On 23.12.2012 03:11, Walter Bright wrote:
On 12/22/2012 5:43 PM, Jonathan M Davis wrote:
On Saturday, December 22, 2012 17:36:11 Brad Roberts wrote:
On 12/22/2012 3:44 PM, Jesse Phillips wrote:
What is nice about making a pull request against staging is that the
reviewer knows that the fix can be applied that far (not that comments
wouldn't do the same).
I don't believe those assertions to be true. Merging in either
direction is
possible and the difficulty lies in the nature of the drift between the
two. Neither direction is necessarily any easier than the other.
If you merge from the branch to master, then there's a higher risk of
forgetting to merge fixes. If you merge from master to the branch,
then there's
a higher risk of putting changes in the branch that you don't want in the
branch. However, as long as the changes on master aren't too large,
you can
simply cherry-pick the changes from master to the branch (or vice versa)
without too much trouble. Overall though, I would think that the risk of
screwing up is higher if commits go to the branch initially rather than
master.
It makes more sense to me to put the commits into master, and then
cherry pick for the branch.
IMHO, the big issue is, and has always been, what does the autotester test?
It makes most sense to me to have all new fixes for _anything_ going
into the development branch, and tests on the release branch to exist
solely for regression testing "just in case".
It makes no sense to me to have pull testing against multiple branches.
