RFC: Linux Bug Tracking & Feature Tracking DB

RFC: Linux Bug Tracking & Feature Tracking DB

[Timothy Covell]

I'm sure that this has been proposed and discussed
before, and I'm sure that some of the software houses
like RedHat must do this internally, but here goes again....


First the obvious problem:

Just today, I had a problem with a system lockup on 2.4.16
which was fixed in 2.4.17.  Although, I try to read the changelogs,
most of them are so terse as to be worthless to anyone but the
kernel hackers themselves.   And few people beside the hackers
have time to read through all the patches just in case the pertinant
fix might be there (and if said person could readily do this, he
could probably code his own fixes!)


Present solution:

Kernel hackers spend lots of time reading email and replying.
This requires that kernel hackers are user friendly, can easily
recognize bugs, and easily recall fixes, have lots of time on
their hands, etc.



Proposed Solution:

A kernel bug and feature tracking system.  This would similar
to what you all know (like Bugtraq).   Entries might look something like:

Example bug:

bug #13697
Synopsys: Hard kernel lockup on 2.4.16 with ieee1394 SBP-2.
Solution: Patch file: pdrv54678
            http://patches.linux.org./pub/linux/v2.4/patches/p/drv/54678.diff
Platform: x86
Section: drivers
Subsection: ieee1394
Contact: joe_hacker@linux-ieee1394.sourceforge.net.
Web URL: http://linux1394.sourceforge.net

Note: All patches in 'diff -urc' format.

Example Feature:

Search Results on Keyword: SBP-2 	Platform: x86

Topic: SBP-2
Platform: x86
Section: drivers
Subsection: ieee1394
Support on 2.2.x-2.2.y and 2.4.x-2.4.present
Maturity: 7 (of 10)
Relevant Bug Reports:   #13697, #14999
Contact: joe_hacker@linux-ieee1394.sourceforge.net.
Web URL: http://linux1394.sourceforge.net




The outstanding issues:

1. The maintainer of this DB would need to receive patches
along with patch.lsm and feature.lsm like files from the code 
maintainers.   That means  that Linus, Alan, Marcello, Dave 
Jones, et al.,  might have to be involved.

2. DB would be a high volume site (at least that's the idea!)

3. Would would pay for and maintain it?  (I know, since I'm
the one putting forth the idea, it's mine to run with.  However,
a. I ain't rich.  b. following from a., I have no bandwidth 24kbps
dialup.)




That's my RFC.


timothy.covell@ashavan.org.

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Anuradha Ratnaweera]

On Sat, Dec 29, 2001 at 12:53:39AM -0600, Timothy Covell wrote:
> 
> I'm sure that this has been proposed and discussed before, and I'm sure that
> some of the software houses like RedHat must do this internally, but here
> goes again....
> 
> [...] 
> 
> Proposed Solution:
> 
> A kernel bug and feature tracking system.  This would similar
> to what you all know (like Bugtraq).   Entries might look something like:

I have bought over the domain kernelpatches.org just for this purpose.  Will
be able to release it in a matter of about a week.

Regards,

Anuradha

-- 

Debian GNU/Linux (kernel 2.4.17)

Houston, Tranquillity Base here.  The Eagle has landed.
		-- Neil Armstrong

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Larry McVoy]

On Sat, Dec 29, 2001 at 12:53:39AM -0600, Timothy Covell wrote:
> 1. The maintainer of this DB would need to receive patches
> along with patch.lsm and feature.lsm like files from the code 
> maintainers.   That means  that Linus, Alan, Marcello, Dave 
> Jones, et al.,  might have to be involved.
> 
> 2. DB would be a high volume site (at least that's the idea!)
> 
> 3. Would would pay for and maintain it?  (I know, since I'm
> the one putting forth the idea, it's mine to run with.  However,
> a. I ain't rich.  b. following from a., I have no bandwidth 24kbps
> dialup.)

OK, we've got a prototype of something like this already, I don't claim
it is ready for prime time, but you can go look at it here:

	http://bugs.bkbits.net/bugs.html

You can run queries, etc.  

This is a fairly early version, so be gentle.  The data in it is the
current BitKeeper bug list (feel free to fix some :-)

There are other ways to access the data, both command line and email
are supported.  Long term, I'd like to make the bug db be an NNTP server
so you could do everything via a news reader, which would be bitchin'.

If this is a first order approximation of what you want, we'll host
it here if you like.  We have a T1 line with lots of spare bandwidth
at the moment.  The machine that you are poking at is the same machine
which hosts various BK repos, such as the Linux/PPC trees, Ted's linux24
tree, Ted's e2fsprogs, NTP trees, GregKH's trees, Chris Wright's trees
(he has a 25 tree based on Ted's 24 tree), Rik's VM tree, among others.
We haven't talked about this very much because we don't have all the
nifty sourceforge like indices and statistics, but long term this is
headed towards something somewhat like a distributed sourceforge.
We never liked the centralized model that sourceforge has, it becomes
a single point of failure.

One interesting, perhaps, point is that bugdb is a BitKeeper repository,
which means you can clone it and take *all* of the data with you,
unlike sourceforge.  So if you were to become dependent on this and
we ran out of bandwidth or something, you can clone the bug db and set
up your own bug server elsewhere.  In general, for both databases and
source, that's the approach we want, i.e., we're happy to host it here
to get you started but if you have needs that we can't meet, we'll make
it easy for you to host elsewhere.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Edgar Toernig]

Larry McVoy wrote:
>
> The data in it is the current BitKeeper bug list (feel free to fix
> some :-)

Bah!  Debugging and patching binaries isn't fun!

ET.

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Daniel Phillips]

On December 29, 2001 08:08 pm, Edgar Toernig wrote:
> Larry McVoy wrote:
> >
> > The data in it is the current BitKeeper bug list (feel free to fix
> > some :-)
> 
> Bah!  Debugging and patching binaries isn't fun!

Check the site, he provides the source.

--
Daniel

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Edgar Toernig]

Daniel Phillips wrote:
> 
> On December 29, 2001 08:08 pm, Edgar Toernig wrote:
> > Larry McVoy wrote:
> > >
> > > The data in it is the current BitKeeper bug list (feel free to fix
> > > some :-)
> >
> > Bah!  Debugging and patching binaries isn't fun!
> 
> Check the site, he provides the source.

Just checked it again: no sources.  Only binaries.  None of them
will run on my system.  Last time I asked for the sources my
request was rejected.

ET.

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Larry McVoy]

On Sat, Dec 29, 2001 at 11:52:36PM +0100, Edgar Toernig wrote:
> Daniel Phillips wrote:
> > 
> > On December 29, 2001 08:08 pm, Edgar Toernig wrote:
> > > Larry McVoy wrote:
> > > >
> > > > The data in it is the current BitKeeper bug list (feel free to fix
> > > > some :-)
> > >
> > > Bah!  Debugging and patching binaries isn't fun!
> > 
> > Check the site, he provides the source.
> 
> Just checked it again: no sources.  Only binaries.  None of them
> will run on my system.  Last time I asked for the sources my
> request was rejected.

The only interaction with you that I've ever had, according to my outbox, 
is on Date: Mon, 30 Oct 2000 15:38:43 -0800 where you asked about BK, 
said there wasn't an image for you platform, I asked what platform, and
so far haven't heard back, at least I have no record of it.

Bootstrapping BK on a new platform isn't easy, you need BK to do it, so
we do it by hand for each new platform.  We try and provide images for
all platforms, so it would be nice to know what it is that you have.

And, it would be nice if you raised the issue with us rather than the 
kernel list, they aren't going to build your BK image for you.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Edgar Toernig]

Larry McVoy wrote:
> 
> On Sat, Dec 29, 2001 at 11:52:36PM +0100, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > >
> > > On December 29, 2001 08:08 pm, Edgar Toernig wrote:
> > > > Larry McVoy wrote:
> > > > >
> > > > > The data in it is the current BitKeeper bug list (feel free to fix
> > > > > some :-)
> > > >
> > > > Bah!  Debugging and patching binaries isn't fun!
> > >
> > > Check the site, he provides the source.
> >
> > Just checked it again: no sources.  Only binaries.  None of them
> > will run on my system.  Last time I asked for the sources my
> > request was rejected.
> 
> The only interaction with you that I've ever had, according to my outbox,
> is on Date: Mon, 30 Oct 2000 15:38:43 -0800 where you asked about BK,
> said there wasn't an image for you platform, I asked what platform, and
> so far haven't heard back, at least I have no record of it.

The answer was sent 1 minute after your reply.  Here it is again:

----------------
> Date: Tue, 31 Oct 2000 00:36:40 +0100
> From: Edgar Toernig <froese@gmx.de>
> To: Larry McVoy <lm@bitmover.com>
> Subject: Re: Source of Bitkeeper
> Message-ID: <39FE0608.7C11302E@gmx.de>
> References: <39FE034C.F6658D5A@gmx.de> <20001030153843.C31369@work.bitmover.com>
>
> Larry McVoy wrote:
> >
> > On Tue, Oct 31, 2000 at 12:25:00AM +0100, Edgar Toernig wrote:
> > > is the source code of Bitkeeper somewhere to download?
> > > There's no binary image for my system.  And, I prefer
> > > sources anyway.
> >
> > Which platform is it?
>
> An old linux system with libc5.
>
> Ciao, ET.
------------------

After that I heard nothing more from you.  I got the impression that a
libc5 system was not commercially interesting enough...

> And, it would be nice if you raised the issue with us rather than the
> kernel list, they aren't going to build your BK image for you.

I asked nobody to build a BK image for me.  You are constantly misusing
the lkml as a BK promotion facility.  And when you raise the impression
that sources are available I'll correct that.  Pretty simple.

Ciao, ET.


Reply-To set...

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Larry McVoy]

> After that I heard nothing more from you.  I got the impression that a
> libc5 system was not commercially interesting enough...

Huh.  Well, it's easy enough to add that to the list of build machines, 
I think I can build libc5 binaries on redhat52, and we support that.

> > And, it would be nice if you raised the issue with us rather than the
> > kernel list, they aren't going to build your BK image for you.
> 
> I asked nobody to build a BK image for me.  You are constantly misusing
> the lkml as a BK promotion facility.  

If you feel that way, might I kindly suggest you add a simple rule to your
procmail filters and spare yourself (and the rest of the world) some pain?
I can show you how to do it if you don't know how, it would be no problem.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Timothy Covell]

On Saturday 29 December 2001 12:55, Larry McVoy wrote:
> On Sat, Dec 29, 2001 at 12:53:39AM -0600, Timothy Covell wrote:
> > 1. The maintainer of this DB would need to receive patches
> > along with patch.lsm and feature.lsm like files from the code
> > maintainers.   That means  that Linus, Alan, Marcello, Dave
> > Jones, et al.,  might have to be involved.
> >
> > 2. DB would be a high volume site (at least that's the idea!)
> >
> > 3. Would would pay for and maintain it?  (I know, since I'm
> > the one putting forth the idea, it's mine to run with.  However,
> > a. I ain't rich.  b. following from a., I have no bandwidth 24kbps
> > dialup.)
>
> OK, we've got a prototype of something like this already, I don't claim
> it is ready for prime time, but you can go look at it here:
>
> 	http://bugs.bkbits.net/bugs.html
>
> You can run queries, etc.
>
> This is a fairly early version, so be gentle.  The data in it is the
> current BitKeeper bug list (feel free to fix some :-)
>
> There are other ways to access the data, both command line and email
> are supported.  Long term, I'd like to make the bug db be an NNTP server
> so you could do everything via a news reader, which would be bitchin'.
>
> If this is a first order approximation of what you want, we'll host
> it here if you like.  We have a T1 line with lots of spare bandwidth
> at the moment.  The machine that you are poking at is the same machine
> which hosts various BK repos, such as the Linux/PPC trees, Ted's linux24
> tree, Ted's e2fsprogs, NTP trees, GregKH's trees, Chris Wright's trees
> (he has a 25 tree based on Ted's 24 tree), Rik's VM tree, among others.
> We haven't talked about this very much because we don't have all the
> nifty sourceforge like indices and statistics, but long term this is
> headed towards something somewhat like a distributed sourceforge.
> We never liked the centralized model that sourceforge has, it becomes
> a single point of failure.
>
> One interesting, perhaps, point is that bugdb is a BitKeeper repository,
> which means you can clone it and take *all* of the data with you,
> unlike sourceforge.  So if you were to become dependent on this and
> we ran out of bandwidth or something, you can clone the bug db and set
> up your own bug server elsewhere.  In general, for both databases and
> source, that's the approach we want, i.e., we're happy to host it here
> to get you started but if you have needs that we can't meet, we'll make
> it easy for you to host elsewhere.

Thank you.  That's a kind offer.  I'm taking a look at it right now.  So
your solution might solve the bandwidth issue, but the bigger issue
is what the big guys think, at least as far as I imagined the system.

timothy.covell@ashavan.org.

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Stewart Smith]

What about instead of tracking bugs and if they've been squashed. Why 
don't we build a database of known bugs with different kernel versions. 
i.e. You can go to the site and get a complete list of every single bug 
that people have entered about 2.0.36 you're still running on that box 
under the stairs.

People could then 'vote' on the bug, so we could keep track of what's a 
big problem for a lot of people, and what's something that just one 
person found not to work.

This would also help people pick 'stable' kernels for their own systems.

Kept seperate from kernel development (i.e. bugs never have to be 
'closed') it means that Linus et al wouldn't have to spend half their 
time there (esp if it wasn't the way they wanted to work), unless they 
wanted to of course :)

just my 2 Australian peso



On Saturday, December 29, 2001, at 05:53  PM, Timothy Covell wrote:

>
> I'm sure that this has been proposed and discussed
> before, and I'm sure that some of the software houses
> like RedHat must do this internally, but here goes again....
>
>
> First the obvious problem:
>
> Just today, I had a problem with a system lockup on 2.4.16
> which was fixed in 2.4.17.  Although, I try to read the changelogs,
> most of them are so terse as to be worthless to anyone but the
> kernel hackers themselves.   And few people beside the hackers
> have time to read through all the patches just in case the pertinant
> fix might be there (and if said person could readily do this, he
> could probably code his own fixes!)
>
>
> Present solution:
>
> Kernel hackers spend lots of time reading email and replying.
> This requires that kernel hackers are user friendly, can easily
> recognize bugs, and easily recall fixes, have lots of time on
> their hands, etc.
>
>
>
> Proposed Solution:
>
> A kernel bug and feature tracking system.  This would similar
> to what you all know (like Bugtraq).   Entries might look something 
> like:
>
> Example bug:
>
> bug #13697
> Synopsys: Hard kernel lockup on 2.4.16 with ieee1394 SBP-2.
> Solution: Patch file: pdrv54678
>             
> http://patches.linux.org./pub/linux/v2.4/patches/p/drv/54678.diff
> Platform: x86
> Section: drivers
> Subsection: ieee1394
> Contact: joe_hacker@linux-ieee1394.sourceforge.net.
> Web URL: http://linux1394.sourceforge.net
>
> Note: All patches in 'diff -urc' format.
>
> Example Feature:
>
> Search Results on Keyword: SBP-2 	Platform: x86
>
> Topic: SBP-2
> Platform: x86
> Section: drivers
> Subsection: ieee1394
> Support on 2.2.x-2.2.y and 2.4.x-2.4.present
> Maturity: 7 (of 10)
> Relevant Bug Reports:   #13697, #14999
> Contact: joe_hacker@linux-ieee1394.sourceforge.net.
> Web URL: http://linux1394.sourceforge.net
>
>
>
>
> The outstanding issues:
>
> 1. The maintainer of this DB would need to receive patches
> along with patch.lsm and feature.lsm like files from the code
> maintainers.   That means  that Linus, Alan, Marcello, Dave
> Jones, et al.,  might have to be involved.
>
> 2. DB would be a high volume site (at least that's the idea!)
>
> 3. Would would pay for and maintain it?  (I know, since I'm
> the one putting forth the idea, it's mine to run with.  However,
> a. I ain't rich.  b. following from a., I have no bandwidth 24kbps
> dialup.)
>
>
>
>
> That's my RFC.
>
>
> timothy.covell@ashavan.org.
> -
> 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/
>
------------------------------
Stewart Smith
stewart@softhome.net
Ph: +61 4 3884 4332
ICQ: 6734154

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Dave Jones]

On Sun, 30 Dec 2001, Stewart Smith wrote:

> What about instead of tracking bugs and if they've been squashed. Why
> don't we build a database of known bugs with different kernel versions.
> i.e. You can go to the site and get a complete list of every single bug
> that people have entered about 2.0.36 you're still running on that box
> under the stairs.
> People could then 'vote' on the bug, so we could keep track of what's a
> big problem for a lot of people, and what's something that just one
> person found not to work.

Congratulations, you just invented bugzilla 8)
The only thing I dislike about bugzilla (and lookalikes) is that
someone has to go through them pruning them, updating them etc
and this is a lot of work.
Look at $vendor_of_choice's bugzilla entry for the kernel.
You'll see hundreds, nay, thousands of reports filed.

It's an immense amount of data to track.
Some people have no problem with this, others loath it.

The advantage email has over this are too numerous to list,
but they start with the fact that lots of kernel developers are
lazy[*]. 2-3 keypresses to archive a patch for looking at later/merging
are about the level of involvement thats aimed for.
Having to start a browser, go to the bugzilla site, log in, search/browse
for bugs etc.. way too involved.

Dave.

[*] In the sense that if life can be made easier, it should be.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Stewart Smith]

On Sunday, December 30, 2001, at 10:45  AM, Dave Jones wrote:
> Congratulations, you just invented bugzilla 8)

Not really, bugzilla requires interaction from people to 'accept' a bug, 
and then fix it etc. I'm talking about just logging them. Instead of 
tracking 'things to fix', track 'things that were broken'.

> Having to start a browser, go to the bugzilla site, log in, 
> search/browse
> for bugs etc.. way too involved.

agreed, it's a pain in the arse. plus you can't do it on the road, or on 
the beach with a martini in hand lying next to a beautiful woman (or 
man, if u like 'em :) but I guess not many of us would be thinking of 
kernel code at a time like that.....
------------------------------
Stewart Smith
stewart@softhome.net
Ph: +61 4 3884 4332
ICQ: 6734154

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Dave Jones]

On Sun, 30 Dec 2001, Stewart Smith wrote:

> Not really, bugzilla requires interaction from people to 'accept' a bug,
> and then fix it etc. I'm talking about just logging them. Instead of
> tracking 'things to fix', track 'things that were broken'.

it still requires some dumb^Wpoor sap to go in pruning them,
plus once it gets to a certain point, there will be dupes.
Oh boy will there be dupes. People will check for them first you say?
Some people are _still_ getting "Loop doesn't compile in 2.4.14"
messages.
Why search archives when you can be the 900th person to ask the
same question.  Even Richard Gooch's page for showing whats wrong
with the current kernel and how to fix it to get it to compile
seems to be completly overlooked. Maybe if it were moved to
www.kernel.org people would see it ? *shrug*

> agreed, it's a pain in the arse. plus you can't do it on the road, or on
> the beach with a martini in hand lying next to a beautiful woman (or
> man, if u like 'em :) but I guess not many of us would be thinking of
> kernel code at a time like that.....

*grin* One of my favorite quotes :
"Holiday just means hacking from a different location" -- jgarzik ?

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Richard Gooch]

Dave Jones writes:
> Why search archives when you can be the 900th person to ask the
> same question.  Even Richard Gooch's page for showing whats wrong
> with the current kernel and how to fix it to get it to compile
> seems to be completly overlooked. Maybe if it were moved to
> www.kernel.org people would see it ? *shrug*

This was suggested some months ago, but nothing happened. Firstly, the
www.kernel.org page talks about the mailing list and some archives,
but makes no reference to the list FAQ. That's the first thing that
should be fixed. Talk to HPA to change this.

Secondly, either a copy of the FAQ, or a reference to it under
kernel.org:pub/linux/kernel/ would also be a good idea. Talk to Linus
to change this.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[H. Peter Anvin]

Richard Gooch wrote:

> 
> This was suggested some months ago, but nothing happened. Firstly, the
> www.kernel.org page talks about the mailing list and some archives,
> but makes no reference to the list FAQ. That's the first thing that
> should be fixed. Talk to HPA to change this.
> 


What's the URL?

	-hpa

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Richard Gooch]

H. Peter Anvin writes:
> Richard Gooch wrote:
> > This was suggested some months ago, but nothing happened. Firstly, the
> > www.kernel.org page talks about the mailing list and some archives,
> > but makes no reference to the list FAQ. That's the first thing that
> > should be fixed. Talk to HPA to change this.
> 
> What's the URL?

http://www.tux.org/lkml/

Part of the trailer message for all lkml messages :-)

If you would like a local copy on the kernel.org mirror sites (maybe a
good idea, if you mirror the kernel.org WWW pages), I can
automatically upload new versions of the FAQ at the same time as I
upload to tux.org.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[H. Peter Anvin]

Richard Gooch wrote:

> H. Peter Anvin writes:
> 
>>Richard Gooch wrote:
>>
>>>This was suggested some months ago, but nothing happened. Firstly, the
>>>www.kernel.org page talks about the mailing list and some archives,
>>>but makes no reference to the list FAQ. That's the first thing that
>>>should be fixed. Talk to HPA to change this.
>>>
>>What's the URL?
>>
> 
> http://www.tux.org/lkml/
> 
> Part of the trailer message for all lkml messages :-)
> 
> If you would like a local copy on the kernel.org mirror sites (maybe a
> good idea, if you mirror the kernel.org WWW pages), I can
> automatically upload new versions of the FAQ at the same time as I
> upload to tux.org.
> 


The best would really be for this stuff to be at vger.kernel.org IMO, 
but the easiest is probably to put it in /pub/linux/doc or somesuch...

	-hpa

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Richard Gooch]

H. Peter Anvin writes:
> Richard Gooch wrote:
> 
> > H. Peter Anvin writes:
> > 
> >>Richard Gooch wrote:
> >>
> >>>This was suggested some months ago, but nothing happened. Firstly, the
> >>>www.kernel.org page talks about the mailing list and some archives,
> >>>but makes no reference to the list FAQ. That's the first thing that
> >>>should be fixed. Talk to HPA to change this.
> >>>
> >>What's the URL?
> >>
> > 
> > http://www.tux.org/lkml/
> > 
> > Part of the trailer message for all lkml messages :-)
> > 
> > If you would like a local copy on the kernel.org mirror sites (maybe a
> > good idea, if you mirror the kernel.org WWW pages), I can
> > automatically upload new versions of the FAQ at the same time as I
> > upload to tux.org.
> 
> The best would really be for this stuff to be at vger.kernel.org IMO, 
> but the easiest is probably to put it in /pub/linux/doc or somesuch...

Well, merely shifting the FAQ from www.tux.org to vger.kernel.org
doesn't have any real benefit. The main thing is that the
www.kernel.org page has a link to the FAQ. If you want to have a
"local" mirrored copy that you link to instead (along with a link to
the official version at www.tux.org), I'm fine with that and can
update my push script. Just give me a place to write to.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[H. Peter Anvin]

Richard Gooch wrote:

> 
> Well, merely shifting the FAQ from www.tux.org to vger.kernel.org
> doesn't have any real benefit. The main thing is that the
> www.kernel.org page has a link to the FAQ. If you want to have a
> "local" mirrored copy that you link to instead (along with a link to
> the official version at www.tux.org), I'm fine with that and can
> update my push script. Just give me a place to write to.
> 


master.kernel.org:/pub/linux/docs/lkml/

	-hpa

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Richard Gooch]

H. Peter Anvin writes:
> Richard Gooch wrote:
> 
> > 
> > Well, merely shifting the FAQ from www.tux.org to vger.kernel.org
> > doesn't have any real benefit. The main thing is that the
> > www.kernel.org page has a link to the FAQ. If you want to have a
> > "local" mirrored copy that you link to instead (along with a link to
> > the official version at www.tux.org), I'm fine with that and can
> > update my push script. Just give me a place to write to.
> 
> master.kernel.org:/pub/linux/docs/lkml/

I've updated my script to upload to index.html and re-run it. File is
there now.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Arnaldo Carvalho de Melo]

Em Sun, Dec 30, 2001 at 04:44:00PM -0800, H. Peter Anvin escreveu:
> Richard Gooch wrote:
> 
> >
> >This was suggested some months ago, but nothing happened. Firstly, the
> >www.kernel.org page talks about the mailing list and some archives,
> >but makes no reference to the list FAQ. That's the first thing that
> >should be fixed. Talk to HPA to change this.
> >
> 
> What's the URL?

http://www.tux.org/lkml, IIRC

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Dave Jones]

On Sun, 30 Dec 2001, H. Peter Anvin wrote:

> > This was suggested some months ago, but nothing happened. Firstly, the
> > www.kernel.org page talks about the mailing list and some archives,
> > but makes no reference to the list FAQ. That's the first thing that
> > should be fixed. Talk to HPA to change this.
> What's the URL?

Hmm, didn't Linux-kernel used to have this appended in the footer of
each message ?

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Rob Landley]

On Sunday 30 December 2001 07:44 pm, H. Peter Anvin wrote:
> Richard Gooch wrote:
> > This was suggested some months ago, but nothing happened. Firstly, the
> > www.kernel.org page talks about the mailing list and some archives,
> > but makes no reference to the list FAQ. That's the first thing that
> > should be fixed. Talk to HPA to change this.
>
> What's the URL?
>
> 	-hpa
>
>
> -
> 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/

Proof positive nobody ever looks at the bottom of these messages...

You've been here how many years now? :)

Rob

(P.S. Happy new year.)

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[David Ford]

If I had the time to do it or subsistence backing to do it, I would.

I'd write the bugzilla concept that interfaced w/ lkml to automatically 
run queries and email results to "loop doesn't compile".  It would also 
cross check at bug submission time for possible dupe entries and ask the 
submitter if he really wanted to continue.

If you make it easy to use and it has the answers you need, it will 
create it's own success and by that, it'll draw a lot of these lkml 
repeats from the list.  the SNR will increase and users will be happier. 
 Instead of going to google and getting 947 mostly similar pages to the 
same sender/replier and 3 pages that you actually could use..you could 
visit the kernel bugkeep lair.

What is needed is a well designed interface to a DB, not YAB (yet 
another bugtracker) that isn't intuitive and thus won't be used.  Most 
of the reason why such a DB is looked down on is because we have seen 
way too many wonderful new ideas that have a horrible UI.  So people 
don't like it or the 20 that came before it, so they expect the next new 
wonderful idea to also turn out bad.  Not to mention that the author 
didn't do it exactly like they envisioned it.

David

>it still requires some dumb^Wpoor sap to go in pruning them,
>plus once it gets to a certain point, there will be dupes.
>Oh boy will there be dupes. People will check for them first you say?
>Some people are _still_ getting "Loop doesn't compile in 2.4.14"
>messages.
>Why search archives when you can be the 900th person to ask the
>same question.  Even Richard Gooch's page for showing whats wrong
>with the current kernel and how to fix it to get it to compile
>seems to be completly overlooked. Maybe if it were moved to
>www.kernel.org people would see it ? *shrug*
>

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[David Ford]

>
>
>The advantage email has over this are too numerous to list,
>but they start with the fact that lots of kernel developers are
>lazy[*]. 2-3 keypresses to archive a patch for looking at later/merging
>are about the level of involvement thats aimed for.
>Having to start a browser, go to the bugzilla site, log in, search/browse
>for bugs etc.. way too involved.
>
>Dave.
>
>[*] In the sense that if life can be made easier, it should be.
>

That's a bit of apples and oranges ;)

Starting a browser is equivalent to starting a mail client.  In some 
instances it's the same program.

Hitting 2-3 keypresses to archive an email...how do you manage that 
archive v.s. it being managed for you w/ bugzilla?

Logging into bugzilla can be automatic, searching for a bug across the 
archive is in my opinion much more easily done w/ a relational database 
than grepping several mbox files that collect hundreds of messages a 
day.  Not to mention that comments on each bug are localized to -that- 
bug.  All said and done there are a lot of pros and cons from the newbie 
v.s. the 'Linus' perspective.  I think there is at least one or two 
irate persons per week here that have been fighting to find a solution 
to their problem and someone finally speaks up "oh yeah, do this".

It really would be nice to have a reference database -somewhere- where 
we could find answers or even just suggestions about the myriad of 
problems related to the kernel and what the kernel touches.

David

[*] RDBMSs do make my life much easier

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Dave Jones]

On Mon, 31 Dec 2001, David Ford wrote:

> Starting a browser is equivalent to starting a mail client.  In some
> instances it's the same program.

keeping a terminal with ssh open all day is feasible (and is what I
and a lot of others probably do). Keeping mozilla open all day is
not practical. (and no, w3m/lynx etc are not practical for using
bugzilla imo).

> Hitting 2-3 keypresses to archive an email...how do you manage that
> archive v.s. it being managed for you w/ bugzilla?

both mua's I use have comprehensive indexing/searching abilities.
s25<enter> saves a patch for applying later.

cat ~/25 | patch -p1  is all I need to do, plus I have an archive
of patches applied on what date, along with the descriptive mails
that went with them.

Effortless.

If a patch needs reversing, I load the mua, move the mail to another
folder, and do the same with patch -R

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[David Ford]

>
>
>>Starting a browser is equivalent to starting a mail client.  In some
>>instances it's the same program.
>>
>
>keeping a terminal with ssh open all day is feasible (and is what I
>and a lot of others probably do). Keeping mozilla open all day is
>not practical. (and no, w3m/lynx etc are not practical for using
>bugzilla imo).
>

Eh?  Why isn't it?  I keep it open for weeks if it doesn't crash.

>>Hitting 2-3 keypresses to archive an email...how do you manage that
>>archive v.s. it being managed for you w/ bugzilla?
>>
>
>both mua's I use have comprehensive indexing/searching abilities.
>s25<enter> saves a patch for applying later.
>
>cat ~/25 | patch -p1  is all I need to do, plus I have an archive
>of patches applied on what date, along with the descriptive mails
>that went with them.
>
>Effortless.
>
>If a patch needs reversing, I load the mua, move the mail to another
>folder, and do the same with patch -R
>
>Dave.
>

Then your system works for you, but it doesn't make anything available 
for anyone else nor does it allow for anything other than the simple 
collection of emails/patches.  That's the point of an accessible 
database.  Over years of development, trying to maintain a comprehensive 
system would require you to index what "25" relates to.

The point of this DB in discussion is to make it easier for everyone, 
from developer to the random person who only reads lkml when he needs to 
find an answer.  Make it easier to research, catalog, reference, 
explain, and derive all the parts of a given bug.

For example, the ECN issue.  Anyone from developer to Joe Admin could 
look up "connection failed" and get back a group of results with a high 
"ECN" hit rate.  A few seconds to type it in and a minute later he has 
probably put 0 in tcp_ecn and happily wanders away.

David

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[Horst von Brand]

David Ford <david+cert@blue-labs.org> said:

[...]

> That's a bit of apples and oranges ;)
> 
> Starting a browser is equivalent to starting a mail client.  In some 
> instances it's the same program.

It is not for anybody who handles large amounts of mail. I have yet to see
a browser which does even a half-assed attempt at doing email right.

> Hitting 2-3 keypresses to archive an email...how do you manage that 
> archive v.s. it being managed for you w/ bugzilla?

Here (emacs + mh-e): ^ on the message, RET to confirm the folder. Managing?
No sweat, it is just another mail folder, to be handled by the same
commands my fingers do on their own now.

> Logging into bugzilla can be automatic, searching for a bug across the 
> archive is in my opinion much more easily done w/ a relational database 
> than grepping several mbox files that collect hundreds of messages a 
> day.  Not to mention that comments on each bug are localized to -that- 
> bug.  All said and done there are a lot of pros and cons from the newbie 
> v.s. the 'Linus' perspective.  I think there is at least one or two 
> irate persons per week here that have been fighting to find a solution 
> to their problem and someone finally speaks up "oh yeah, do this".

Plus the problem that thousands of (well meaning, but completely useless)
reports clog up bug<foo>, rquiring hand-cleaning by somebody who _really_
knows about the system. I.e., exactly the person whose work you want to
spare.

> It really would be nice to have a reference database -somewhere- where 
> we could find answers or even just suggestions about the myriad of 
> problems related to the kernel and what the kernel touches.

Look at the FAQ for the kernel (helpfully compiled by this list). Problems
that get identified tend to get fixed fast, so working at documenting them
in detail makes no sense at al.

If you want to know what is broken in _development_ kernels, you have to
read this list.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: RFC: Linux Bug Tracking & Feature Tracking DB

[David Ford]

>
>
>It is not for anybody who handles large amounts of mail. I have yet to see
>a browser which does even a half-assed attempt at doing email right.
>

I handle thousands of emails a day, over a hundred emails distinctly to 
me, not a list.  I like mozilla most, but don't think I like the 
footprint or everything about it ;)

>Here (emacs + mh-e): ^ on the message, RET to confirm the folder. Managing?
>No sweat, it is just another mail folder, to be handled by the same
>commands my fingers do on their own now.
>

As I mentioned to DJ, this is fine for you, your personal database, but 
it serves no purpose for anyone else and doesn't scale well for large 
amounts of reference material.

>Plus the problem that thousands of (well meaning, but completely useless)
>reports clog up bug<foo>, rquiring hand-cleaning by somebody who _really_
>knows about the system. I.e., exactly the person whose work you want to
>spare.
>

Untidied bug reports can be flushed out of the system, they can be 
<insert action>.  By making a more intuitive system, these bug reports 
could be fleshed out better or coallated when appropriate.  By having an 
open system, anyone can do the maintenance.  You can choose different 
pools for the entries and keep the chaff "outside" until it is weeded 
through or discarded.

>Look at the FAQ for the kernel (helpfully compiled by this list). Problems
>that get identified tend to get fixed fast, so working at documenting them
>in detail makes no sense at al.
>
>If you want to know what is broken in _development_ kernels, you have to
>read this list.
>

Not everything needs to be documented or documented in detail. 
 Sometimes a simple "loopback compile err, 'loopback.c:417:foo is not 
defined' is fixed in 2.2.2." is quite sufficient.  People with 2.2.1 
will recognize the need to upgrade or generate a patch to solve their 
problem.  The FAQ doesn't address everything and not everything is 
broken.  A 'bug' database is sometimes a misnomer.

Neither the DB nor the list replace each other.  They augment each other.

David