I think we still should try to form a culture of targeting PR into release branch instead of master in the long term, reserving cherry-pick approach for the rest. At least major regression fix contrbutors should try to do it to make Andrew life tiny bit easier.
On Tue, Jan 28, 2014 at 7:04 PM, Brad Roberts <[email protected]> wrote: > On 1/28/14 9:27 AM, Andrew Edwards wrote: > >> Recent experience with #3103 and #3151 suggests that there needs to be a >> better way of identifying >> what goes in the releases. Currently, I am honing in on regressions and >> ICEs because those are the >> stated objectives for this release. That being said, if I read one of >> these fixes and is says git >> master/head only, I simply mark it as ignore and move on. If another fix >> appearing down the line >> depends on the one I've ignored to be merged first, I do not know if it >> does not explicitly state. >> >> Additionally, it causes a slight confusion when I encounter errors upon >> attempts to sync local >> branch with upstream branch, which I'm under the assumption that I'm the >> only one cherry picking to, >> because someone else is committing to that branch. >> >> These two issues prompts me to suggest that instead of simply merge and >> forget or merge and >> cherry-pick yourselves that you simply assign the PR to me after the >> merge if it is intended to be >> included in the upcoming release cycle. With this one action, we can >> alleviate all confusion about >> what should be include in the release and prevent errors/conflicts when >> trying to commit to release >> branches upstream. >> >> Your understanding and efforts are appreciated. >> >> Regards, >> Andrew >> > > IMHO, a much more workable solution is to use pull requests just like for > any other branch. If someone is requesting a merge to a release branch, > then they should assemble the pull request and submit it. If you are > deciding a fix should be merged to the release branch, put together the > pull request just like anyone else would. That gains several advantages: > > 1) gives a good chance to review exactly what changes are going to be > made > 2) gives the auto-tester a chance to validate then changes > 3) gives a chance for additional eyeballs to be watching for mistakes > > The only con is that it's more steps, but without those steps, the gains > aren't possible. For any regular developer, putting together a pull > request is something they can do in their sleep, so the cost is pretty > small. > > > _______________________________________________ > 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
