[dmd-beta] Cherry-picking II

[Andrew Edwards]

On 2/3/14, 12:33 AM, Brad Roberts wrote:
> On 1/29/14, 12:07 AM, Andrew Edwards wrote:
>> 1) A change is placed in git-hub and reviewed prior to being merged into
>> master. Without such a review it will not be accepted. Why now should we
>> hold another review session prior to picking something to include into
>> the branch? Isn't it better to require a minimum number of reviewers
>> (say three for good measures) to approve a change before to committing
>> to master? That way auto designation of such changes can be made at the
>> time of review with a majority vote from the reviewers.
>
> Not at all.  As a release branch progresses, it naturally grows 
> further out of sync with the master branch.  That by itself lends to 
> some justification for a re-review, even if a very quick on. 
> Additionally, it's a sanity check to allow for the opportunity to make 
> sure what's being merged is what's intended to be merged. Pushing 
> directly into _any_ branch rather than going through a merge pull 
> raises the risk of accidents happening.  Such accidents have happened 
> more than a few times throughout our history.  Even more have happened 
> and caused no damage in wrongly constructed pull requests, indicating 
> the value of stepping through a pull request and avoiding damaging the 
> master branch.  It has much less to do with correctness of the change, 
> but rather with validation of the merge and it's continued correctness 
> within the differing code base.
>
>> 2) We just agreed upon a naming scheme that you insisted had to meet a
>> certain convention in order to guarantee validation by the auto-tester.
>
> Not relevant.
>
I don't see why not. Take a walk with me 4 weeks after the final release 
of 2.065. At that time the new release cycle begins for 2.066. Would I 
need a pull request for everything in master that is about to make it 
into 2.066 without the added scrutiny of this safer process? Why is it 
not important to provide the same scrutiny to these changes as you would 
to changes that follow for the branch specifically?

>> By doing this we would be unnecessarily inducing another delay in the
>> process: which is counterproductive.
>
> I don't believe that's accurate.  What I suggest is a substitution of 
> a request for you to merge that comes in via a bug notation, an email, 
> or a pull request note in the master branch pull with a pull request.  
> The latter being significantly less likely to get lost in the noise 
> than most of the former.  Lastly, by constructing and submitting a 
> pull request, chances are even higher that by the time you see it, 
> it's already both been validated by the requester as matching his 
> intent and by the auto-tester as passing tests.  That just leaves a 
> little button pressing to perform the merge.
>
So if I understand this right, you are suggesting that the author of a 
pull create two separate pull requests. One against master, which is 
tested by the auto tester, must be reviewed by one or more developer(s), 
approved, and merged into master once approval is granted. Once it 
passes the first phase, the author creates another pull request for the 
same changed to be merged into the release branch, which again must be 
auto tested, reviewed, and approved for merger to the branch. Finally, 
after the branch is released, it must be merged back into master and 
retested by the auto-tester. Am I understanding that correctly? If I am, 
isn't it simper to create the pull against the branch, merge it after 
approval and merge the branch back to master after release? That is the 
correct way and and it ultimately achieves everything your are seeking.

It would work like this:

     Sunday 04:00AM to Saturday 10:00PM - pull requests generated 
against branch or master are merged upon approval
     Saturday 10:00PM to Sunday 04:00AM - new tag is generated against 
branch and pushed upstream. Release binaries are built from new tag. 
Branch (beta or otherwise) is merged to master
     Sunday 04:00 - immediately after merging branch to master, resume 
merging approved changes to branch or master as appropriate

Six hour window for building to address any issues that might arise. 
Window may shrink as the process becomes more fluid. This keeps branch 
and master from diverging and puts the changes in their appropriate 
location to begin with. It also completely eliminates the guessing game 
of what needs to be in the branch. Safe, lean, and efficient.