lkml.org 
[lkml]   [2010]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: current pending merge fix patches

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> This could also be taken as a reminder to the respective maintiners that
> they may want to do a merge of your tree before asking you to pull theirs.

I dont think that's generally correct for trivial conflicts: it's better if
Linus does the merge of a tree that is based in some stable tree.

It causes slightly messier criss-cross history: there will be the back-merge
commit plus the inevitable merge commit from Linus. It also makes bisection a
bit messier:

For example when bisecting i generally consider the 'boundary' of where Linus
pulls as a 'known point of stability': i.e. the 'subsystem side' is expected
to be well-tested and if there's a problem on that side, it's that subsystem's
domain.

"Linus's side", during the merge window, is a rolling tree of many freshly
merged trees, which inevitably piles up a few problems.

So it's IMO somewhat better to keep that boundary and not push out Linus's
side into subsystem trees: which then may merge a few new patches after having
merged Linus's tree, intermixing it all into a non-bisectable combination.

Plus there's also an indirect effect: it keeps people from merging back
Linus's tree all the time.

So i'd argue to not backmerge during the merge window (and i have stopped
doing that myself a few cycles ago, and it clearly helped things) - but in any
case it's certainly no big deal and up to Linus i guess.

Ingo


\
 
 \ /
  Last update: 2010-03-01 09:13    [from the cache]
©2003-2011 Jasper Spaans