On 27 July 2015 at 08:45, Donald Stufft <[email protected]> wrote: > On July 26, 2015 at 6:22:44 AM, Nick Coghlan ([email protected]) wrote: >> On 25 July 2015 at 14:47, Brett Cannon wrote: >> > How would we handle >> > changes that require custom fixes in two branches? They just fix it in both >> > and we automatically handle the merge/revert steps? >> >> I don't think it's a coincidence that there's a correlation between >> "project uses a pull request based workflow" and "project doesn't >> provide maintenance releases for past feature releases" :) > > I think it is a coincidence (and in fact there are projects that use PRs > and multiple maintenance series). No matter what any system requires > some(one|thing) to trigger a patch against the other branches. There is > basically no difference between sending a PR in GitHub to a particular > series branch or submitting a CR in Gerrit to a different branch. GitHub > lets you do it entirely in the web interface for the simple case where > there are no merge conflicts even where you can create a PR that forward > merges the old branches in the UI.
Oh, nice - I didn't know GitHub could do that. That reduces the meaningful workflow differences I am aware of to Gerrit's support for "multiple approvals required for merge" and the more fine-grained access control model around things like who can submit change requests, who can mark them as verified, who can approve them, etc. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
