<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 7:04 PM, Brad Roberts <span dir="ltr"><<a href="mailto:braddr@puremagic.com" target="_blank">braddr@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 1/28/14 9:27 AM, Andrew Edwards wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Recent experience with #3103 and #3151 suggests that there needs to be a better way of identifying<br>
what goes in the releases. Currently, I am honing in on regressions and ICEs because those are the<br>
stated objectives for this release. That being said, if I read one of these fixes and is says git<br>
master/head only, I simply mark it as ignore and move on. If another fix appearing down the line<br>
depends on the one I've ignored to be merged first, I do not know if it does not explicitly state.<br>
<br>
Additionally, it causes a slight confusion when I encounter errors upon attempts to sync local<br>
branch with upstream branch, which I'm under the assumption that I'm the only one cherry picking to,<br>
because someone else is committing to that branch.<br>
<br>
These two issues prompts me to suggest that instead of simply merge and forget or merge and<br>
cherry-pick yourselves that you simply assign the PR to me after the merge if it is intended to be<br>
included in the upcoming release cycle. With this one action, we can alleviate all confusion about<br>
what should be include in the release and prevent errors/conflicts when trying to commit to release<br>
branches upstream.<br>
<br>
Your understanding and efforts are appreciated.<br>
<br>
Regards,<br>
Andrew<br>
</blockquote>
<br></div>
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:<br>

<br>
  1) gives a good chance to review exactly what changes are going to be made<br>
  2) gives the auto-tester a chance to validate then changes<br>
  3) gives a chance for additional eyeballs to be watching for mistakes<br>
<br>
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.<div class="HOEnZb">
<div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
dmd-beta mailing list<br>
<a href="mailto:dmd-beta@puremagic.com" target="_blank">dmd-beta@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/dmd-beta" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/dmd-beta</a><br>
</div></div></blockquote></div><br></div>