Brad Roberts, el 22 de December a las 17:36 me escribiste:
> On 12/22/2012 3:44 PM, Jesse Phillips wrote:
> > On Saturday, 22 December 2012 at 21:48:51 UTC, Brad Roberts wrote:
> > 
> >> I strongly recommend requiring that all bugs be first fixed in the development branch and then being pushed backwards through the version history.  Quite a few projects follow this pattern based on the requirement that no fix can ever be accidentally left out of a future release.  You never want someone to pick up (using made up version numbers) 3.4.2 to get a fix and later upgrade to 4.1.1 and find out it's not yet fixed in that release.
> > 
> > Well, to have the easy merging the change must be made against the oldest applicable code. The benefit of merging into staging first is that staging can be merged into master, while master can not be merged into staging.
> > 
> > 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.

And cherry-picking is your friend. You don't really need to merge anything.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<original> [Penis Uptime: 2days 13hrs 59mins 35secs]
<Yapa> viagra? :)
<original> yea, 20 pills

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.

On Sunday, December 23, 2012 20:06:38 Don wrote:
> 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.

That makes it make all the more sense to merge into master first, though it means that staging never gets tested in all of the various environments, which could be a problem if commits that are in master aren't supposed to be merged into staging but actually (unknowingly) fix the build somehow. There's no way to fix that without actually running the autotester or staging as well as master though. No matter how you do the branching, if you're not releasing from your development branch, you end up needing to autotest both branches if you want to be safe about it.

- Jonathan M Davis

On 21.12.2012 23:12, Andrei Alexandrescu wrote:
> All contributors - over the weekend please ping reviewers on what you
> believe are pull requests with a high importance*urgency product. Once
> we branch into staging, pull requests will only be merged into master.

DMD #1396 fixes a compile error with Visual Studio 2012 and should be merged.

Kai

On 2012-12-23 20:06, Don wrote:

> 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.

Preferably we should have the autotester running on all branches. It would be nice if the autotester could automatically start testing new branches as soon as they are pushed upstream. Now I understand that we might not have enough computers to do that.

-- 
/Jacob Carlborg

What kind of computers would we need to do these tests?
I have some spare resources for one or two VPS.

Perhaps others do too.
On 24 Dec 2012 12:45, "Jacob Carlborg" <doob@me.com> wrote:

> On 2012-12-23 20:06, Don wrote:
>
>  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.
>>
>
> Preferably we should have the autotester running on all branches. It would be nice if the autotester could automatically start testing new branches as soon as they are pushed upstream. Now I understand that we might not have enough computers to do that.
>
> --
> /Jacob Carlborg
>

And what is the stage of affairs? Means: Can I download 2.061?

On 2012-12-24 13:52, Rory McGuire wrote:
> What kind of computers would we need to do these tests?
> I have some spare resources for one or two VPS.

I have no idea how many are need to run tests on all branches. Brad would know this better.

What usually is a problem is Mac OS X. Since you're only allowed to run it on Apple computers (if you want to follow the EULA) and Mac users is a minority here.

> Perhaps others do too.

People have already donated computers/shells to run the test suite as we do now.

I'm wondering if it would be a good idea to start using Travis CI. Currently it only supports Linux but they're working on adding Mac OS X and Windows.

-- 
/Jacob Carlborg

On Monday, 24 December 2012 at 10:43:07 UTC, Jacob Carlborg wrote:
> Preferably we should have the autotester running on all branches. It would be nice if the autotester could automatically start testing new branches as soon as they are pushed upstream. Now I understand that we might not have enough computers to do that.

The additional load caused by this should be negligible compared to all the pull requests.

David

On 2012-12-24 14:08, David Nadlinger wrote:

> The additional load caused by this should be negligible compared to all
> the pull requests.

Well, we want all pull request to run on all these branches as well, or at least the pull request made on a given branch :)

-- 
/Jacob Carlborg