lkml.org 
[lkml]   [2010]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] block/IO bits for 2.6.36-rc1
    On Fri, Aug 6, 2010 at 3:38 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
    >
    > Not sure what happened on the excessive number of merges listed
    > as:
    >
    >      Merge branch 'for-2.6.36' into for-next

    Yeah, I'm not taking this. This has all the signs of the things people
    used to do a year or two ago - daily merges into random points of my
    tree. Some of them are more than daily.

    There is no excuse. None. Your "I thought they were all going to be
    fast-forwards" excuse is pointless. You shouldn't have done it in the
    first place, and once you did it, you should have noticed, instead of
    doing _another_ merge on the same effing day!

    I accept a few merges over many weeks. I accept things like merging
    tags (preferably the _release_ tags, rather than -rc's). But you have
    two merges of my tree ON THE SAME DAY, and you have three merges - of
    just totally trivial and uninteresting individual patches - from your
    own branch within a couple of days. For no reason I can fathom. Why
    didn't you do those commits on the right branch to begin with?

    That's just f*cked up. And quite frankly, I have no other way to fix
    crap like this than to say "I won't merge it". If I do merge it, not
    only do I get the crap, but I just know I'll _continue_ to get crap
    because things don't get fixed. Which is why I've spent so much time
    talking about clean history over the years.

    I thought we were over this.

    I would suggest you:

    (a) think about what the hell you do wrong. I can point to at least a
    couple of things:

    - you use two branches for the same thing, for no reason. You
    apparently have "for-next" and "for-2.6.36", and you seem to have
    thought they were different (why?) and then merged between them
    sometimes daily.

    If they are separate, you shouldn't be merging them (and you should
    _never_ merge daily - if it's under development, it just messes things
    up). And if they aren't separate, you shouldn't mess things up and use
    two different branches for the same thing, and then just make things
    messy that way.

    - You merged from my tree at random points. Why? Until you ask me to
    merge from you, there is NO REASON to try to resolve conflicts. And
    once you _do_ ask me to merge from you, I still don't want you to do
    the merge, because I want to know about what conflicts. That's where
    the bugs almost always are.

    And finally: if you do merge from me, don't merge some random
    "master" branch. Merge the v2.6.35 release tag.

    (b) Once you are sure the current mess doesn't ever happen again,
    rebase the mess on top of 2.6.35. NOT on top of whatever random
    unstable tree-of-the-day-during-the-merge-window. Rebasing on top of
    something unstable is crazy work, and should absolutely never be done.
    And then test the hell out of it, and walk through it all making sure
    it's ok. And do that for a couple of _days_.

    And note: one of the reasons I want the block tree to be clean is that
    the biggest problems we had last release cycle was with the writeback
    code. Quite frankly, if you can't get it sorted out and tested well by
    the end of the merge window, I will absolutely _happily_ not pull your
    tree this release at all. Because last release was annoying and
    clearly not tested enough. If the work gets delayed by a release (or
    two), I'll be perfectly ok with it.

    So if we hadn't had problems last release, I might have let this
    slide. But I am of the very strong opinion that the block tree has not
    been careful enough. The mess with ugly history is just a symptom of
    that, I think.

    Linus
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-08-06 17:47    [W:0.044 / U:0.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site