[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070614204610.GV3588@stusta.de>
Date: Thu, 14 Jun 2007 22:46:10 +0200
From: Adrian Bunk <bunk@...sta.de>
To: Oleg Verych <olecom@...wer.upol.cz>
Cc: Stefan Richter <stefanr@...6.in-berlin.de>,
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 Thu, Jun 14, 2007 at 10:33:38PM +0200, Oleg Verych wrote:
>...
> Also, after i saw Linus' message about doing mostly tools last couple of
> years, i wonder why you, Adrian, didn't think about your tools first,
> before you've started regression tracking? You are not running in front
> of a train, unlike you know who does, plus bugzilla issues are known for
> years. Luckily Fedora kernel guys also upstream developers, thus lkml and
> other MLs under their view.
My tool was a textfile with a text editor.
For a smaller amount of regressions that works fine.
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.
> After having read all that, i've asked you, my question, as the person
> who supposedly used BTS as a maintainer.
>
> Yes, in current form it might not be in suitable configuration, i.e.
> kernel sub-systems instead of packages etc, anyway main thing is the way
> BTS is handled. While i was looking and replying for bug reports in the
> Debian kernel, that i saw in lkml, i've noticed, just how guys work with
> it there. Now they even came up with tracking upstream bugzilla, it
> seems [0]. I left that activity due to RL some months ago, but now trying
> to catch up things again.
>...
Both the Debian BTS and Bugzilla are usable programs with their own
advantages and disadvantages.
I don't believe switching to the Debian BTS would solve any problem.
> > And we need a release process that makes debugging, and if possible
> > fixing, all regressions prior to the release mandatory. You might never
> > come down to zero regressions and might not be able to handle all
> > last-minute reported regressions, but the 2.6.21 situation with 3 week
> > old known regressions not ever being debugged by a kernel developer
> > before the release has much room for improvements.
> >
> > Changing the BTS would make sense if some core developers would state
> > that they would start using the BTS after this change. But otherwise it
> > doesn't matter which BTS to use.
>
> So, as i've wrote before: one must give them pretty-shiny tool, kindly
> barking in their inboxes, instead of for example
>
> "Guilty: **** ***** <????@...*.com>",
>
> as it was on the very beginning.
A pretty-shiny tools wouldn't change anything.
What you need are humans debugging the regresssions and humans remining
other humans that they should debug the regressions.
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/
Powered by blists - more mailing lists