[lkml]   [2010]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectThe gregkh patch scripts

    Are the scripts you use for creating the various gregkh-*.patch files
    stored in

    ? Those files appear not to have been updated for quite some time.

    Regardless, the way the current scripts work has got a problem. As far
    as I can tell, they take Linus's current tree, apply your various
    accumulated quilt series files, and then compute the diff between the
    end result and the starting point. The output is labelled with name of
    the starting tree. (If my understanding is wrong then tell me so and
    ignore the rest of this message.)

    The problem is that Linus's current tree is not a good starting point.
    For example, right now several of the individual files such as
    gregkh-07-usb-2.6.33.patch are completely empty. This is because you
    have sent all the pending changes upstream, so they are now included in
    Linus's tree and hence they don't show up in a diff.

    But... The file is still named "gregkh-07-usb-2.6.33.patch", even
    though it isn't a patch against 2.6.33 -- it's a patch against whatever
    Linus's tree happened to contain at the time you ran the script.
    Since I don't know what tree that was (and I don't have git repository
    for the kernel anyway), I can't use the patch file. (Well, I _can_ use
    it because it's empty, but it doesn't do me any good -- the principle
    is still valid.)

    As Linus has explained to quite a few people, this isn't a good way to
    operate. What your scripts do is essentially the same as rebasing a
    publicly-exported git repository, which should be done relatively
    infrequently. It's okay to rebase against the actual releases and the
    *-rcN trees, because they are well-defined intermediate points. But
    rebasing against a *-rcN-gitM should be quite rare, and rebasing
    against anything else is basically forbidden.

    This means the scripts shouldn't start with the vanilla
    tree-of-the-moment. They should start with the most recent release or
    -rcN tag. In rare cases they could use an rcN-gitM tag, but only if
    there's a good reason.

    So for example, the current gregkh-*-2.6.33.patch files should be quite
    large, because they should contain all the accumulated development for
    the last three months that hasn't gotten into 2.6.33. When 2.6.34-rc1
    is released then the files should get small, since they would then
    contain only material that was submitted slightly before or during the
    merge window.

    Can the scripts be updated to work in this way?

    Alan Stern

     \ /
      Last update: 2010-03-07 05:21    [W:0.020 / U:9.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site