On Mon, Oct 10, 2016 at 10:34 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 October 2016 at 01:12, Chris Angelico <ros...@gmail.com> wrote: >> In my experience, CPython is stable enough that you can sometimes even >> pick up a patch from *2.7* and apply it to the latest 3.x. (The >> downside of this is that some files are oddly named, eg longobject.c, >> which implements what we now call "int".) Between 3.5 and 3.6 it'll be >> even more common for a patch to apply cleanly, and shortly after a >> branch is cut (eg current 3.6 -> 3.7), near-certain. > > Right, it's mainly when you collide with a refactoring that things get > painful (e.g. the SSL/TLS rebase in Python 2.7 ran into that).
Makes sense. So it would probably be worth cherry-picking a patch one branch at a time; I would expect that such code changes, once done, are reflected in all future branches, so you'd have something like "3.3-3.4 work this way, and 3.5-3.7 work that way". Should be pretty obvious once people get started on it. > In general though, we shouldn't see any more problems with cherry > picks than we see with forward merges, and there Misc/NEWS is the only > consistent source of conflicts. Is Misc/NEWS needed for old branches? If not, the easiest way might be to simply build the patch without NEWS, then cherry-pick it to all other branches, and finally add NEWS to the latest branch only. >> That would be a personal workflow choice, then. +1 on RFC 2119 MUST vs >> SHOULD usage. IMO the document should specify *one* recommended >> workflow, because otherwise it's just way too confusing to read; and >> then by its language, it can clarify which parts you're allowed to >> diverge from and which not. > > A lot of the SHOULDs will be "Use the web-based workflow to review and > merge changes, since that offloads more of the work to automated > systems and can be done from any client device". > > While there will be cases where local client usage is needed (and > generating a backport PR will be one of them, unless/until GitHub > copies GitLab's cherry-pick-in-the-web-UI feature), allowing reviews > to be done that way is mainly for the benefit of current core devs > that prefer to do their reviews locally. Sounds good to me. Those who are comfortable with local tools are welcome to use them; if you've become as familiar with gitk as I have, you won't want to give it up. (hgk/'hg view' is a poor clone of gitk, with a fraction of its power. Don't judge gitk by hgk!) The default workflow will be the nice simple web-based one, but there are plenty of equivalents. GitHub will notice that you've pushed all the commits in a PR and automatically mark it as "Merged", for instance, so you don't have to worry about going and doing some bookkeeping. ChrisA _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct