<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2/2/14, 2:04 PM, Jesse Phillips
wrote:<br>
</div>
<blockquote
cite="mid:CAKuxe4hTZ6YiKqUu-7Z2JtTCKz4VzrSCu6P+4VefSXa9tFHYqQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>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).<br>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
I agree with you that what we are doing now complicates matters
more. It is not my choice that I made the decision to cherry-pick
commits to the release branch, rather it is compromise that promotes
forward progress. Fact is, only three people adhered to the request
to create pull requests against the release branch and there are a
lot more contributors than that. Honestly I believe this is the best
approach but no matter how good one things a particular approach is,
if no one is doing it, it serves no purpose.<br>
<br>
<blockquote
cite="mid:CAKuxe4hTZ6YiKqUu-7Z2JtTCKz4VzrSCu6P+4VefSXa9tFHYqQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>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.<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
I took issue with it because by adding this extra step, we are
inducing additional delay in the entire process. As you said, one
review should suffice. All that's left to do after that is flip a
switch indicating that it needs to be in the release branch. This
can be accomplish in one of two ways: 1) set the Asignee to
AndrewEdwards following the merge; 2) Set the Milestone to 2.065
anytime during the creation, review or merger of the request. Come
to think of it, a combination of the two would probably provide the
best solution. The author assigns the milestone when creating the
pull. Upon seeing this milestone the reviewer assigns the pull to me
after the merge. A two step process that requires one additional
step from two different people.<br>
<br>
<blockquote
cite="mid:CAKuxe4hTZ6YiKqUu-7Z2JtTCKz4VzrSCu6P+4VefSXa9tFHYqQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>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.<br>
<br>
</div>
</div>
</div>
</blockquote>
Though I'd like this to happen, I really doubt it is going to.
Therefore, in order not to prolong the process, I've decided not to
pursue this direction any longer.<br>
<br>
<blockquote
cite="mid:CAKuxe4hTZ6YiKqUu-7Z2JtTCKz4VzrSCu6P+4VefSXa9tFHYqQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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).<br>
<br>
</div>
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).<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Sun, Feb 2, 2014 at 9:29 AM, Andrew Edwards <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:edwards.ac@gmail.com" target="_blank">edwards.ac@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Andrew
<div class="HOEnZb">
<div class="h5"><br>
_______________________________________________<br>
dmd-beta mailing list<br>
<a moz-do-not-send="true"
href="mailto:dmd-beta@puremagic.com" target="_blank">dmd-beta@puremagic.com</a><br>
<a moz-do-not-send="true"
href="http://lists.puremagic.com/mailman/listinfo/dmd-beta"
target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-beta</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Jesse Phillips
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dmd-beta mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dmd-beta@puremagic.com">dmd-beta@puremagic.com</a>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/dmd-beta">http://lists.puremagic.com/mailman/listinfo/dmd-beta</a></pre>
</blockquote>
<br>
</body>
</html>