[wildfly-dev] Merge Commits

[Jason Greene]

On Sep 30, 2013, at 10:19 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> On 9/30/13 10:04 AM, Jason Greene wrote:
>> 
>> On Sep 30, 2013, at 7:11 AM, Radoslav Husar <rhusar at redhat.com> wrote:
>> 
>>> On 30/09/13 12:07, Tomaž Cerar wrote:
>>>> One of possible ways to do it is also merge commits, aka github's "merge
>>>> button"
>>> 
>>> I wonder how would that help, since IIUC multiple PRs are now tested in
>>> a single batch to make sure the PRs together do not cause a regression,
>>> whereas each one passes the testsuite on its own. Then just push the
>>> whole batch…
>> 
>> We would have to change the process to submit pull requests into a staging branch, and that branch once certified (all tests pass on all combination) would be pushed to the main master branch. In the event that a run fails, we would backup / redo the staging branch, and let it push again.
>> 
> 
> Currently processing multiple pull requests in a batch is just a matter 
> of a script doing rebases in a loop against a special branch that starts 
> out at master HEAD, testing the final result of that and then merging 
> the final special branch.
> 
> Ideally the same process could be used, just with merge commits in the 
> loop instead of rebases. Is that another way of saying what you 
> described above? Or is there a problem with the final merge of the 
> special branch?

Yes we could write something to mirror the old way and use merge commits and PR linking and so on. My suspicion is that the staging process would be faster because you just click the green button on "clean" changes. The test process could kick off automatically and email later, or to prevent duplicate runs we could just have an extra launch step (click the run button on brontes once you are done merging).

> It's pretty important that this be efficient. The large majority of PRs 
> get merged in sizable batches, because the heavy costs are the test 
> execution time and the context switch on the part of the merger.

I agree thats the goal. 

> 
> -- 
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat