[oe] OT: pull requests, merges and bisection (was: OE TSC Meeting 2011/02/21 Minutes)

[Paul Menzel]

Dear OE folks,


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.

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?

Currently I like rebasing (fast fowarding) very much, but that puts
strain on developers too because they always need to update their
patches/commit to latest master.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20110224/d75413b0/attachment-0002.sig>