We have still few issues in Appveyor and should revalidate all open subtasks here (as they propably should be closed), but that looks like real milestone for this project. We should treat right now any Travis failure as blocker (at least till we move to Wikimedia CI) and try to make all tests properly mocked.

@Dalba that's huge! https://travis-ci.org/wikimedia/pywikibot-core/builds/223520844

Isn't it a dup for T158943 ?

Basically it looks, that for pywikibot/i18n git submodule update --init is failing.

Yep, but it was reintroduced in the very next commit, so we should figure out why, because I don't believe that another removal will resolve this issue permanently.

OK, I can confirm, that

Warning: Unable to read "/home/tmagulski/Dokumenty/magul/i18n/core_stable/qqq.json" file (Error code: ENOENT). Use --force to continue.

was occuring since @Dalba change (rPWINcd138ef95047) and was reintroduced in direct child of it (rPWIN23b8beeeeb57)

I've digged one revert from last December (rPWINcd138ef95047e2b4e304d934f640f90e1abf68a3) that looks like something connected.

@Phantom42 Yes, I agree. Actually if You would read my comments above, I done the same research few days ago.

I've checked on Py2,6 and Py2.7 and str(StopIteration()) results with '' so this assertion should be meet in either way. I also checked, that we use unittest2 as unittest for Python versions lower then 2.7.3. I believe problem could be somwhere there.

This particular line that is failing has been introduced in our code in rPWBC2c33f951

I've checked few dozens of builds on our Travis and it looks, that this one first occurs in here. The commit that introduced it was fix for Py2.6 support after introduction of pytest-httpbin.

Great!

It occurs after change rPWBC5138dd7351c9a7eb21791dcfb3b64e276e6bb445 (gerrit: https://gerrit.wikimedia.org/r/#/c/332384/)

Ok @Xqt I upload patch that abandon 2.6 and introduce 3.6 on our Travis CI and Appveyor CI. Feel free to review.

Is there any reason to inform user in any other fashion then ImportError and is there any particular reason that it should be implemented for six package and not some else?

It looks like Your patch requires rebase and it should also remove Python 2.6 from Travis CI and Appveyor CI.

@Dereckson You have my full support on that. Actually we right now have little (or no) unittests in pywikibot and I would like to change it.

I was going create this patch, but You're welcome to do it also, I will just review it (remember about sorting list).

So can we close this issue? What do You think? @jhsoby ?

Yep, You're most probably right. I will create patch for this test in Pywikibot

In Pywikibot we run whole test suit on Travis after every merge. This build is the first one that have this test failing. Previous one didn't fail on that.

Closing it as invalid, because there were no activity for over a month from @Shizhao and I was not able to reproduce it.

@Dalba found a reason why we have problems and remove 2 tests. I'm closing it as resolved.

@Huji I'm aware that we are running 4 jobs to verify any gerrit patch, but haven't found time to check how they are defined. There is also plan to move the whole testing procedure to Wikimedia CI infrastructure (see task T132138), so if You have time to update our jobs there that will be really big step in right direction.

Hi @Huji I don't remember if it is actually pointed out in original PEP-8 document but it was introduced in pycodestyle (formerly known as pep8, changed on direct Guido's requests) as warning W292.

@Lokal_Profil and where is this @Dalba commnet? I cannot see it here or on gerrit.

In T152996#2891272, @Lokal_Profil wrote:

I'm happy to merge as is. Consistently applying the 80 char limit trumps the minor aesthetic loss in this particular case.

Great, thank You!

Shit, I haven't test it, just assumed, that it will work. I will looks further into it. :/

Primary repository is available here: ssh://gerrit.wikimedia.org:29418/pywikibot/core

@maiden_taiwan I see that You're testing today a lot with 2.0rc5 release. Could You test it also on tip of master branch?

In T106121#2892478, @Multichill wrote:

I don't agree. The whole thing with releases is just a giant time sink. We just killed off compat to not have to worry about multiple versions any more. I'd rather have people spend time on improving Pywikibot and fixing bugs, than waste time on some release nobody uses anyway. No, I'm not going to pin on some old version. Pywikibot you run on master. If you run into an issue, you update it to the latest version. If you run into the same issue again, you file a bug and get it fixed. If people are not able to do a simple git clone/git pull, they shouldn't be running Pywikibot at all (or just http://paws.wmflabs.org/).

We tried releases, we failed, let's abandon it.

@Dalba , @Xqt could check this review? There is a question about 79-characters limitation - do we want to always stick to it or do we aproach this limitation in more liberal way?

@Mayank.jindal5 first of all, You should listen to @Framawiki advice and get used look for answers on our IRC channel.

I've tested 707 sites (all production sites: commons, wikidata, wikipedia, wikivoyage, wiktionary, wikibooks, wikinews, wikiquote, wikisource, wikiversity). The whole test takes around 25 minuts.

In T153093#2882015, @gerritbot wrote:

Change 327777 had a related patch set uploaded (by Mpaa):
Fix proofreadpage.purge()

https://gerrit.wikimedia.org/r/327777

@Mayank.jindal5 for your comfort it would be great if You could install virtualenv and create one for pywikibot (see: 1).

Hi @Mayank.jindal5, nice to see You here. Have fun trying to solve this issue, and if You would have any specific question, don't hesitate to ask.

Issue about TestFactoryGenerator::test_random_generator_ns_multi was resolved in T150892.

In last 7 months there were more then 200 occurrences of The build has been terminated (around 5 months ago, build #3545 practically every build has stalled). I have examined almost 100 of them.