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    [W:0.021 / U:65.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site