[dmd-beta] Cherry-picking II

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

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
<jesse.k.phillips at gmail.com>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 <edwards.ac at gmail.com>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
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
>
>
> --
> Jesse Phillips
>
> _______________________________________________
> 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/20140202/c89a1612/attachment.html>