Message-Id: <200711252125.35761.rjw@sisk.pl>
Date:	Sun, 25 Nov 2007 21:25:34 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>,
	Adrian Bunk <bunk@...nel.org>
Subject: Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)

On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> 
> 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).

That's correct, and we generally need to gather it in one place.  Still, I'm
not sure if that should be the Bugzilla.

> 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.

This way we can overlook some bugs unreproducible with the latest-greatest for
whatever the reason, but still present and waiting to bite us when we unhide
them.

> > 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.

Yes, that's one of the things we should fix, IMO.

> > >   - 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".

It usually doesn't.  Anyway, you need to acknowledge the report and asking the
submitter to provide you with additional information doesn't cost that much.

OTOH, if the bug report is not directed at the right person from the start,
it gets redirected and then the reporter is often asked for the information
he's already provided and that's annoying.

> > >   - 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.

I'm sure we can.

In the meantime, there are bug reports coming and they need to be handled
somehow until we finally agree to do that in this or another way. ;-)

> > > * 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.

Every such method will require additional infrastructure needing to be taken
care of by someone.

> > > * 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).

Arguably, the time need not be wasted if it results in the bug being taken care
of sooner.

> [...]
> 
> > > * 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).

Yes, we probably can.

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

Powered by blists - more mailing lists