lkml.org 
[lkml]   [2023]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: AUTOSEL process
    On Sat, Mar 11, 2023 at 10:54:59AM -0800, Eric Biggers wrote:
    > On Sat, Mar 11, 2023 at 01:26:57PM -0500, Sasha Levin wrote:
    > >
    > > "job"? do you think I'm paid to do this work?
    >
    > > Why would I stonewall improvements to the process?
    > >
    > > I'm getting a bunch of suggestions and complaints that I'm not implementing
    > > those suggestions fast enough on my spare time.
    > >
    > > > One of the first things I would do if I was maintaining the stable kernels is to
    > > > set up a way to automatically run searches on the mailing lists, and then take
    > > > advantage of that in the stable process in various ways. Not having that is the
    > > > root cause of a lot of the issues with the current process, IMO.
    > >
    > > "if I was maintaining the stable kernels" - why is this rellevant? give
    > > us the tool you've proposed below and we'll be happy to use it. Heck,
    > > don't give it to us, use it to review the patches we're sending out for
    > > review and let us know if we've missed anything.
    >
    > It's kind of a stretch to claim that maintaining the stable kernels is not part
    > of your and Greg's jobs. But anyway, the real problem is that it's currently
    > very hard for others to contribute, given the unique role the stable maintainers
    > have and the lack of documentation about it. Each of the two maintainers has
    > their own scripts, and it is not clear how they use them and what processes they
    > follow.

    Just a comment here about our scripts and process.

    Our scripts are different as we both currently do different things for
    the stable trees. I have almost no scripts for finding patches, all I
    use is a git hook that dumps emails into a mbox and then go through them
    and queue them up to the quilt trees based on if they are valid or not
    after review.

    My scripts primarily are for doing a release, not building the patches
    up.

    That being said, I do have 2 scripts I use to run on an existing tree or
    series to verify that the fixes are all present already (i.e. if we have
    fixes for the fixes), but that's not really relevant for this discussion.

    Those, and my big "treat the filesystem as a git database" hack can be
    found in this repo:
    https://git.sr.ht/~gregkh/linux-stable_commit_tree/
    if you are curious, these are probably the relevant scripts if you are
    curious:
    https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/find_fixes_in_queue
    https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/find_fixes_in_range

    And I use:
    https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/id_found_in
    all the time to determine if a SHA1 is in any stable releases.

    > (Even just stable-kernel-rules.rst is totally incorrect these days.)

    I do not understand this, what is not correct?

    It's how to get patches merged into stable kernels, we go
    above-and-beyond that for those developers and maintainers that do NOT
    follow those rules. If everyone followed them, we wouldn't be having
    this discussion at all :)

    > Actually I still don't even know where your scripts are! They are not in
    > stable-queue/scripts, it seems those are only Greg's scripts? And if I built
    > something, how do I know you would even use it? You likely have all sorts of
    > requirements that I don't even know about.

    I think what you are talking about here would require new work. New
    tools to dig in the commits to extract "here's the whole series of
    patches" would be wonderful, but as others have pointed out, it is
    _very_ common to have a cc: stable as the first few commits in a series,
    and then the rest have nothing to do with a stable tree.

    But when doing something like what AUTOSEL does, digging up the whole
    series would be great. We have tools that can match up every commit in
    the tree to a specific email message (presentations on the tool and how
    it works have been a previous LinuxCon conferences), but if we can use
    lore.kernel.org for it, that would probably help everyone out.

    And that's why I use the Link: tag, as Ted pointed out, for everything
    that I apply to all of the subsystems I work with. While I know Linus
    doesn't like it, I think it is quite valuable as it makes it so that
    _anyone_ can instantly find the thread where the patch came from, and no
    external tools are required.

    Anyway, as always, I gladly accept help with figuring out what commits
    to apply to stable kernels. I've always said this, and Sasha has
    stepped up in an amazing way here over the years, creating tools based
    on collaboration with many others (see his presentations at conferences
    with Julia) on how to dig into the kernel repo to find patches that we
    all forget to tag for stable kernels and he sends them out for review.

    If you want to help out and do much the same thing using different sorts
    of tools, or come up with other ways of finding the bugfixes that are in
    there that are not properly tagged, wonderful, I will gladly accept
    them, I have never turned down help like this.

    And that's what I ask from companies all the time when they say "what
    can we do to help out?" A simple thing to do is dig in your vendor
    trees and send me the fixes that you have backported there. I know
    distros have this (and some distros help out and do this, I'll call out
    Debian for being very good here), and some companies do submit their
    backports as well (Amazon and Hawaii are good, Android also does a good
    job), but they are rare compared to all of the groups that I know use
    Linux.

    Anyway, if anyone noticed the big problems this weekend with the stable
    releases were due to patches that were actually tagged with "cc: stable"
    so that's kind of proof that we all are human and even when we think a
    fix is enough, it can cause problems when it hits real world testing.

    We are all human, the best we can do is when confronted with "hey, this
    fix causes a problem" is revert it and get the fix out to people as
    quick as possible. That includes fixes picked from tools like AUTOSEL
    as well as manual tags, there is no difference here in our response.

    thanks,

    greg k-h

    \
     
     \ /
      Last update: 2023-03-27 00:57    [W:2.627 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site