linux-kernel - Re: regression tracking (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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 16 Jun 2007 15:25:57 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Oleg Verych <olecom@...wer.upol.cz>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Diego Calleja <diegocg@...il.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: regression tracking (Re: Linux 2.6.21)

On Sat, Jun 16, 2007 at 07:03:44AM +0200, Oleg Verych wrote:
>...
> On Sat, Jun 16, 2007 at 04:55:16AM +0200, Adrian Bunk wrote:
> > On Sat, Jun 16, 2007 at 03:32:36AM +0200, Oleg Verych wrote:
> > > On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
>...
> > > For example you feel, that you've wasted time. But after all, if you've
> > > came up with some kind of tool, everybody else could take it. No
> > > problems, useful ideas must and will evolve. But _ideally_ this must not be
> > > from ground zero every time. _Ideally_ from technical, not personal
> > > point of view ;).
> > 
> > As I expected, someone else has picked up regression tracking.
> > And other from what you claim, this did not require any kind of tool.
> 
> So you expected good, doing bad. ``Bad'' means bringing pointless flame
> about what everybody should do, without constructive approach like: "OK,
> i can't do it due to my POV{0}, useless manual work. Everybody willing to
> bring another way of dealing with it is welcome."
> 
> Your first reply:
> 
> "And it's not that Linus started developing the Linux kernel with writing
> git, the first 10 years of Linux development were without any SCM." {3}
> 
> to my note about, that you are not hurry anywhere, that after all that
> years of Open Source and Free Software development you are not trying
> to deal with such important thing like regression/bug tracking in
> ***organized way***, is rather pointless.

I am dealing with bug tracking in the kernel Bugzilla.
I did regression tracking for the kernel.
Michal is currently tracking regressions.
Andrew is doing an enormous amount of work in these areas.

You might not see it because you are not active in this area, but it is 
working in an organized way.

What is not working is getting all tracked bugs properly debugged.

> > > That's why people in Debian have started *team* maintenance with alioth. 
> > 
> > The problem for the Linux kernel is that for a better bug handling you'd 
> > need people willing to learn other people's code and to do the hard work 
> > of debugging bug reports.
> 
> ... {0}++
> 
> Do you know, for example, why i'm not making my "hacker's career"
> doing that?
> 
> 1. because i ended up with lynx, slrn, mutt, emacs-nox. Including
>    "zarro bogs found" kind of thing and other "userspace suck" problems.
> 2. i have no way to know if something *really* broken, unless it right
>    on my hardware
> 
> This all unlike Debian BTS using reportbug, where you have basic
> information, mbox format messages for easy "mutt -f", and other funny
> things, real maintainers aware of (i'm trying to know, learn about).
> 
> Thus organized, non brain-damaged way of reporting and tracking is the
> key issue.

Bugzilla is a usable tool for bug and regression reporting and tracking 
tracking.

I am using the Debian BTS since 8 years and I've used many Bugzillas.

Both are usable, and the real problem in kernel development is not 
really related to the question which tool to use for bug tracking.

>...
> > Talking about "team maintenance" sounds nice, but the problem in the 
> > kernel starts with code that has zero maintainers.
> 
> Floppy went pretty fine, before it was started to be maintained, and
> you know that. But you also told that unmaintained and not-working are
> different things.

unmaintained != unused
user != developer
worked != went pretty fine

Stuff can easily get broken and noone looks after bugs if there's no 
maintainer both knowing the code and willing to debug bugs.

The floppy driver is actually an example of code that has been broken 
quite often by patches simply because noone who completely understands 
this driver reviewed patches.

It somehow works and it might work for some years, but there is a 
problem.

>...
> I see (this repetition). Maybe i've managed to express my POV, that it
> can be seeing more cleanly.

IMHO your point of view is simply not related to the real current 
quality problems in kernel development.

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/