[oe] OT: pull requests, merges and bisection

[Tom Rini]

On 02/24/2011 04:33 PM, Chris Larson wrote:
> On Thu, Feb 24, 2011 at 3:55 PM, Paul Menzel
> <paulepanter at users.sourceforge.net>  wrote:
>> it is great that the minutes of the meetings get published. Thank you.
>>
>>
>> Am Donnerstag, den 24.02.2011, 09:20 -0700 schrieb Tom Rini:
>>
>> […]
>>
>>> Not clear in the summary but from the logs is that we want to, as part
>>> of making this be transparent, publish guidelines for how this will
>>> work, based on what poky is doing now.  The high level plan is to follow
>>> the contrib tree model that poky has which means sending pull requests
>>> (which in turn also post the patches to the ML for review).
>>>
>>> For changes that don't have a tree to pull from, someone with write
>>> access would need to pick them up.
>>
>> XBMC is using also an approach with pull requests. The Linux kernel is
>> doing that also. Is there documentation on how pull requests, merges and
>> bisecting works together?
>>
>> My problem is that pull requests are based on a certain commit in
>> origin/master. After the request is sent most of the time several
>> commits are pushed to origin/master in the mean time, so a merge is
>> necessary “polluting” the commit history.
>
> I don't really see a problem with it, personally.  It's not pollution
> if it's useful information, and recording the point where the branch
> was brought it can indeed be useful information.
>
>> With my current knowledge I find it very difficult to track down bad
>> commits especially if commits break the builds in between. Does `git
>> bisect` take care of that itself? How do the Linux developers deal with
>> that problem, especially merge conflicts?
>
> Well, you can mark commits that are broken for unrelated reasons with
> bisect, but ideally people would use something like git test-sequence
> combined with rebase to ensure that there are no points in their
> commits which will break bisect, and *that* gets merged to master.  I
> think it's pretty important to retain bisectability (not a word, I
> know :) on our branches.

... and this is where policies and guidelines help the situation.  poky 
currently looks to be doing a rebase after each, which could be fine so 
long as test-sequence (and a useful set of targets being built in there) 
are used.

-- 
Tom Rini
Mentor Graphics Corporation