On Thu, Jun 14, 2007 at 07:30:49PM +0200, Adrian Bunk wrote:
quoted text
> On Thu, Jun 14, 2007 at 06:39:23PM +0200, Oleg Verych wrote:
[]
quoted text
> > I know, that most developers here are not working/familiar with what
> > Debian has as its bug shooting weapon ``The system is mainly controlled
> > by  e-mail, but the bug reports can be viewed using the WWW.''[0].
> > 
> > I thought somebody, who familiar with that, might propose to setup/tune
> > it, but not doing yet another NIH thing, especially from e-mail
> > integration POV. I doubt mozilla guys can think about it without
> > javascript and/or java servlets :)
> >...
> 
> The problem isn't Bugzilla, and the Debian BTS wouldn't solve any 
> problem.
> 
> What is missing?
> 
> We need people who know one or more subsystems and who are willing to 
> regularly handle bug reports in their area.

I think if somebody, by example will show how it can be handled in more
convenient way, that will eventually become mainstream. As we know,
nothing gets from vacuum just like that, without taking energy and time.
And my question was not about this social problem of acceptance, support
etc.

Linus had spent some time in this thread trying to explain what problems
are: as from that (social, think scheduler :) POV, as also from
"zarro bogs found" one.

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.

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.

Thus it's just my curiosity about all this. And BTS is like, you know,
why not, if it fits by mostly all parameters?

[0] Message-ID: <handler.s.C.118074292516912.transcript@bugs.debian.org>
    Xref: news.gmane.org gmane.linux.debian.devel.kernel:29426
    Archived-At: <http://permalink.gmane.org/gmane.linux.debian.devel.kernel/29426>


quoted text
> 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.
____
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/