Well, what about getting back to sane git model but using inverse help from Release Manager? I mean making his job to make sure no fix commits go into master while release is in progress and reverting those who slip by an accident (with a reminder to redo pull request to proper base). This is much less of a burden than cherry-picking and may eventually teach everyone to make correct pulls without reminders :)
On Sun, Feb 2, 2014 at 8:04 PM, Jesse Phillips <[email protected]>wrote: > Well, my opinion is that the quest to find a "simple" process is leading > to reinventing the wheel with a fork and a spoon rather than a hammer and > chisel. This new issue is not a new problem and would have been addressed > with the appropriate process of creating pull requests against the release > branch, or even merging to the release branch instead of master. But there > seems to be some confusion about this (now that it has come up as a > replacement for writing notes back and forth). > > In your last email you took issue of adding a second review step, when the > first doesn't get any attention. This is wrong, dead wrong. There should > not be two reviews, there should only ever be one single pull request and > that request should get the review. > > Yes, this approach does require involvement of the patch contributors, but > that is already true. The contributor is already tackling regressions for > the new release, so they're already aware of where this fix needs to go. It > just requires them to check out the release branch on the three repos > before starting. > > Even if the developers don't wish to push the request against release, > they can still leave a comment on the Pull request (against master) stating > this should go into release. At this point the pull request is NOT merged > into master, instead it is merged into the release branch. This approach > has the negative that the fix may not be complete or have merge conflicts > due to dependency on previous changes (this would be where a comment should > be left and request that the issues be addressed). > > Once the release is complete, merge it back into master (this can actually > be done at any time, but should always be done at the end of release). > > > On Sun, Feb 2, 2014 at 9:29 AM, Andrew Edwards <[email protected]>wrote: > >> So this is where the discussion ends? No decision or further >> communication. All forward action suggest the status quo. We honestly need >> to do something here gents. Were it my decision to make, would have been >> handled on day one but since it's not, I need your participation. >> >> Kenji, need you take a look at dmd/pull/#3140 and see what kind of >> problems will occur it is merged after #3103, #3151, #3174, and #3169 >> respectively. >> >> Thanks, >> Andrew >> >> _______________________________________________ >> dmd-beta mailing list >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/dmd-beta >> > > > > -- > Jesse Phillips > > _______________________________________________ > dmd-beta mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-beta >
_______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
