bug database braindump from the kernel summit

bug database braindump from the kernel summit

[Larry McVoy]

Folks, since bug tracking is the next thing we are attacking here at
BitMover, I have a great deal of interest in the bug tracking discussion
which happened last night at the summit.  We already have a prototyped bug
tracking system which we are integrating into BitKeeper, but as usual,
it isn't good enough for the kernel team who have an interesting set
of requirements.

We want to make sure that the BK bug tracking system _could_ be used for
the kernel effort.  Whether it is or not will be decided after years of
licensing flamewars, etc., etc.  We're not going to go there so please
don't try.

Where I want to go is a discussion of requirements, then we converge on
a strawman proposal, and then all of the people who care enough about
this can go implement an answer and Linus and/or Alan and/or whoever can
choose one.

Let's stay focussed on arriving at a good set of agreed on requirements.

I've done a brain dump below.  I'll track this mail thread and update this
doc as the discussion unfolds.  I'll post updates as it is needed.  If this
discussion takes on a life of its own, I may try and grab all the mail and
archive it so that people can browse; we'll see, it may be that everyone
is so busy that this will be the first and last message on the topic.

--lm

Brain dump on the bug tracking problem from the Kernel Summit discussions

		[SCCS/s.BUGS vers 1.2 2001/04/01 10:46:55]

Outline
	Problems
	Problem details
	Past experiences
	Requirements

Problems
    - getting quality bug reports
    - not losing any bugs
    - sorting low signal vs high signal into a smaller high signal pile
    - simplified, preferably NNTP, access to the bug database (Linus
      would use this; he's unlikely to use anything else)

Problem details
    Bug report quality
    	There was lots of discussion on this.  The main agreement was that we
	wanted the bug reporting system to dig out as much info as possible
	and prefill that.  There was a lot of discussion about possible tools
	that would dig out the /proc/pci info; there was discussion about
	Andre's tools which can tell you if you can write your disk; someone
	else had something similar.

	But the main thing was to extract all the info we could
	automatically.	One thing was the machine config (hardware and
	at least kernel version).  The other thing was extract any oops
	messages and get a stack traceback.

	The other main thing was to define some sort of structure to the
	bug report and try and get the use to categorize if they could.
	In an ideal world, we would use the maintainers file and the
	stack traceback to cc the bug to the maintainer.  I think we want
	to explore this a bit.	I'm not sure that the maintainer file is
	the way to go, what if we divided it up into much broader chunks
	like "fs", "vm", "network drivers", and had a mail forwarder
	for each area.	That could fan out to the maintainers.

    Not losing bugs
	While there was much discussion about how to get rid of bad,
	incorrect, and/or duplicate bug reports, several people - Alan
	in particular - made the point that having a complete collection
	of all bug reports was important.  You can do data mining across
	all/part of them and look for patterns.  The point was that there
	is some useful signal amongst all the noise so we do not want to
	lose that signal.
    
    Signal/noise
	We had a lot of discussion about how to deal with signal/noise.
	The bugzilla proponents thought we could do this with some additional
	hacking to bugzilla.  I, given the BitKeeper background, thought 
	that we could do this by having two databases, one with all the 
	crud in it and another with just the screened bugs in it.  No matter
	how it is done, there needs to be some way to both keep a full list,
	which will likely be used only for data mining, and another, much
	smaller list of screened bugs.  Jens wants there to be a queue of 
	new bugs and a mechanism where people can come in the morning, pull
	a pile of bugs off of the queue, sort them, sending some to the real
	database.  This idea has a lot of merit, it needs some pondering as
	DaveM would say, to get to the point that we have a workable mechanism
	which works in a distributed fashion.

	The other key point seemed to be that if nobody picked up a bug and
	nobody said that this bug should be picked up, then the bug expires
	out of the pending queue.  It gets stashed in the bug archive for
	mining purposes and it can be resurrected if it later becomes a real
	bug, but the key point seems to be that it _automatically_ disappears
	out of the pending queue.  I personally am very supportive of this
	model.  We need some way to just let junk stay junk.  If junk has to
	be pruned out of the system by humans, the system sucks.  The system,
	not humans, needs to autoprune.
    
    Simplified access: browsing and updating
	Linus made the point that mailing lists suck.  He isn't on any and
	refuses to join any.  He reads lists with a news reader.  I think
	people should sit up and listen to that - it's a key point.  If your
	mailing list isn't gatewayed to a newsgroup, he isn't reading it and
	a lot of other people aren't either.

	There was a fair bit of discussion about how to get the bug database
	connected to news.  There doesn't seem to be any reason that the
	bug system couldn't be a news server/gateway.  You should be able to
	browse
	    bitbucket.kernel.bugs - all the unscreened crud
	    screened.kernel.bugs - all bugs which have been screened
	    fs.kernel.bugs - screened bugs in the "fs" category
	    ext2.kernel.bugs - screened bugs in the "ext2" category
	    eepro.kernel.bugs - screened bugs in the "eepro" category
	    etc.

	Furthermore, the bugs should be structured once they are screened,
	i.e., they have a set of fields like (this is a strawman):

	    Synopsis - one line man-page like summary of the bug
	    Severity - how critical is this bug?
	    Priority - how soon does it need to be fixed?
	    Category - subsystem in which the bug occurs
	    Description - details on the bug, oops, stack trace, etc.
	    Hardware - hardware info
	    Software - kernel version, glibc version, etc.
	    Suggested fix - any suggestion on how to fix it
	    Interest list - set of email addresses and/or newsgroups for updates
	
	It ought to work that if someone posts a followup to the bug then if
	the followup changes any of the fields that gets propagated to the
	underlying bug database.  If this is done properly the news reader will
	be the only interface that most people use.

Past experiences
    This is a catch all for sound bytes that we don't want to forget...

    - Sorting bugs by hand is a pain in the ass (Ted burned out on it and
      Alan refuses to say that it is the joy of his life to do it)
    - bug systems tend to "get in the way".  Unless they are really trivial
      to submit, search, update then people get tired of using them and go
      back to the old way
    - one key observation: let bugs "expire" much like news expires.  If
      nobody has been whining enough that it gets into the high signal 
      bug db then it probably isn't real.  We really want a way where no
      activity means let it expire.
    - Alan pointed out that having all of the bugs someplace is useful,
      you can search through the 200 similar bugs and notice that SMP
      is the common feature.  

Requirements
    This section is mostly empty, it's here as a catch all for people's
    bullet items.  

    - it would be very nice to be able to cross reference bugs to bug fixes
      in the source management system, as well as the other way around.

Re: bug database braindump from the kernel summit

[Albert D. Cahalan]

> Problem details
>     Bug report quality
>     	There was lots of discussion on this.  The main agreement was that we
> 	wanted the bug reporting system to dig out as much info as possible
> 	and prefill that.  There was a lot of discussion about possible tools
> 	that would dig out the /proc/pci info; there was discussion about
> 	Andre's tools which can tell you if you can write your disk; someone
> 	else had something similar.
> 
> 	But the main thing was to extract all the info we could
> 	automatically.	One thing was the machine config (hardware and
> 	at least kernel version).  The other thing was extract any oops
> 	messages and get a stack traceback.

I'm really sick of being buried in useless information. The signal
gets lost in the noise. It is easy to discard automatically generated
bug reports, and way too annoying to wade through the crud.

When network connections hang, the console-tools package version
isn't likely to be of any use. When ramfs leaks memory, nobody needs
the content of /proc/pci.

Sometimes the bit of crud are HUGE. Imagine the hardware info
for a 64-way SGI or Sun box with plenty of devices attached.

Re: bug database braindump from the kernel summit

[Gregory Maxwell]

On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote:
> I'm really sick of being buried in useless information. The signal
> gets lost in the noise. It is easy to discard automatically generated
> bug reports, and way too annoying to wade through the crud.
> 
> When network connections hang, the console-tools package version
> isn't likely to be of any use. When ramfs leaks memory, nobody needs
> the content of /proc/pci.
> 
> Sometimes the bit of crud are HUGE. Imagine the hardware info
> for a 64-way SGI or Sun box with plenty of devices attached.

Disk space is 'free'. The information should be stored in a database where
you can retrieve the information you need at will, while the back-end can
statistically analyze the whole of the information looking for anomalies you
would never have expected (like that network hang actually being caused by
console-tools :) ).

Re: bug database braindump from the kernel summit

[Albert D. Cahalan]

Gregory Maxwell writes:
> On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote:

>> I'm really sick of being buried in useless information. The signal
>> gets lost in the noise. It is easy to discard automatically generated
>> bug reports, and way too annoying to wade through the crud.
>>
>> When network connections hang, the console-tools package version
>> isn't likely to be of any use. When ramfs leaks memory, nobody needs
>> the content of /proc/pci.
>>
>> Sometimes the bit of crud are HUGE. Imagine the hardware info
>> for a 64-way SGI or Sun box with plenty of devices attached.
>
> Disk space is 'free'.

Disk space isn't the issue. Just a few days ago I tried to help
somebody who posted one of the bloated fill-in-the-form bug reports.
I gave him a useless answer, because I didn't see amid all the junk
that he had no problems with a 2.2.xx kernel. The good information
had been buried in fluff.

Re: bug database braindump from the kernel summit

[David Lang]

On Sun, 1 Apr 2001, Larry McVoy wrote:

when generating the auto bug reports make sure that the system tells the
user exactly what data is being sent.

sending a large chunk of unknown data off the machine is a big concern to
many people.

David Lang

Re: bug database braindump from the kernel summit

[David Lang]

oops, I was going to quote a section from Larry's mail then decided not to
and forgot to delete the header.

David Lang

On Sun, 1 Apr 2001, David Lang wrote:

> Date: Sun, 1 Apr 2001 14:16:57 -0700 (PDT)
> From: David Lang <dlang@diginsite.com>
> To: Larry McVoy <lm@bitmover.com>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: bug database braindump from the kernel summit
>
> On Sun, 1 Apr 2001, Larry McVoy wrote:
>
> when generating the auto bug reports make sure that the system tells the
> user exactly what data is being sent.
>
> sending a large chunk of unknown data off the machine is a big concern to
> many people.
>
> David Lang
>
>
>

Re: bug database braindump from the kernel summit

[Miles Lane]

David Lang wrote:
> 
> On Sun, 1 Apr 2001, Larry McVoy wrote:
> 
> when generating the auto bug reports make sure that the system tells the
> user exactly what data is being sent.
> 
> sending a large chunk of unknown data off the machine is a big concern to
> many people.

Yeah.  This is a good point, although I can't think of info
about a system's hardware and software configuration that would
be particularly sensitive, other than files that contain network
topology or encrypted passwords.  I'm sure others can come up
with such a list.  One candidate might be the smbfs configuration
file, since network passwords can live there, right?  tcpdump output
might also be sensitive, but that type of info would need to get 
requested by network driver developers after the initial bug report 
anyhow.  

	Miles

Re: bug database braindump from the kernel summit

[David Lang]

Miles, if the system is just sending the config info it may not be a
problem, but take the microsoft example, how do you know the bug report is
just sending info that is relevent to the system and not trying to
discover everything that you have installed in your system (in our case we
can't be looking for pirated software, but assuming that the bug report is
being sent as root how do you know that it's not sending out your password
file if it just send 'stuff' out)

David Lang

 On Sun, 1 Apr 2001, Miles Lane wrote:

> David Lang wrote:
> >
> > On Sun, 1 Apr 2001, Larry McVoy wrote:
> >
> > when generating the auto bug reports make sure that the system tells the
> > user exactly what data is being sent.
> >
> > sending a large chunk of unknown data off the machine is a big concern to
> > many people.
>
> Yeah.  This is a good point, although I can't think of info
> about a system's hardware and software configuration that would
> be particularly sensitive, other than files that contain network
> topology or encrypted passwords.  I'm sure others can come up
> with such a list.  One candidate might be the smbfs configuration
> file, since network passwords can live there, right?  tcpdump output
> might also be sensitive, but that type of info would need to get
> requested by network driver developers after the initial bug report
> anyhow.
>
> 	Miles
>

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Larry McVoy wrote:
> Problem details
>     Bug report quality
[...]
> 	But the main thing was to extract all the info we could
> 	automatically.	One thing was the machine config (hardware and
> 	at least kernel version).  The other thing was extract any oops
> 	messages and get a stack traceback.

Basically look through REPORTING-BUGS for a laundry list of helpful info.

> 	The other main thing was to define some sort of structure to the
> 	bug report and try and get the use to categorize if they could.
> 	In an ideal world, we would use the maintainers file and the
> 	stack traceback to cc the bug to the maintainer.  I think we want
> 	to explore this a bit.	I'm not sure that the maintainer file is
> 	the way to go, what if we divided it up into much broader chunks
> 	like "fs", "vm", "network drivers", and had a mail forwarder
> 	for each area.	That could fan out to the maintainers.

(slight tangent)
One thing people have talked about in the past is updating MAINTAINERS
to actually reflect real life...  some of the active maintainers
don't have maintainer entries.  That may be intentional, maybe not...

For drivers at least, bugs -should- be mailed to the driver
maintainer where possible, which is not always the same as the
subsystem maintainer.


>     Signal/noise
[...]
> 	Jens wants there to be a queue of 

Jes?

> 	new bugs and a mechanism where people can come in the morning, pull
> 	a pile of bugs off of the queue, sort them, sending some to the real
> 	database.  This idea has a lot of merit, it needs some pondering as
> 	DaveM would say, to get to the point that we have a workable mechanism
> 	which works in a distributed fashion.

Back when I was hacking GNOME, various janitors (to use the now-popular
term) would go through and clean the bug database, sorting through a lot
of the noise.

Newbies are finding the Kernel Janitors project as an excellent way to
begin to contribute to the kernel.  There are definitely interested,
smart people willing to help, that at present don't know a lot about the
kernel.  Such volunteers, like the GNOMEs mentioned above, could be a
vast benefit to this particular step of the bug tracking process.  You
http://sourceforge.net/projects/kernel-janitor/    </plug>

> Past experiences
>     This is a catch all for sound bytes that we don't want to forget...
> 
>     - one key observation: let bugs "expire" much like news expires.  If
>       nobody has been whining enough that it gets into the high signal 
>       bug db then it probably isn't real.  We really want a way where no
>       activity means let it expire.

Agreed, with a caveat:  some bugs should stay around but not expire.
There is a class of bugs that shouldn't go away from the "less noise"
bug database when there is no activity.  ie. hard problems we want to
remember, but solve in a later version.


> Requirements

1) An e-mail interface.

For sorting through massive amounts of bugs, NNTP is far more useful.
Maybe as a query interface as well, NNTP is useful.  But for getting
into the nitty-gritty details of handling a bug, e-mail is generally the
primary medium of communication between developer and user.

debian-bugs assigns each bug a unique e-mail address, and all e-mail
that arrives in that mailbox is appended to the bug's comments.

2) Support for binary attachments from users

Re: bug database braindump from the kernel summit

[Rogier Wolff]

Larry McVoy wrote:
> 	The other main thing was to define some sort of structure to the
> 	bug report and try and get the use to categorize if they could.
> 	In an ideal world, we would use the maintainers file and the
> 	stack traceback to cc the bug to the maintainer.  I think we want
> 	to explore this a bit.	I'm not sure that the maintainer file is
> 	the way to go, what if we divided it up into much broader chunks
> 	like "fs", "vm", "network drivers", and had a mail forwarder
> 	for each area.	That could fan out to the maintainers.

This depends on the bug. 

If someone finds a generic kernel problem while logging in on a serial
terminal connected through a specialix-SX card, there is no reason to
CC me as the maintainer of that driver. If however, the bug is in the
driver, then I should be CC-ed.

Asking the submitter is I think the only way to do this: 
	You have a XYZ scsi Controller.
	Do you think this bug relates to this driver?           yes/no
	Should the maintainer of the xyz controller be CCed?    yes/no

	You have a Specialix SX card.
	Do you think this bug relates to this driver?           yes/no
	Should the maintainer of the specialix SX card be CCed? yes/no

Blindly CCing people from the Maintainers list is probably not a good
idea. Better would be to allow the maintainers to specify HOW they
want to be CC-ed. I for example, would want for every driver that I
maintain, to have a bug submitted in my jitterbug database (instead
of mailed to my private email address). 

>     Not losing bugs
> 	While there was much discussion about how to get rid of bad,
> 	incorrect, and/or duplicate bug reports, several people - Alan
> 	in particular - made the point that having a complete collection
> 	of all bug reports was important.  You can do data mining across
> 	all/part of them and look for patterns.  The point was that there
> 	is some useful signal amongst all the noise so we do not want to
> 	lose that signal.

All this sorting and tagging should be done in ONE database. So,
random users can add "count me in on this one", meaning that they too
see this problem. And that someone trying to fix this can CC them too.

Also, say Jens can tag a problem as "a fluke", while Alan should still
be able to tag it as: "Hmm. Odd problem. Heard of it before, Need more
reports to figure out the common cause". 

Queries to the database can then be "All problems tagged as real by at
least one kernel hotshot".

>     Signal/noise
> 	We had a lot of discussion about how to deal with signal/noise.
> 	The bugzilla proponents thought we could do this with some additional
> 	hacking to bugzilla.  I, given the BitKeeper background, thought 
> 	that we could do this by having two databases, one with all the 
> 	crud in it and another with just the screened bugs in it.  No matter
> 	how it is done, there needs to be some way to both keep a full list,
> 	which will likely be used only for data mining, and another, much
> 	smaller list of screened bugs.  Jens wants there to be a queue of 
> 	new bugs and a mechanism where people can come in the morning, pull
> 	a pile of bugs off of the queue, sort them, sending some to the real
> 	database.  This idea has a lot of merit, it needs some pondering as
> 	DaveM would say, to get to the point that we have a workable mechanism
> 	which works in a distributed fashion.

Jitterbug already has this. However, every problem in Jitterbug is
only in one queue/classification. My suggestion for the big thingy is
that everybody could have a different view.

> 	The other key point seemed to be that if nobody picked up a bug and
> 	nobody said that this bug should be picked up, then the bug expires
> 	out of the pending queue.  It gets stashed in the bug archive for
> 	mining purposes and it can be resurrected if it later becomes a real
> 	bug, but the key point seems to be that it _automatically_ disappears
> 	out of the pending queue.  I personally am very supportive of this
> 	model.  We need some way to just let junk stay junk.  If junk has to
> 	be pruned out of the system by humans, the system sucks.  The system,
> 	not humans, needs to autoprune.

OK. But those "interested" in the bug (the Email of the submitter)
should be notified: "Your reported bug is going to expire soon. Could you
indicate that this is still bothering you"?. 

"Enhancement requests" can stay around for a long, long time if nobody
takes the time to implement the request.

Speaking of "Enhancement requests", there once was a professor in the
field of "operating systems" who wanted to give out real
Linux-ehancement projects as lab-projects for his course. Some people
might tag enhancement requests with "80-hour project", and then allow
students to do them for credit!

>     Simplified access: browsing and updating
> 	Linus made the point that mailing lists suck.  He isn't on any and
> 	refuses to join any.  He reads lists with a news reader.  I think
> 	people should sit up and listen to that - it's a key point.  If your
> 	mailing list isn't gatewayed to a newsgroup, he isn't reading it and
> 	a lot of other people aren't either.
> 
> 	There was a fair bit of discussion about how to get the bug database
> 	connected to news.  There doesn't seem to be any reason that the
> 	bug system couldn't be a news server/gateway.  You should be able to
> 	browse
> 	    bitbucket.kernel.bugs - all the unscreened crud
> 	    screened.kernel.bugs - all bugs which have been screened
> 	    fs.kernel.bugs - screened bugs in the "fs" category
> 	    ext2.kernel.bugs - screened bugs in the "ext2" category
> 	    eepro.kernel.bugs - screened bugs in the "eepro" category

This sounds good, except that when you have different views towards
the database, problems arise. We could just dump the database into a
news-server every hour to make Linus happy, but that would probably
defeat some of the advantages of the "news" interface (mark problems
as "read").

>     - one key observation: let bugs "expire" much like news expires.  If
>       nobody has been whining enough that it gets into the high signal 
>       bug db then it probably isn't real.  We really want a way where no
>       activity means let it expire.

This needs to be "forced". A submitter should get an EMail when a bug
is about to be expired, and should be able to claim an extension. The
reply should also ask for the latest kernel that the submitter tried,
and was verfied to have the bug. 

So the bug item in the DB will get tagged for example as: reported to
exist on 2.4.1, 2.4.2-ac12 and 2.4.3 by REW.

- Dynamic keyword section. 

Dynamic: You CAN enter keywords that are not already in the database. 
Those will be available to others from then on. 

Someone may want to tag "disc-problem" as equivalent to "disk-problem". 

The "limited list of possibilites" means that searches for...

>     - Alan pointed out that having all of the bugs someplace is useful,
>       you can search through the 200 similar bugs and notice that SMP
>       is the common feature.  

... similar problems become easier/possible. 


- Automatic inclusion of ".config" files. Nowadays, the .config is so
large that submitting it with a bugreport is not efficient. However,
if you would be submitting a bugreport into a database, the info could
be very useful in reliably scanning for common configuration options
in a set of reports.

- "me too" reports should be able to append a new ".config" to an
existing bugreport.

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: bug database braindump from the kernel summit

[Manfred Spraul]

> There was a lot of discussion about possible tools
> that would dig out the /proc/pci info

I think the tools should not dig too much information out of the system.
I remember some Microsoft (win98 beta?) bugtracking software that
insisted on sending a several hundert kB long compressed blob with every
bug report.
IMHO it must be possible to file bugreports without the complete hw info
if I know that the bug isn't hw related.

--
    Manfred

Re: bug database braindump from the kernel summit

[Albert D. Cahalan]

Manfred Spraul writes:
> [Larry McVoy]

>> There was a lot of discussion about possible tools
>> that would dig out the /proc/pci info
>
> I think the tools should not dig too much information out of the system.
> I remember some Microsoft (win98 beta?) bugtracking software that
> insisted on sending a several hundert kB long compressed blob with every
> bug report.
> IMHO it must be possible to file bugreports without the complete hw info
> if I know that the bug isn't hw related.

Yep. The two hardware-related items that usually matter:

Little-endian or broken-endian?
32-bit or 64-bit?

The CPU type is not necessary or sufficient, since one can often
run a 32-bit kernel on 64-bit hardware and at least MIPS has both
little-endian and broken-endian supported.

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Albert D. Cahalan wrote:
> Manfred Spraul writes:
> > [Larry McVoy]
> 
> >> There was a lot of discussion about possible tools
> >> that would dig out the /proc/pci info

> > I think the tools should not dig too much information out of the system.
> > I remember some Microsoft (win98 beta?) bugtracking software that
> > insisted on sending a several hundert kB long compressed blob with every
> > bug report.
> > IMHO it must be possible to file bugreports without the complete hw info
> > if I know that the bug isn't hw related.
> 
> Yep. The two hardware-related items that usually matter:
> 
> Little-endian or broken-endian?
> 32-bit or 64-bit?

Matters to whom?  You, or the people actually fixing bugs?

"Broken-endian"?  whatever.

/proc/pci data alone with every bug report is usually invaluable.  It
gives you a really good idea of the general layout of the system, and
you can often catch or become aware of related hardware characteristics
which 

linux/REPORTINGS-BUGS was created to give users a hint that we need
-more- information, and tells exactly what general information is useful
to provide.  We do not need less information.

	Jeff

Re: bug database braindump from the kernel summit

[Manfred Spraul]

From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
>
> /proc/pci data alone with every bug report is usually invaluable.

Even if the bug is a compile error?

E.g.
BUG REPORT (a real one, I didn't have the time yet to post a patch):
kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
Description:
Several config options are missing in the 'if' at the end of
linux/drivers/net/pcmcia/Config.in.
This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the
kernel won't link.

CONFIG_ARCNET_COM20020_CS
CONFIG_PCMCIA_HERMES
CONFIG_AIRONET4500_CS
CONFIG_PCMCIA_IBMTR
are missing.

Obviously too much data doesn't hurt, as long as
* it's hidden somewhere deep in a database, clearly separated from the
important parts (if there is an oops: decoded oops, description, how
easy is it to trigger the bug, steps to reproduce)
* very easy for the bug reporter to collect.
* not mandatory.

--
    Manfred

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Manfred Spraul wrote:
> From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> >
> > /proc/pci data alone with every bug report is usually invaluable.
> 
> Even if the bug is a compile error?

In fact, yes.  Having the tuple of: .config, /proc/pci, and compile
error output, you can see additionally if the user is doing something
wrong.

It allows you to fix the user as well as the compile error ;-)


> E.g.
> BUG REPORT (a real one, I didn't have the time yet to post a patch):
> kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
> Description:
> Several config options are missing in the 'if' at the end of
> linux/drivers/net/pcmcia/Config.in.
> This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the
> kernel won't link.
> 
> CONFIG_ARCNET_COM20020_CS
> CONFIG_PCMCIA_HERMES
> CONFIG_AIRONET4500_CS
> CONFIG_PCMCIA_IBMTR
> are missing.

noted.

> Obviously too much data doesn't hurt, as long as
> * it's hidden somewhere deep in a database, clearly separated from the
> important parts (if there is an oops: decoded oops, description, how
> easy is it to trigger the bug, steps to reproduce)
> * very easy for the bug reporter to collect.
> * not mandatory.

agreed.

Regards,

	Jeff

Re: bug database braindump from the kernel summit

[David Lang]

if we want to get the .config as part of the report then we need to make
it part of the kernel in some standard way (the old /proc/config flamewar)
it's difficult enough sometimes for the sysadmin of a box to know what
kernel is running on it, let alone a bug reporting script.

David Lang

 On Sun, 1 Apr
2001, Jeff Garzik wrote:

> Date: Sun, 1 Apr 2001 17:48:34 -0500 (CDT)
> From: Jeff Garzik <jgarzik@mandrakesoft.com>
> To: Manfred Spraul <manfred@colorfullife.com>
> Cc: Albert D. Cahalan <acahalan@cs.uml.edu>, lm@bitmover.com,
>      linux-kernel@vger.kernel.org
> Subject: Re: bug database braindump from the kernel summit
>
> On Sun, 1 Apr 2001, Manfred Spraul wrote:
> > From: "Jeff Garzik" <jgarzik@mandrakesoft.com>
> > >
> > > /proc/pci data alone with every bug report is usually invaluable.
> >
> > Even if the bug is a compile error?
>
> In fact, yes.  Having the tuple of: .config, /proc/pci, and compile
> error output, you can see additionally if the user is doing something
> wrong.
>
> It allows you to fix the user as well as the compile error ;-)
>
>
> > E.g.
> > BUG REPORT (a real one, I didn't have the time yet to post a patch):
> > kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
> > Description:
> > Several config options are missing in the 'if' at the end of
> > linux/drivers/net/pcmcia/Config.in.
> > This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the
> > kernel won't link.
> >
> > CONFIG_ARCNET_COM20020_CS
> > CONFIG_PCMCIA_HERMES
> > CONFIG_AIRONET4500_CS
> > CONFIG_PCMCIA_IBMTR
> > are missing.
>
> noted.
>
> > Obviously too much data doesn't hurt, as long as
> > * it's hidden somewhere deep in a database, clearly separated from the
> > important parts (if there is an oops: decoded oops, description, how
> > easy is it to trigger the bug, steps to reproduce)
> > * very easy for the bug reporter to collect.
> > * not mandatory.
>
> agreed.
>
> Regards,
>
> 	Jeff
>
>
>
>
> -
> 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/
>

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, David Lang wrote:
> if we want to get the .config as part of the report then we need to make
> it part of the kernel in some standard way (the old /proc/config flamewar)
> it's difficult enough sometimes for the sysadmin of a box to know what
> kernel is running on it, let alone a bug reporting script.

Let's hope it's not a flamewar, but here goes :)

We -need- .config, but /proc/config seems like pure bloat.

If a sysadmin (note I don't say "user") has no clue what his kernel
config is, or has no clue what kernel is running on his box, then
they should be fired before the day is out.

	Jeff

Re: bug database braindump from the kernel summit

[David Lang]

Jeff, if the sysadmin had anything to do with setting up the box I would
agree with you, but there are cases where one person will boot a machine
and another will then need to find out what is going on.

I have seen systems with multiple kernels available on boot get booted
from the wrong kernel

I've also seen a machine running for years without being touched and then
a sysadmin is hired and has to work on it, how should they know what the
config was?

/proc/config may be bloat, but we do need a way for the kernel config to
be tied to the kernel image that is running, however it is made available.

David Lang

 On Sun, 1 Apr
2001, Jeff Garzik wrote:

>
> If a sysadmin (note I don't say "user") has no clue what his kernel
> config is, or has no clue what kernel is running on his box, then
> they should be fired before the day is out.
>
> 	Jeff
>
>
>

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, David Lang wrote:
> /proc/config may be bloat, but we do need a way for the kernel config to
> be tied to the kernel image that is running, however it is made available.

/sbin/installkernel copies stuff into /boot, appending a version number.
One way might be to have this script also copy the kernel config.

	Jeff

Re: bug database braindump from the kernel summit

[David Lang]

could be, /sbin/installkernel doesn't exist on my systems

David Lang

On Sun, 1 Apr 2001, Jeff Garzik wrote:

> Date: Sun, 1 Apr 2001 18:34:07 -0500 (CDT)
> From: Jeff Garzik <jgarzik@mandrakesoft.com>
> To: David Lang <dlang@diginsite.com>
> Cc: Manfred Spraul <manfred@colorfullife.com>,
>      Albert D. Cahalan <acahalan@cs.uml.edu>, lm@bitmover.com,
>      linux-kernel@vger.kernel.org
> Subject: Re: bug database braindump from the kernel summit
>
> On Sun, 1 Apr 2001, David Lang wrote:
> > /proc/config may be bloat, but we do need a way for the kernel config to
> > be tied to the kernel image that is running, however it is made available.
>
> /sbin/installkernel copies stuff into /boot, appending a version number.
> One way might be to have this script also copy the kernel config.
>
> 	Jeff
>
>
>
>

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, David Lang wrote:
> On Sun, 1 Apr 2001, Jeff Garzik wrote:
> > /sbin/installkernel copies stuff into /boot, appending a version number.
> > One way might be to have this script also copy the kernel config.

> could be, /sbin/installkernel doesn't exist on my systems

arch/i386/boot/install.sh has been calling /sbin/installkernel, if it
exists, for a good while now.

It sounds like your kernel or initscripts package is incomplete.
You can grab installkernel off a Mandrake- or RedHat-based system.

	Jeff

Re: bug database braindump from the kernel summit

[David Lang]

Jeff, my point was that not all systems will have this script. also it
won't do you any good if the system you are compiling on is not the same
system the kernel will be running on

but we are starting the wrong discussion here :-)

David Lang

On Sun, 1 Apr 2001, Jeff Garzik
wrote:

> On Sun, 1 Apr 2001, David Lang wrote:
> > On Sun, 1 Apr 2001, Jeff Garzik wrote:
> > > /sbin/installkernel copies stuff into /boot, appending a version number.
> > > One way might be to have this script also copy the kernel config.
>
> > could be, /sbin/installkernel doesn't exist on my systems
>
> arch/i386/boot/install.sh has been calling /sbin/installkernel, if it
> exists, for a good while now.
>
> It sounds like your kernel or initscripts package is incomplete.
> You can grab installkernel off a Mandrake- or RedHat-based system.
>
> 	Jeff
>
>
>
>

Re: bug database braindump from the kernel summit

[Ben Ford]

Why not have the /proc/config option but instead of being plain text, 
make it binary with a userspace app that can interpret it?

It could have a signature as to kernel version + patches and the rest 
would be just bits.

Instead of:

CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

You'd have
2.4.3-pre3:1101111100000100000000 . . . . .

-b

Re: bug database braindump from the kernel summit

[Kai Henningsen]

ben@kalifornia.com (Ben Ford)  wrote on 01.04.01 in <3AC7C719.3080403@kalifornia.com>:

> Why not have the /proc/config option but instead of being plain text,
> make it binary with a userspace app that can interpret it?
>
> It could have a signature as to kernel version + patches and the rest
> would be just bits.

> You'd have
> 2.4.3-pre3:1101111100000100000000 . . . . .

Another option would be to put a checksum of the config, and still keep  
the config separate - at least you could tell if you had the right config  
for the kernel.


MfG Kai

Re: bug database braindump from the kernel summit

[Petr Baudis]

> Why not have the /proc/config option but instead of being plain text, 
> make it binary with a userspace app that can interpret it?
[snip]
> You'd have
> 2.4.3-pre3:1101111100000100000000 . . . . .
> 
I think this is against UNIX/Linux philosophy... Why we wouldn't just
providing all the interface through sysctl stuff and abadon all the
/proc? Cause we want to provide human-readable interface, which could
be parsed really simply...

We should just mean 'cat' as 'userspace app' primarily i think. At least
currently we does. Also you have a big problem with forward compatibility
etc.

But anyway i would vote for the .config file somewhere in /boot directory.
If one have a kernel from some linux distribution, it is propably actually
obsolete, so it is proximity the bug is actually fixed anyway. And if he
will get the newest kernel, it should do something like cp .config /boot/config.

-- 

				Peter "Pasky" Baudis

Whoever coded that patch should be taken out and shot, hung, drawn and
quartered then forced to write COBOL for the rest of their natural
life.
-- Keith Owens <kaos@ocs.com.au> in linux-kernel

My public PGP key is on: http://pasky.ji.cz/~pasky/pubkey.txt
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL++++$ P+ L+++ E--- W+ N !o K- w-- !O M-
!V PS+ !PE Y+ PGP+>++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e-> h! r% y?
------END GEEK CODE BLOCK------

Re: bug database braindump from the kernel summit

[Richard Russon]

On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote:
> Let's hope it's not a flamewar, but here goes :)
> 
> We -need- .config, but /proc/config seems like pure bloat.

Don't ask me for sample code, but...

The init code for many drivers is freed up after it's used.
Could we apply the same technique and compile in .config,
then printk the entire lot (boot option) and free up the
space afterwards?

FlatCap (Richard Russon)
kernel@flatcap.org

Re: bug database braindump from the kernel summit

[Steven Walter]

On Mon, Apr 02, 2001 at 06:26:45AM +0100, Richard Russon wrote:
> On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote:
> > Let's hope it's not a flamewar, but here goes :)
> > 
> > We -need- .config, but /proc/config seems like pure bloat.
> 
> Don't ask me for sample code, but...
> 
> The init code for many drivers is freed up after it's used.
> Could we apply the same technique and compile in .config,
> then printk the entire lot (boot option) and free up the
> space afterwards?

Though this would save memory at run-time, you'd still increase the size
of the image.

-- 
-Steven
Freedom is the freedom to say that two plus two equals four.

Re: bug database braindump from the kernel summit

[Oliver Xymoron]

On Sun, 1 Apr 2001, Jeff Garzik wrote:

> On Sun, 1 Apr 2001, David Lang wrote:
> > if we want to get the .config as part of the report then we need to make
> > it part of the kernel in some standard way (the old /proc/config flamewar)
> > it's difficult enough sometimes for the sysadmin of a box to know what
> > kernel is running on it, let alone a bug reporting script.
>
> Let's hope it's not a flamewar, but here goes :)
>
> We -need- .config, but /proc/config seems like pure bloat.

As a former proponent of /proc/config (I wrote one of the much-debated
patches), I tend to agree. Debian's make-kpkg does the right thing, namely
treating .config the same way it treats System-map, putting it in the
package and eventually installing it in /boot/config-x.y.z. If Redhat's
kernel-install script did the same it would rapidly become a non-issue.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: bug database braindump from the kernel summit

[J . A . Magallon]

On 04.02 Oliver Xymoron wrote:
> 
> As a former proponent of /proc/config (I wrote one of the much-debated
> patches), I tend to agree. Debian's make-kpkg does the right thing, namely
> treating .config the same way it treats System-map, putting it in the
> package and eventually installing it in /boot/config-x.y.z. If Redhat's
> kernel-install script did the same it would rapidly become a non-issue.
> 

Could <installkernel> make part of the kernel scripts, or in one other
standard software package, like modutils, so its versions are controlled
and can be requested (in Doc/ChageLog, like other things) ?

Perhaps it could be put into a kernel-utils package with ksymoops, and
standarise the places and naming. I do not know if systems like Caldera,
SuSE or Debian adopted the /boot place for kernel things (standard kernels
still come with INSTALL_PATH=/boot commented-out), or the
vmlinuz-X.Y.Z naming.

I think the best solution would be to make /boot the 'official' place for
kernels, the -X.Y.Z naming an standard, installkernel should save System.map
and .config.

And you can add something like /proc/signature/map, /proc/signature/config,
etc to md5-check if a certain file fits running kernel.

-- 
J.A. Magallon                                          #  Let the source
mailto:jamagallon@able.es                              #  be with you, Luke... 

Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686

Re: bug database braindump from the kernel summit

[Jeff Garzik]

"J . A . Magallon" wrote:
> Could <installkernel> make part of the kernel scripts, or in one other
> standard software package, like modutils, so its versions are controlled

There is value in putting it into the Linux kernel source tree, in
linux/scripts dir.  But most vendors can and should take this script as
a sample, and customize it for their distro.  The Linux-Mandrake
installkernel script definitely gets touched every so often, and
decisions it makes, like updating lilo.conf or grub/menu.lst, or
autodetecting the boot loader, are definitely not to be applied for all
cases.

FWIW here is our /sbin/installkernel command line usage help text, to
give a glimpse of what it does and can do:

Usage: ${0##*/} -[lngarhcq] KERNEL_VERSION BOOTIMAGE MAPFILE

  -l:  Add a lilo entry
  -i:  Dont generate Initrd files           
  -n:  Don't launch lilo.
  -g:  Add a Grub entry.
  -d:  Don't autodetect boot loader.
  -a:  Autodetect boot loader.
  -r:  Features for RPM post install.
  -c:  Don't copy files.
  -q:  Be quiet.
  -h:  This help.


> I think the best solution would be to make /boot the 'official' place for
> kernels, the -X.Y.Z naming an standard, installkernel should save System.map
> and .config.

There will never be an official place to put this stuff, because that's
a distro policy decision.  A quick search just now reveals no reference
to /boot in the i386 Makefiles, and only a quick reference in the README
file.

> And you can add something like /proc/signature/map, /proc/signature/config,
> etc to md5-check if a certain file fits running kernel.

Additionally, everyone should remember: /proc is not a dumping ground :)

Ad-hoc naming like this has created the procfs namespace ugliness we
have now... let's not add to it unless we have to, and unless we have a
good idea of proper naming.

-- 
Jeff Garzik       | May you have warm words on a cold evening,
Building 1024     | a full moon on a dark night,
MandrakeSoft      | and a smooth road all the way to your door.

Re: bug database braindump from the kernel summit

[David Lang]

the reason for suggesting /proc is that this data needs to be available in
a standard place, putting it in the kernel image (compressed is fine,
bitmap is fine)  eliminates the problems of trying to dictate where in the
filesystem the distros need to put things.

putting it in /proc _somewhere_ (/proc/sys/kernel/config any better???)
avoids the need to invent a new place to put it.

one person suggested that instead of listing all the options in a nice
human readable format we could change it to a series of flags, that won't
quite work as there are three values for most options (Y,N,M) not to
mentions the ones that allow more values. you could still just list all
the config values without including the stuff to the left of the = it
would require matching up with the kernel version specific config file to
tell what is what but would cut down on the space needed.

David Lang


proc is overused, but putting the compile options

 On Mon, 2 Apr 2001, Jeff Garzik wrote:

> Date: Mon, 02 Apr 2001 18:09:05 -0400
> From: Jeff Garzik <jgarzik@mandrakesoft.com>
> To: J . A . Magallon <jamagallon@able.es>
> Cc: Oliver Xymoron <oxymoron@waste.org>, David Lang <dlang@diginsite.com>,
>      Manfred Spraul <manfred@colorfullife.com>,
>      Albert D . Cahalan <acahalan@cs.uml.edu>, lm@bitmover.com,
>      linux-kernel@vger.kernel.org
> Subject: Re: bug database braindump from the kernel summit
>
> "J . A . Magallon" wrote:
> > Could <installkernel> make part of the kernel scripts, or in one other
> > standard software package, like modutils, so its versions are controlled
>
> There is value in putting it into the Linux kernel source tree, in
> linux/scripts dir.  But most vendors can and should take this script as
> a sample, and customize it for their distro.  The Linux-Mandrake
> installkernel script definitely gets touched every so often, and
> decisions it makes, like updating lilo.conf or grub/menu.lst, or
> autodetecting the boot loader, are definitely not to be applied for all
> cases.
>
> FWIW here is our /sbin/installkernel command line usage help text, to
> give a glimpse of what it does and can do:
>
> Usage: ${0##*/} -[lngarhcq] KERNEL_VERSION BOOTIMAGE MAPFILE
>
>   -l:  Add a lilo entry
>   -i:  Dont generate Initrd files
>   -n:  Don't launch lilo.
>   -g:  Add a Grub entry.
>   -d:  Don't autodetect boot loader.
>   -a:  Autodetect boot loader.
>   -r:  Features for RPM post install.
>   -c:  Don't copy files.
>   -q:  Be quiet.
>   -h:  This help.
>
>
> > I think the best solution would be to make /boot the 'official' place for
> > kernels, the -X.Y.Z naming an standard, installkernel should save System.map
> > and .config.
>
> There will never be an official place to put this stuff, because that's
> a distro policy decision.  A quick search just now reveals no reference
> to /boot in the i386 Makefiles, and only a quick reference in the README
> file.
>
> > And you can add something like /proc/signature/map, /proc/signature/config,
> > etc to md5-check if a certain file fits running kernel.
>
> Additionally, everyone should remember: /proc is not a dumping ground :)
>
> Ad-hoc naming like this has created the procfs namespace ugliness we
> have now... let's not add to it unless we have to, and unless we have a
> good idea of proper naming.
>
> --
> Jeff Garzik       | May you have warm words on a cold evening,
> Building 1024     | a full moon on a dark night,
> MandrakeSoft      | and a smooth road all the way to your door.
>

Re: bug database braindump from the kernel summit

[J . A . Magallon]

On 04.03 Jeff Garzik wrote:
> "J . A . Magallon" wrote:
> > Could <installkernel> make part of the kernel scripts, or in one other
> > standard software package, like modutils, so its versions are controlled
> 
> There is value in putting it into the Linux kernel source tree, in
> linux/scripts dir.  But most vendors can and should take this script as
> a sample, and customize it for their distro.  The Linux-Mandrake
> installkernel script definitely gets touched every so often, and
> decisions it makes, like updating lilo.conf or grub/menu.lst, or
> autodetecting the boot loader, are definitely not to be applied for all
> cases.
>

I think that should be split in two, one thing is building and install a kernel
and one other is add the entry in your bootloader config ('update-bootloader',
for example, that looks into /boot and adds missing entries).

> FWIW here is our /sbin/installkernel command line usage help text, to
> give a glimpse of what it does and can do:

I know, run Cooker.

> 
> There will never be an official place to put this stuff, because that's
> a distro policy decision.  A quick search just now reveals no reference
> to /boot in the i386 Makefiles, and only a quick reference in the README
> file.

linux/Makefile, #INSTALL_PATH=/boot

> 
> > And you can add something like /proc/signature/map, /proc/signature/config,
> > etc to md5-check if a certain file fits running kernel.
> 

I usually think about /proc like the way to do a 'cat' instead of a 'syscall',
in this case to ask kernel for various md5 sigs,
but of course you can always write a user app that queries kernel and prints
result for your scripting pleasure...

-- 
J.A. Magallon                                          #  Let the source
mailto:jamagallon@able.es                              #  be with you, Luke... 

Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686

Re: bug database braindump from the kernel summit

[Tom Leete]

Oliver Xymoron wrote:
> 
> On Sun, 1 Apr 2001, Jeff Garzik wrote:
> 
> > On Sun, 1 Apr 2001, David Lang wrote:
> > > if we want to get the .config as part of the report then we need to make
> > > it part of the kernel in some standard way (the old /proc/config flamewar)
> > > it's difficult enough sometimes for the sysadmin of a box to know what
> > > kernel is running on it, let alone a bug reporting script.
> >
> > Let's hope it's not a flamewar, but here goes :)
> >
> > We -need- .config, but /proc/config seems like pure bloat.
> 
> As a former proponent of /proc/config (I wrote one of the much-debated
> patches), I tend to agree. Debian's make-kpkg does the right thing, namely
> treating .config the same way it treats System-map, putting it in the
> package and eventually installing it in /boot/config-x.y.z. If Redhat's
> kernel-install script did the same it would rapidly become a non-issue.

How about /lib/modules/$(uname -r)/build/.config ? It's already there.

Tom

-- 
The Daemons lurk and are dumb. -- Emerson

Re: bug database braindump from the kernel summit

[Oliver Xymoron]

On Mon, 2 Apr 2001, Tom Leete wrote:

> Oliver Xymoron wrote:
> >
> > On Sun, 1 Apr 2001, Jeff Garzik wrote:
> >
> > > On Sun, 1 Apr 2001, David Lang wrote:
> > > > if we want to get the .config as part of the report then we need to make
> > > > it part of the kernel in some standard way (the old /proc/config flamewar)
> > > > it's difficult enough sometimes for the sysadmin of a box to know what
> > > > kernel is running on it, let alone a bug reporting script.
> > >
> > > Let's hope it's not a flamewar, but here goes :)
> > >
> > > We -need- .config, but /proc/config seems like pure bloat.
> >
> > As a former proponent of /proc/config (I wrote one of the much-debated
> > patches), I tend to agree. Debian's make-kpkg does the right thing, namely
> > treating .config the same way it treats System-map, putting it in the
> > package and eventually installing it in /boot/config-x.y.z. If Redhat's
> > kernel-install script did the same it would rapidly become a non-issue.
>
> How about /lib/modules/$(uname -r)/build/.config ? It's already there.

It'd be great if we got away from the config being hidden too.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: bug database braindump from the kernel summit

[Jeff Garzik]

Oliver Xymoron wrote:
> On Mon, 2 Apr 2001, Tom Leete wrote:
> > How about /lib/modules/$(uname -r)/build/.config ? It's already there.

> It'd be great if we got away from the config being hidden too.

When exporting it outside the kernel tree, the '.' prefix should
definitely be stripped...  My preference is /boot/config-2.4.3 (with
/boot/config as a symlink to it)

Assuming your initscripts is smart about updating /boot symlinks, any
running kernel config [properly installed] can be grabbed with a simple
'cp /boot/config .'

-- 
Jeff Garzik       | May you have warm words on a cold evening,
Building 1024     | a full moon on a dark night,
MandrakeSoft      | and a smooth road all the way to your door.

Re: bug database braindump from the kernel summit

[Oliver Xymoron]

On Mon, 2 Apr 2001, Jeff Garzik wrote:

> Oliver Xymoron wrote:
> > On Mon, 2 Apr 2001, Tom Leete wrote:
> > > How about /lib/modules/$(uname -r)/build/.config ? It's already there.
>
> > It'd be great if we got away from the config being hidden too.
>
> When exporting it outside the kernel tree, the '.' prefix should
> definitely be stripped...

I think the same should be true for the new build system as well.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: bug database braindump from the kernel summit

[Miles Lane]

Oliver Xymoron wrote:
> 
> On Mon, 2 Apr 2001, Tom Leete wrote:
> 
> > Oliver Xymoron wrote:
> > >
> > > On Sun, 1 Apr 2001, Jeff Garzik wrote:
> > >
> > > > On Sun, 1 Apr 2001, David Lang wrote:
> > > > > if we want to get the .config as part of the report then we need to make
> > > > > it part of the kernel in some standard way (the old /proc/config flamewar)
> > > > > it's difficult enough sometimes for the sysadmin of a box to know what
> > > > > kernel is running on it, let alone a bug reporting script.
> > > >
> > > > Let's hope it's not a flamewar, but here goes :)
> > > >
> > > > We -need- .config, but /proc/config seems like pure bloat.
> > >
> > > As a former proponent of /proc/config (I wrote one of the much-debated
> > > patches), I tend to agree. Debian's make-kpkg does the right thing, namely
> > > treating .config the same way it treats System-map, putting it in the
> > > package and eventually installing it in /boot/config-x.y.z. If Redhat's
> > > kernel-install script did the same it would rapidly become a non-issue.
> >
> > How about /lib/modules/$(uname -r)/build/.config ? It's already there.
> 
> It'd be great if we got away from the config being hidden too.

How about adding a config tag that gets spit out along an OOPS
message.  We could add a flag to ksymoops that would cause that
flag to be read and the corresponding .config info to get looked
up (mechanism to be determined).  This might reduce the chances
of "new kernel tester" reporting an OOPS but sending in the 
wrong .config data.

	Miles

Re: bug database braindump from the kernel summit

[Miles Lane]

Jeff Garzik wrote:

<snip>

> /proc/pci data alone with every bug report is usually invaluable.  It
> gives you a really good idea of the general layout of the system, and
> you can often catch or become aware of related hardware characteristics
> which

I often see requests for the output of "lspci -vvxxx" when developers
are looking into problems with handling pci bus bridging and quirks
in specific hardware.  For example, this info has been requested of
me for debugging a problem handling my Neomagic 2160, at least one
bug in early Yenta code and so on.  Does /proc/pci get you all the
information that would be obtained with "lspci -vvxxx"?

> linux/REPORTINGS-BUGS was created to give users a hint that we need
> -more- information, and tells exactly what general information is useful
> to provide.  We do not need less information.

Agreed.

	Miles

Re: bug database braindump from the kernel summit

[Jeff Garzik]

On Sun, 1 Apr 2001, Manfred Spraul wrote:
> > There was a lot of discussion about possible tools
> > that would dig out the /proc/pci info
> 
> I think the tools should not dig too much information out of the system.
> I remember some Microsoft (win98 beta?) bugtracking software that
> insisted on sending a several hundert kB long compressed blob with every
> bug report.
> IMHO it must be possible to file bugreports without the complete hw info
> if I know that the bug isn't hw related.

Two comments --
* It's only disk space.  It's better to have and not need, than need and
  not have.  Please do give me 200kb bug reports!  :)
* There should be a way to allow the user to omit hw info, because the
  user may not want to disclose some parts of their system.

Regards,

	Jeff

Re: bug database braindump from the kernel summit

[Stephen Satchell]

At 10:54 AM 4/1/01 -0700, Larry McVoy wrote:
>     - one key observation: let bugs "expire" much like news expires.  If
>       nobody has been whining enough that it gets into the high signal
>       bug db then it probably isn't real.  We really want a way where no
>       activity means let it expire.

I have a couple of suggestions that may improve the bug tracking process 
without needing a bug czar or driving everyone crazy.

1)  The idea of letting a bug "expire" is a good one.  One way to do this 
is to incorporate some form of user-base moderation into the bug 
database.  Unlike some of the forum systems, there's no reason why we can't 
have tiers of moderators:  "maintainers" are the clearinghouse people for 
certain portions of the Linux kernel source tree and should have a larger 
voice as to whether a bug is important, redundant, or completely off 
base.  "contributors" are people recognized as having contributed in one 
way or another to the source tree (or, as the bug systems grows to 
encompass documentation, the documentation tree) and could serve as a 
"citizens advisory group" to speed the process of sorting the wheat from 
the chaff.  Also, a "contributor" would be able to "take ownership" of the bug.

2)  One of the big problems is recognizing that a particular bug has 
already been reported, and more importantly getting some sort of link 
between the new bug and the old bug.  When I ran a DVT operation, the 
developers found this linkage to be extremely useful in order to trace the 
source of bugs, especially really obscure ones that cut across a number of 
modules.

3)  In the commercial software world, there is a requirement that a bug be 
verified by someone "in house" -- in other words, a bug isn't a bug until 
someone can reproduce it.  This is a key item in separating the noise from 
the signal.  Again, the group-moderation system would permit quick 
identification of repeatable bugs.

4)  Using an NNTP interface would be interesting.  "Follow-ups" could 
consist of observations, commands, and requests for additional information 
from the bug report that isn't visible from the basic NNTP tree.  If you 
want to see more about a bug, the tree representation could let you pick 
and choose what you want to look at.  For someone who prefers to have 
everything to hand, a command would say "email sections a, b, ... to me 
(with "me" defined in the NNTP headers) and those sections would be mailed 
to the individual.

5)  Most important, the person originally submitting the bug should have an 
easy way of saying "never mind."  Existing search commands in the NNTP 
interface could make this a very easy chore for the infrequent contributor.

EXPIRING:  It's one thing to do an expire a la standard NNTP conventions, 
but it's quite another to do something "smarter".  I see a couple of things 
that would have to enter into a decision whether to expire a bug from the 
pending-status list:

a)  The bug needs to be present for more than a set amount of time without 
overt activity.
b)  A person trying to replicate the bug should be able to extend the 
time-out -- some bugs take longer to replicate than others.  If you don't 
allow for this, the bug could be expired before it can be verified, and the 
verifier has to work harder (assuming they even bother) to extract the bug 
from the data mine and get it to where a code guy can get to it.
c)  A maintainer should be able to sink a bogus bug early, especially if no 
one has owned up to trying to replicate it or fix it.  Contributors can 
heartily declare a bug "bogus", and if enough do so the bug could be sunk 
early.  Also, if enough people say "I can't replicate this bug" that's a 
good sign you have a piece of noise.

 From my own experience in commercial shops, I'd say that we could start 
with an expire time of two weeks, and if necessary adjust it.  Weighting 
for each of the metrics for expiring bugs could be set experimentally.  The 
goal is that a maintainer can squash bugs NOW, and the community could 
actively squash bugs in 24 hours.

IS THE BUG FIXED:  When a bug is declared "fixed" the bug tracking system 
needs to alert everyone who has submitted the bug and replicated it.  This 
notification would then let those people (those who are still interested) 
see if the patch really fixes the bug.  If it does, confirmation of a bug 
fix would be included, and that would help Alan & Co. to determine what 
patches should go in.

Just a few random thoughts on the whole process -- but I suspect others 
have already thought of these things.  I'd be interested in working on 
this, day job willing.

Stephen Satchell
satch@fluent-access.com

Re: bug database braindump from the kernel summit

[Olaf Titz]

> 1)  The idea of letting a bug "expire" is a good one.  One way to do this
> is to incorporate some form of user-base moderation into the bug
> database.  Unlike some of the forum systems, there's no reason why we can't
> have tiers of moderators:  "maintainers" are the clearinghouse people for
> certain portions of the Linux kernel source tree and should have a larger
> voice as to whether a bug is important, redundant, or completely off

As everyone thinking about this perhaps should know, this moderation
system is already used by Bugzilla: A bug report starts out as
"unconfirmed", and people who volunteer to triage bugs and are given
appropriate permission may elevate them to "new" status or resolve
them as invalid. The actual maintainers query the database only for
"new" bugs.

Experience in the Mozilla development community has shown, however,
that this is not as simple as it sounds. There are bug reports which
remain unconfirmed for weeks. People submitting reports have that
nasty feeling that they are being ignored. Really, I don't think it is
a good idea to stamp any bug report as "not to be taken seriously" by
default. It puts off people who know better.

With automatic expiry of unconfirmed reports that would be absolutely
devastating. Hopefully it is clear why. (Any pre-triaging process,
even without expiry, must be done quickly and have enough people who
do this unrewarding work, or it will introduce delays which make the
submissions increasingly worthless.)

I think that some sort of expiry is in order, but perhaps better the
other way around: any report with no progress in a certain amount of
time gets _higher_ priority, so that someone (perhaps a triager) is
"forced" to do _something_ about it (and if it's only to close an
issue which has long been fixed or is invalid from the start).

Bugzilla also does address some of the other issues presented here.
(No, I don't think it's perfect :-)

Olaf