⚓ T114534 release 2.0rc4

		Status	Subtype	Assigned	Task
		Declined		jayvdb	T1315 Release 2.0
		Resolved		jayvdb	T114534 release 2.0rc4

Event Timeline

valhallasw created this task.Oct 2 2015, 9:39 PM

valhallasw raised the priority of this task from to Needs Triage.

valhallasw updated the task description. (Show Details)

valhallasw added a project: Pywikibot.

valhallasw subscribed.

Restricted Application added subscribers: pywikibot-bugs-list, Aklapper. · View Herald TranscriptOct 2 2015, 9:39 PM

valhallasw added a parent task: T1315: Release 2.0.Oct 2 2015, 9:44 PM

valhallasw moved this task from Backlog to Next major release on the Pywikibot board.

To be considered for manual cherry-picking:

hashar awarded a token.Oct 2 2015, 9:49 PM

Also, as found during T114487, setup.py and a few other files on the 2.0 branch are not using unicode_literals. If we want to fix this, the following two need to be merged.

What is the advantage of introducing new unnecessary unicode_literals liabilities?

Anyway I don't like how we aren't improving the tests. It might be that issues are covered by our master branch tests, but those don't test the 2.0 branch and we might very well introduce a bug due to incorrect cherry picking.

Sorry wrt to my last comment, but I have been trying cherry pick everything useful but apparently my definition is way off. And if you want to also introduce the forced unicode_literals, should those two patches be integrated into one patch so that our setup.py is never broken?

Also you could in theory use curly brackets: {0a66705} → rPWBC0a66705f6c67: Work around traceback in atexit

I don't think we should introduce unicode_literals either, unless this is important for later cherry-picking (e.g. we expect to introduce code that assumes unicode_literals is used later).

I'm also not sure how this relates to the patches you suggested to backport but where jayvdb or I disagreed. Those were not improvements to the tests (i.e., they were not adding or fixing tests), but were changes to how the test framework operates, and I don't see the benefit in backporting those. Again, if the changes are needed for a new test: sure, but on itself they don't provide value.

valhallasw updated the task description. (Show Details)Oct 4 2015, 1:36 PM

valhallasw set Security to None.

valhallasw updated the task description. (Show Details)

valhallasw updated the task description. (Show Details)Oct 4 2015, 1:51 PM

I backported most of them, but several of them change so much stuff in different places I'm not sure if the backport is actually correct. Several of them also get -1'ed by Jenkins. I'm not going to fix those -- I feel I put in my fair share by doing the initial backport.

In T114534#1700581, @XZise wrote:

What is the advantage of introducing new unnecessary unicode_literals liabilities?

I am not sure there is any benefit in backporting unicode_literals into pwb.py & setup.py. I was only noting them as those two need to be done together, or not at all. The bug in setup.py was a bit of a surprise. I wonder how many more are lurking in the corners. But I wouldnt call unicode_literals a liability!
Consistency would be the only argument, but those two files are quite different in that they are not installed.