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: [email protected].
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: [email protected].
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.
[email protected].
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
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
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.
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.
[email protected].
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
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.
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
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: [email protected].
> 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: [email protected].
> 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.
>
>
> [email protected].
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
------------------------------
Stewart Smith
[email protected]
Ph: +61 4 3884 4332
ICQ: 6734154
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 <[email protected]>
> To: Larry McVoy <[email protected]>
> Subject: Re: Source of Bitkeeper
> Message-ID: <[email protected]>
> References: <[email protected]> <[email protected]>
>
> 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...
> 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
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
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
[email protected]
Ph: +61 4 3884 4332
ICQ: 6734154
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
http://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
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
> http://www.kernel.org people would see it ? *shrug*
This was suggested some months ago, but nothing happened. Firstly, the
http://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: [email protected]
Current: [email protected]
Richard Gooch wrote:
>
> This was suggested some months ago, but nothing happened. Firstly, the
> http://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
On Sun, 30 Dec 2001, H. Peter Anvin wrote:
> > This was suggested some months ago, but nothing happened. Firstly, the
> > http://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
H. Peter Anvin writes:
> Richard Gooch wrote:
> > This was suggested some months ago, but nothing happened. Firstly, the
> > http://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: [email protected]
Current: [email protected]
Richard Gooch wrote:
> H. Peter Anvin writes:
>
>>Richard Gooch wrote:
>>
>>>This was suggested some months ago, but nothing happened. Firstly, the
>>>http://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
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
> >http://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
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
> >>>http://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 http://www.tux.org to vger.kernel.org
doesn't have any real benefit. The main thing is that the
http://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 http://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: [email protected]
Current: [email protected]
Richard Gooch wrote:
>
> Well, merely shifting the FAQ from http://www.tux.org to vger.kernel.org
> doesn't have any real benefit. The main thing is that the
> http://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 http://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
H. Peter Anvin writes:
> Richard Gooch wrote:
>
> >
> > Well, merely shifting the FAQ from http://www.tux.org to vger.kernel.org
> > doesn't have any real benefit. The main thing is that the
> > http://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 http://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: [email protected]
Current: [email protected]
>
>
>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
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
>http://www.kernel.org people would see it ? *shrug*
>
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
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
> > http://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 [email protected]
> 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.)
David Ford <[email protected]> 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 [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
>
>
>>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
>
>
>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