linux-kernel - Re: Linux 2.6.21

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:	Sun, 29 Apr 2007 02:40:35 +0200
From:	"Markus Rechberger" <mrechberger@...il.com>
To:	"Bob Tracy" <rct@...rkin.frus.com>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Adrian Bunk" <bunk@...sta.de>,
	"Diego Calleja" <diegocg@...il.com>,
	"Chuck Ebbert" <cebbert@...hat.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.21

On 4/29/07, Bob Tracy <rct@...rkin.frus.com> wrote:
> Linus Torvalds wrote:
> > On Sun, 29 Apr 2007, Markus Rechberger wrote:
> > > How else should bugs get handled, sending them to the lkml?
> >
> > Actually, looking at Adrian's regression lists, yes. lkml worked better
> > than bugzilla did. By at _least_ a factor of two.
>
> Since 1992, lkml (with "Cc:" to the appropriate subsystem mailing list
> if applicable) and the presumed responsible parties are the only channels
> I've used to report the bugs I encounter.
>

since there are subsystems out there which are managed separatly this
doesn't work out.
I wasn't happy when I noticed that patches got applied to the
sourcecode I contributed without notifying me while I still worked on
that code separatly
It was moreover the fault of the subsystem maintainer to not notify me
back then but a centralized bugreporting (as bugzilla) tool would at
least have notified me, or I would have been able to see the suggested
changes there.

But I agree with that if you're only 1 level far away from the linux kernel.

> Other methods come and go, but old habits die hard, particularly when
> they have a knack for producing the desired result.  Historically,
> requiring a developer to fire up a GUI to read a bug report decreases
> the chance that bug report will be noticed.  The development community
> can do whatever flips its collective switch as far as tracking bugs,
> but the bugs have to be reported and noticed before tracking becomes a
> meaningful activity.
>
> One more thought and I'll get off your screens...  We've steadfastly
> resisted making lkml and friends subscriber-only mailing lists precisely
> because we don't want to miss a potential bug report because a would-be
> submitter isn't subscribed.  If people aren't looking for bug reports
> here, what's the point?
>

it's just easy to miss something here, if an ext3 bug comes in and all
people who're involved in the ext3 filesytem are on vacation I'm sure
they won't read all the mails which came in during a week, now take a
part of the kernel which is smaller than the ext3 filesystem (eg. usb
gadgets, smaller drivers)

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