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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

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.

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.

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

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

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

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.

>...
> Greetings,
> Rafael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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