[dmd-beta] Cherry-picking II

[Михаил Страшун]

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 at 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 at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20140128/2cea4c13/attachment.html>