lkml.org 
[lkml]   [2009]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.6.32-rc3
    Both Ingo and Dirk clarified and amplified my original request,
    that it be easy to trivially tell the difference between stuff
    _based on_ on 2.6.X, and stuff _based on_ the following merge window.

    I fully understand non-linear development, I undersatnd
    and use CONFIG_LOCALVERSION_AUTO, but that isn't sufficient
    to solve the problem I have in my use case.

    In my use-case, I develop on my desktop with a backing git tree.

    When I want to do builds, I throw a tar-ball over the wall
    to a remote compute engine to chew on the tree for a few hours.

    The compute engine runs a relatively time-consuming serialized
    script to discover all of the interesting configs to build.
    It then stores those configs in a unique place associated
    with that release. It doesn't have a backing git tree,
    so it uses the info in the Makefile -- 2.6.X.

    Then the compute engine builds each config, and stores the
    output in the same place -- 2.6.X. On a typical build error,
    I fix, send a new tar file, and unless I've changed Kconfig,
    I kick off the builds without re-generating all the config files.

    Even if I could get it, I generally don't want an exact -g1234
    to identify the release, because 90% of the time I want to re-use
    the config files that I've already built for the snapshot
    the tree is based on without the repeating the time-consuming config
    re-generation step.

    My big problem today is that is that the new 2.6.X results
    overwrites my reference configs for the real 2.6.X.

    This means that if I have a development tree that is based
    on the real 2.6.X (I almost always do), as soon as I build
    a merge window kernel, I've lost all the golden configs
    that I may want to re-use for my branch that is based
    on the real 2.6.X

    This also means that I've overwritten all of the
    reference build results.

    Maybe this use-case is stupid and simple-minded, but I'm
    sure there are more stupid and more simple-minded use cases
    out there that would benefit from immediately knowing the
    difference in the Makefile between something based on 2.6.X
    and something based on the following merge window.

    thanks for listening.

    -Len






    \
     
     \ /
      Last update: 2009-10-06 19:55    [W:4.094 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site