linux-kernel - Re: A proposal; making 2.6.20 a bugfix only version.

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]

Date:	Sat, 11 Nov 2006 20:15:19 +0100
From:	Adrian Bunk <bunk@...sta.de>
To:	Stephen Hemminger <shemminger@...l.org>
Cc:	Jesper Juhl <jesper.juhl@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: A proposal; making 2.6.20 a bugfix only version.

On Fri, Nov 10, 2006 at 08:42:58AM -0800, Stephen Hemminger wrote:
>...
>  * Old bugs die, the bugzilla database needs a 6mo prune out.

That's not that much of a problem.

There is me and there are some other people who sometimes go through 
older bugs asking submitters whether the issue is still present in a 
recent kernel.

And if it is not or the submitter doesn't answer the bug gets closed a 
few weeks later.

The problem with this approach is what to do when the bug is still 
present - it's quite unfair to ask a submitter whether a bug is still 
present, but having no way to help the submitter if he confirms it's 
still present.

A positive example is e.g. sparc: davem doesn't use Bugzilla, but when I 
forward bugs to him from Bugzilla I know that there will be an answer.

But for other subsystems like e.g. ext3 I don't know about anyone who 
will answer every time I forward a bug that is still present in the 
latest kernel.

>  * Bugzilla.kernel.org is underutilized and is only a small sample of the
>    real problems. Not sure if it is a training, user, behaviour issue or
>    just that bugzilla is crap.

At least one positive thing about Bugzilla is that it shows how bad our 
bug handling is - bug reports noone took care of are visible...

>  * Vendor bugs (that could be fixed) aren't forwarded to lkml or bugzilla

We do already get more bug reports than we can handle.

As an example, until recently people were spreading the fairy tale noone 
would test -rc kernels. So I started a list of reported regressions by 
people who did test the -rc kernels, and this shows that we are even far 
away from handling recent regressions within one or two weeks - and the 
situation with other bugs looks much worse.

>  * LKML is an overloaded communication channel, do we need:
>      linux-bugs@...r.kernel.org ?

The problem is not how to communicate bugs - the problem is who will 
look after the bugs.

As an example, Andrew is already doing a great job in forwarding bugs 
from Bugzilla and linux-kernel to maintainers. It's not that maintainers 
miss bugs because they don't see them.

>   * Developers can't get (or afford to buy) the new hardware that causes
>      a lot of the pain. Just look at the number of bug reports due to new
>      flavors of motherboards, chipsets, etc. I spent 3mo on a bug that took
>      one day to fix once I got the hardware.

If only this was the only problem...

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/