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
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
