Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

Hi,

On Sunday 25 November 2007, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > 
> > [ 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... ]
> 
> Well, I use the Bugzilla as a tool for tracking regressions.
> 
> You don't need to use or even follow the entries created by me, but some
> people do with good results.
> 
> > 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")
> 
> Here, I agree, but IMO that's an organizational issue.  We first should assign
> people to handling bugs related to various subsystems and based on that create
> the menu so that the right people are notified of the reports.
> 
> >   - there is no help for "Componenet" selection
> >   - "Some basic debugging hints" are not there
> 
> It looks like you'd like the reporter to initially debug the issue for you
> before actually reporting it.  I don't think it's realistic. ;-)

Give people right hints and tools and they will work miracles. ;-)

If user reports hard lockup propably the first thing to ask will be
to try NMI watchdog etc.  We have this kind of information spreaded
through various files in Documentation/ (and also other sources).

What we right now we have in bugzilla is:

"
Some basic debugging hints

    * Diagnosing OOM conditions
    * Debugging kernel hangs
    * Setting up a serial console
"

[ at http://test.kernel.org/bugzilla/faq.html ]

and all entries end up with "This page does not exist yet. You can create
a new empty page, or use one of the page templates. Before creating the
page, please check if a similar page already exists."

> >   - "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
> 
> Why?

To speedup a process.

> If someone has a problem with 2.6.23.x which has already been fixed in the
> mainline, we should be able to point him to the fix.  If we aren't, then
> something is wrong on our side.

Sure there is something wrong on our side as we don't store this kind of
information in organized way currently.

> >   - it should be strongly suggested to attach dmesg output and kernel config
> 
> I, personally, don't like reports with dmesgs and .configs attached from the
> start, especially if they are cut'n'pasted into the message window, because

I do.

> they often don't contain the relevant information.

If you are lucky the right information will be there and it will save both
reporter and the developer one "communication cycle".

> >   - zillion other little improvements...
> 
> Sure, improvements are always possible. :-)
> 
> >   [ 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. ]
> 
> IMO, if there's a user who has a problem with _our_ code, we should do our best
> to help him even if he doesn't report the bug very well.  Also, if the problem
> is not with the most recent kernel, we should at least ask the reporter to try
> a newer version.

Fully agreed.

I rather meant that the we can make the process work better for both sides.

> > * Bugs that sit in NEEDINFO state for more than i.e. one month should be
> >   automatically closed.
> 
> I agree that we probably should do something like this.
>  
> > * After each major kernel release bugzilla should send a kind request for
> >   retesting to all open bugs.
> 
> Good idea, IMO.
> 
> > * You can't close/reject bugs by email.
> 
> Well, how would you authenticate?

Technically it is not a problem at all, i.e. you can sign mail with GPG etc.

> > * 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.).
> 
> True and that's why I think there should be some poeple officially resposnible
> for handling bugs (which involves talking with the reporter and forwarding the
> bug to an appropriate developer if necessary etc.).
> 
> >   OTOH mailing list doesn't give such assumptions and encourages more active
> >   attitudes of bugreporters.
> 
> Nothing prevents bugreporters from sending emails along with filing Bugzilla
> reports.

Duplicating efforts is not good thing (wasted time).

[...]

> > * 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).
> 
> Well, that doesn't matter to me as long as it's useful.  Any ideas how to
> improve that? ;-)

Well, I hope that we can use some help from distro people here
(many distros have bugzillas superior to our).

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/