lkml.org 
[lkml]   [2009]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.6.29


    On Fri, 27 Mar 2009, Mike Galbraith wrote:
    > >
    > > If you're using the kernel-of-they-day, you're probably using git, and
    > > CONFIG_LOCALVERSION_AUTO=y should be mandatory.
    >
    > I sure hope it never becomes mandatory, I despise that thing. I don't
    > even do -rc tags. .nn is .nn until baked and nn.1 appears.

    If you're a git user that changes kernels frequently, then enabling
    CONFIG_LOCALVERSION_AUTO is _really_ convenient when you learn to use it.

    This is quite common for me:

    gitk v$(uname -r)..

    and it works exactly due to CONFIG_LOCALVERSION_AUTO (and because git is
    rather good at figuring out version numbers). It's a great way to say
    "ok, what is in my git tree that I'm not actually running right now".

    Another case where CONFIG_LOCALVERSION_AUTO is very useful is when you're
    noticing some new broken behavior, but it took you a while to notice.
    You've rebooted several times since, but you know it worked last Tuesday.
    What do you do?

    The thing to do is

    grep "Linux version" /var/log/messages*

    and figure out what the good version was, and then do

    git bisect start
    git bisect good ..that-version..
    git bisect bad v$(uname -r)

    and off you go. This is _very_ convenient if you are working with some
    "random git kernel of the day" like I am (and like hopefully others are
    too, in order to get test coverage).

    > (would be nice if baked were immediately handed to stable .nn.0 instead
    > of being in limbo for a bit, but I don't drive the cart, just tag along
    > behind [w. shovel];)

    Note that the "v2.6.29[-rcX" part is totally _useless_ in many cases,
    because if you're working past merges, and especially if you end up doing
    bisection, it is very possible that the main Makefile says "2.6.28-rc2",
    but the code you're working on wasn't actually _merged_ until after
    2.6.29.

    In other words, the main Makefile version is totally useless in non-linear
    development, and is meaningful _only_ at specific release times. In
    between releases, it's essentially a random thing, since non-linear
    development means that versioning simply fundamentally isn't some simple
    monotonic numbering. And this is exactly when CONFIG_LOCALVERSION_AUTO is
    a huge deal.

    (It's even more so if you end up looking at "next" or merging other
    peoples trees. If you only ever track my kernel, and you only ever
    fast-forward - no bisection, no nothing - then the release numbering looks
    "simple", and things like LOCALVERSION looks just like noise).

    Linus


    \
     
     \ /
      Last update: 2009-03-27 17:07    [W:0.025 / U:1.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site