Getting ready for 2.061

[Don]

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.