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