Page MenuHomePhabricator

release 2.0rc4
Closed, ResolvedPublic

Description

Changes to backport (as compared to rc3 = 1ff1cec):

done

(other changes were also included; see committed changelog)

Not done:

Related Objects

StatusAssignedTask
Declinedjayvdb
Resolvedjayvdb

Event Timeline

valhallasw raised the priority of this task from to Needs Triage.
valhallasw updated the task description. (Show Details)
valhallasw added a project: Pywikibot.
valhallasw added a subscriber: valhallasw.
Restricted Application added subscribers: pywikibot-bugs-list, Aklapper. · View Herald TranscriptOct 2 2015, 9:39 PM
valhallasw moved this task from Backlog to Next release on the Pywikibot board.
hashar awarded a token.Oct 2 2015, 9:49 PM
jayvdb added a comment.Oct 3 2015, 1:17 AM

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.

XZise added a subscriber: XZise.Oct 4 2015, 11:26 AM

What is the advantage of introducing new unnecessary unicode_literals liabilities?

XZise added a comment.EditedOct 4 2015, 12:44 PM

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
valhallasw updated the task description. (Show Details)Oct 4 2015, 2:16 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.

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.

jayvdb updated the task description. (Show Details)Oct 5 2015, 11:37 AM
valhallasw updated the task description. (Show Details)Oct 6 2015, 12:35 PM
jayvdb updated the task description. (Show Details)Dec 19 2015, 12:22 AM
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptDec 19 2015, 12:22 AM
jayvdb closed this task as Resolved.Dec 19 2015, 12:26 AM
jayvdb claimed this task.
jayvdb updated the task description. (Show Details)