On 02/24/2011 04:33 PM, Chris Larson wrote:
On Thu, Feb 24, 2011 at 3:55 PM, Paul Menzel
<[email protected]> 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
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
