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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
