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 <braddr@puremagic.com> 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
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta