lkml.org 
[lkml]   [2011]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectLinux 3.2-rc1
    So it's been two weeks since 3.1, and you know how it works by now.

    I have to say, this wasn't my favorite merge window ever. I really
    wanted to take only things that had been in -next, but verifying it
    was fairly painful, since a lot of the trees had been rebased, and the
    ones that hadn't been rebased often had some extra patches that still
    showed up when I did my "git log linux-next..FETCH_HEAD" thing.

    On the whole, most of it was all good, and I didn't really end up
    complaining to people. I'm pretty sure that there were trees I
    shouldn't have let through, but the majority really had been in -next.

    The other point of irritation was that there really was a lot of stuff
    that came in yesterday and basically treated the merge window as some
    kind of high-tech limbo dance. If it hadn't been for a few trees I
    wanted to pull, I had actually planned to do the -rc1 release Sunday
    afternoon instead, just to cut those annoying last-minute pull
    requests off.

    And some trees didn't get pulled. You know who you are, and you can
    try to appeal to my softer side if you think it was unfair. Of course,
    if you *do* find my softer side, please tell my wife and kids too,
    they'll be thrilled.

    But the main reason some trees didn't get pulled was that they
    generated long flame-wars, and I just felt like I really didn't need
    the aggravation this time around, especially as I knew I had plenty
    other trees to pull.

    What *did* get pulled? A lot. The diffstat is huge, and is full of
    renames. The network drivers got re-organized, which is a big chunk of
    the renames, but there are architecture cleanups and re-organizations
    there too (UML and some arm sub-architectures, for example) adding
    their own set of renames. Along with some staging drivers that got
    upgraded to non-staging etc etc.

    Which brings me to a question I already asked on G+ - do people really
    need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
    and part of the reason is that all those renames cause big
    delete/create diffs. We *could* use git rename patches, but then you'd
    have to apply them with "git apply" rather than the legacy "patch"
    executables. But as it is, the patch is almost a third of the size of
    the tar-ball, which makes me wonder if there's even any point to such
    a big patch?

    Apart from the re-organization, there is really just a lot of changes
    all over. It's about 75% drivers (and that's without the renames
    counted as big delete/create events - in the traditional diff, more
    than 90% is drivers), 15% arch, and 10% "rest" (mainly fs and net -
    with header file changes showing up in the statistics too).

    What doesn't even show up in the stats is the VM changes, although
    those may well be the most noticeable core stuff. It may be fairly
    small, but it's rather more core, and has the potential to affect
    everybody. People have been working on writeback tuning, and the whole
    IO-less dirty balancing. So now foreground writeback should be a thing
    of the past. Let's see how that all works out.

    Have fun, give it a good testing. There shouldn't be anything hugely
    scary in there, but there *is* a lot of stuff. The fact that 3.1
    dragged out did mean that this ended up being one of the bigger merge
    windows, but I'm not feeling *too* nervous about it.

    Linus


    \
     
     \ /
      Last update: 2011-11-08 03:13    [W:0.083 / U:0.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site