[dmd-beta] Cherry-picking II

[Andrew Edwards]

On 1/28/14, 1:04 PM, Brad Roberts 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.
>
I'm not necessarily against this but I have a few questions.

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.

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. 
If the auto tester already test this branch, and it does, why now would 
I need another way of monitoring what changes made to the branch?

3) How often have you seen a request for comment on a particular pull go 
unanswered? Just this past week, several request were made by Daniel 
Murphy than no on responded to. In the end, he made the decision on his 
own. Here are a couple that still remain unanswered:

https://github.com/D-Programming-Language/dmd/pull/3120#issuecomment-33344986
https://github.com/D-Programming-Language/dmd/pull/3118#issuecomment-33309502
https://github.com/D-Programming-Language/phobos/pull/1864#issuecomment-32484778

By doing this we would be unnecessarily inducing another delay in the 
process: which is counterproductive.

Regards,
Andrew