lkml.org 
[lkml]   [2007]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subjectkernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
    Date

    [ I removed Frans from cc: since it is off-topic to the original bugreport ]

    On Saturday 24 November 2007, Rafael J. Wysocki wrote:
    > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
    > [--snip--]
    > > Rafael, I see that you've filled a bug for this bugreport into kernel
    > > bugzilla tracker (one day after the bugreport):
    > >
    > > http://bugzilla.kernel.org/show_bug.cgi?id=9442
    > >
    > > Since we try to address regressions with the highest priority in the
    > > IDE-land (and usually they get fixed quickly) I would strongly prefer to
    > > use bugzilla only for long-term bugs and avoid the needless bureaucracy.
    >
    > As a rule, I put all of the reported regressions into the Bugzilla early. You
    > are not required to use these entries for tracking the bugs, though. If you

    [ I really don't think that the recent push from both Andrew and you in
    bugzilla direction is a good thing... ]

    There is a mix of technical and psychological issues with using bugzilla:

    * Interface for filling bugs is a joke:
    - help for "Product" selection is mediocre
    ("IO/Storage:" -> "Bugs related to IO")
    - there is no help for "Componenet" selection
    - "Some basic debugging hints" are not there
    - "Kernel version" given by reporter should be checked against the latest
    kernel version and if not matching there should be a kind request to
    retest with the latest kernel
    - it should be strongly suggested to attach dmesg output and kernel config
    - zillion other little improvements...

    [ The average bug quality is not very high (bugs often lack critical
    information) and this is really not reporters' fault! The interface
    should be kept as simple as possible but if the reporter wants to
    find some help and hints they should be there. ]

    * Bugs that sit in NEEDINFO state for more than i.e. one month should be
    automatically closed.

    * After each major kernel release bugzilla should send a kind request for
    retesting to all open bugs.

    * You can't close/reject bugs by email.

    * There is "Assigned-to:" field which is described as "This is the person in
    charge of resolving the bug." in bugzilla's help so people get assumptions
    that there is somebody who is supposed to handle the bug and that this
    person should be actively working on it. Both assumptions may be invalid
    (orhpaned drivers, there are more high priority bugs etc.). OTOH mailing
    list doesn't give such assumptions and encourages more active attitudes
    of bugreporters.

    [ also compare this with "Maintained" definition in MAINTAINERS file ]

    * From maintainer/developer POV you really want to track bugs in public
    (mailing list) so other people can jump in and help.

    [ It is also important that the other developers see that you are active. ]

    * We want bug tracking the other way around: everything goes through mailing
    list first (including bugs filled to the bug tracker) and if not fixed
    quickly, somebody (maintainer of the given part of code or a higher level
    maintainer) replies cc:ing bugzilla so the new bug entry is added.

    Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
    without any bugzilla overhead. We also add a new patch description tags:
    - "Fixes-bug:" tag with reference to the original discussion
    and
    - "Fixes-commit:" tag with reference to the kernel commit
    which are automatically snooped by bugzilla from git so we keep info about
    fixed bugs/regression for statistics, bugs history and to aid -stable team
    in their efforts.

    [ This is just a blurry sketch of the desired workflow but please note how
    this is different from just assigning your component to the mailing list
    address which should already be possible. ]

    * Last but not least our bugzilla just looks ugly (it is _very_ important,
    I feel disgusted each time I have to work with it, OTOH I love using
    gitweb - you get the idea).

    Sigh, I've just realized that comparing to source code control we are in
    the "stone-age" when it comes to bug tracking. Hmm, what about switching
    to some proprietary bug tracking system just to talk Linus into writing
    a superior one? ;-)

    > don't want to, just leave the entry as is and I'll close it when the fix is in
    > the Linus' tree.

    > > Therefore I kindly ask you to defer filling bugs for new bugreports for
    > > a week or two, and give us some time to react (and always ping me about
    > > the bugreport status before filling bugzilla entry).
    >
    > Well, I thought you'd get an email from the Bugzilla, but of course I can notify
    > you directly about reported regressions related to IDE.

    I do get mails from bugzilla so if you are going to assign these bugs to
    yourself and track them, then no need to notify me.

    [ I also regularly read your regressions list. ]

    > > The alternative solution would be that you fill all new bugreports but
    > > then please assign them to yourself and track their status (if after two
    > > weeks the problem is not fixed feel free to reassign bug to me).
    >
    > I can do that, but please note that the bugs filed against IDE are assigned to
    > you automatically, so I'll have to reassign them to me (as I've just done with

    Thank you.

    > this particular entry). If you don't want them to be assigned to you at all,
    > please contact the Bugzilla administrators and ask them to change that.

    Well, I consider this from time to time...

    Bart
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-25 01:23    [W:0.034 / U:29.936 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site