With the recent inflation of merging pull requests and reverting them I
wonder if it would
make sense to use integration branches.

The proposed workflow would be.

  - merge pull request to integration branch of dmd/druntime/phobos, i.e.
multiple merges
    are stashed into the same branch
  - if auto testing or something else fails revert merge and discuss follow
ups on github
  - after everything is sorted out merge the complete pull request into
master
  - from time to time the integration branch needs to be synced with master
    most likely when not too much pulls are merged into it

That way pull requests can stay open until being functional and merged to
master.
The maintenance overhead should be fairly low.
The auto tester would need to test two sources and sometimes one needs to
reset the integration branch.

martin

Sounds like a reasonable approach to me. Recent experience indicates that even if the pull request author tests on one platform, it can't be expected the code will work for all.

Brad?

Andrei

On 6/3/11 10:08 AM, Martin Nowak wrote:
> With the recent inflation of merging pull requests and reverting them I
> wonder if it would
> make sense to use integration branches.
>
> The proposed workflow would be.
>
> - merge pull request to integration branch of dmd/druntime/phobos, i.e.
> multiple merges
> are stashed into the same branch
> - if auto testing or something else fails revert merge and discuss
> follow ups on github
> - after everything is sorted out merge the complete pull request into
> master
> - from time to time the integration branch needs to be synced with master
> most likely when not too much pulls are merged into it
>
> That way pull requests can stay open until being functional and merged
> to master.
> The maintenance overhead should be fairly low.
> The auto tester would need to test two sources and sometimes one needs
> to reset the integration branch.
>
> martin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I've never seen this actually add value before.  All it does is shift where things break.  We're not having cross-pull request conflicts.  We're having simple "it doesn't work" breakage.  Whether that shows up on a build from the trunk or an integration branch, the bottom line is it's broken and it causes work to revert them.

I'm not opposed to trying it, but I don't really have the extra time to invest in a project I see as being not-useful. I encourage those that do to do so though since I could easily be wrong.  It wouldn't be the first time.

Later,
Brad

On 6/3/2011 8:44 AM, Andrei Alexandrescu wrote:
> Sounds like a reasonable approach to me. Recent experience indicates that even if the pull request author tests on one platform, it can't be expected the code will work for all.
> 
> Brad?
> 
> Andrei
> 
> On 6/3/11 10:08 AM, Martin Nowak wrote:
>> With the recent inflation of merging pull requests and reverting them I
>> wonder if it would
>> make sense to use integration branches.
>>
>> The proposed workflow would be.
>>
>> - merge pull request to integration branch of dmd/druntime/phobos, i.e.
>> multiple merges
>> are stashed into the same branch
>> - if auto testing or something else fails revert merge and discuss
>> follow ups on github
>> - after everything is sorted out merge the complete pull request into
>> master
>> - from time to time the integration branch needs to be synced with master
>> most likely when not too much pulls are merged into it
>>
>> That way pull requests can stay open until being functional and merged
>> to master.
>> The maintenance overhead should be fairly low.
>> The auto tester would need to test two sources and sometimes one needs
>> to reset the integration branch.
>>
>> martin

OK. Then we'll keep the idea in mind going forward without acting on it yet.

Thanks all,

Andrei

On 6/3/11 11:52 AM, Brad Roberts wrote:
> I've never seen this actually add value before.  All it does is shift where things break.  We're not having cross-pull request conflicts.  We're having simple "it doesn't work" breakage.  Whether that shows up on a build from the trunk or an integration branch, the bottom line is it's broken and it causes work to revert them.
>
> I'm not opposed to trying it, but I don't really have the extra time to invest in a project I see as being not-useful. I encourage those that do to do so though since I could easily be wrong.  It wouldn't be the first time.
>
> Later,
> Brad
>
> On 6/3/2011 8:44 AM, Andrei Alexandrescu wrote:
>> Sounds like a reasonable approach to me. Recent experience indicates that even if the pull request author tests on one platform, it can't be expected the code will work for all.
>>
>> Brad?
>>
>> Andrei
>>
>> On 6/3/11 10:08 AM, Martin Nowak wrote:
>>> With the recent inflation of merging pull requests and reverting them I
>>> wonder if it would
>>> make sense to use integration branches.
>>>
>>> The proposed workflow would be.
>>>
>>> - merge pull request to integration branch of dmd/druntime/phobos, i.e.
>>> multiple merges
>>> are stashed into the same branch
>>> - if auto testing or something else fails revert merge and discuss
>>> follow ups on github
>>> - after everything is sorted out merge the complete pull request into
>>> master
>>> - from time to time the integration branch needs to be synced with master
>>> most likely when not too much pulls are merged into it
>>>
>>> That way pull requests can stay open until being functional and merged
>>> to master.
>>> The maintenance overhead should be fairly low.
>>> The auto tester would need to test two sources and sometimes one needs
>>> to reset the integration branch.
>>>
>>> martin
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos