lkml.org 
[lkml]   [2022]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"
    On 04.10.22 19:53, Konstantin Ryabitsev wrote:
    > On Thu, Sep 29, 2022 at 01:19:24PM +0200, Thorsten Leemhuis wrote:
    >> TLDR: Core Linux kernel developers are unhappy with the state of
    >> bugzilla.kernel.org; to improve things I plan to change a few important
    >> aspects of its configuration, unless somebody comes up with better ideas
    >> to tackle current problems: (1) Create a catch-all product making it
    >> totally obvious to submitters that likely nobody will look into the
    >> ticket. (2) Remove or hide all products & components where the subsystem
    >> didn't fully commit to look into newly submitted reports. (3) Change the
    >> text on the front page to make it clear that most kernel bug reports
    >> need to be sent by mail.

    So, merge window is over. To avoid any doubt, I'd now like to get a
    clarification what the outcome of this discussion actually is.

    FWIW, as most of you likely know, lwn.net has a write-up of this thread:
    https://lwn.net/Articles/910740/

    > Here's my counter-plan, which builds on top of yours.

    Is this the agreed on path forward by silent agreement? And if so: who
    will actually shepherd this? I just wonder, as it sounded to me that
    Konstantin would be happy to take care of the bot-related stuff, but
    leave the rest to somebody else.

    Or do we have two proposals on the table that are kind of deadlocked so
    that nothing will happen until the next maintainers summit, where things
    like this are usually discussed and a way forward agreed on? Then the
    ugly situation with bugzilla.kernel.org would continue for afaics at
    least 11 more months, which I'd call "unfortunate". :-/

    Ciao, Thorsten

    > 1. Create a Kernel/Kernel product that acts as a starting point for all bug
    > submissions.
    > 2. Create and maintain a mapping from MAINTAINER subsystem entries to
    > Product/Component categories in Bugzilla (the scheme to be established).
    > 3. Establish and maintain a team of designated triage people who are willing
    > to look at incoming bugs to either:
    >
    > a. quick-close them as non-actionable (tainted kernel, distro kernel, spam)
    > b. obtain missing information from the submitter as necessary
    > c. figure out the correct component to assign, to the best of their ability
    > d. set a "triaged" flag
    >
    > 4. a backend monitoring bot will track all bug changes and, when it sees a bug
    > get the "triaged" state, it will:
    >
    > a. create a useful bug summary from all bug comments
    > b. figure out who to notify based on the mapping (see #2 above)
    > c. send out the email to everyone identified
    >
    > 5. the same backend monitoring bot will track responses and update the bug
    > comments as needed; any comments added via the bugzilla site will be
    > similarly sent out as follow-up messages.
    >
    > 6. the bot can also monitor commits and other discussions via lore.kernel.org
    > and automatically add comments/links when it sees the bug mentioned
    > elsewhere.
    >
    > I'm happy to take care of everything bot-related (apparently, programming bots
    > is what I do now -- I just wish it was the cool and glamorous kind).
    >
    > As I have stated multiple times, the hard part will be keeping a team of
    > people who are willing to do the bug triage work, but maybe we can start with
    > Greg KH using his intern funds to hire someone (assuming he's not already
    > using these funds for someone to help him with all the other tasks).
    >
    > Does that sound like a plan for everyone?
    >
    > -K

    \
     
     \ /
      Last update: 2022-10-17 15:58    [W:4.074 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site