On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 02:11:15PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> >...
> > > On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > > > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> >...
> > > - 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.
>
>
> Completely ACK'ed.
>
> Also keep in mind:
>
> Andrew is going through all new bug reports.
> People like Natalie or me also go through new bug reports.
>
> Good bug reports are valuable contributions.
> Bug reporters are humans.
> In my experience, most bug reporters are more than willing to provide
> any kind of information or testing when requested.
>
> And not to forget:
> All the problems with bug report quality are not better when the bug
> report comes via email.
>
>
> > > * 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.
>
> Not automatically.
OK, say "as a rule".
> Often submitters answer the question that led to the NEEDINFO state but
> don't change the state.
>
> And I know this, since going through all bugs in the NEEDINFO state and
> either closing them or removing the NEEDINFO is a simple and not too big
> task I'm sometimes doing.
I think we can set a rule that NEEDINFO bugs with a developer request not
responded to by the reporter for a month are closable. Everyone with
sufficient access rights who spots such a bug can close it.
> > > * After each major kernel release bugzilla should send a kind request for
> > > retesting to all open bugs.
> >
> > Good idea, IMO.
>
> Good idea ... for pissing off bug submitters.
>
> We have many bug reports in the Bugzilla with very responsive submitters
> who wrote very good bug reports but have the bad luck that it's in an
> area without a maintainer looking after the bug.
These are two different issues.
On the one hand, I don't see anything wrong with encouraging bug reporters to
test new kernels, especially if the reported problems depend on hardware, as it
is possible that the bug will get fixed as a result of a loosely related change
(like a fix for another bug etc.). [Still, in such cases it would be good to
identify the change that fixes the problem anyway.]
OTOH, the situations in which good bug reports are not responded to are not
acceptable. There should be a way to make developers take care of _their_
code, because by not doing so they hurt us all, big time.
> >...
> > > [ 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. ]
> >
> > You can always ask on the list, pointing to the Bugzilla entry in question.
>
>
> You can also assign bugs for some component by default to some real or
> dummy address that forwards everything from the Bugzilla bug (starting
> with the initial bug report) to some mailing list.
>
> And when people answer to this email, the answers will be tracked in
> Bugzilla.
Yes.
> > > * 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
> >
> > Alternatively, we can give a Bugzilla link here pointing to the entry which
> > contains a pointer to the original discussion. [This may be more convenient,
> > since some bugs are reported multiple times and tracked separately to the point
> > in which it turns out that they really are the same.]
>
>
> It would be best if bugs would initially be entered in Bugzilla.
The Bugzilla has a considerable "barrier to entry" for new bug reporters, as
it pretends to require them to spend quite a lot of time on the bug report.
Also, some developers do not consider the Bugzilla as a useful thing and
wouldn't like to use it (which is why this thread has appeared, among other
things ;-)).
> If you have a permanent cookie with the Bugzilla authentification in
> your browser the overhead of closing a bug is to click on the link in
> the Bugzilla email plus 2 clicks in the browser.
Sure.
Greetings,
Rafael
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
