Re: Bug-List (Was: Re: 2.0.31 Please)

James Mastros (abszero@epix.net)
Tue, 15 Jul 1997 21:16:17 -0400


At 01:28 PM 7/15/97 -0400, Tim Hollebeek wrote:
>Dave Wreski writes ...
>>
>> > You also don't need to be a hacker to help. The biggest single problem
with
>> > testing a new 2.0.x kernel is getting enough test data. Every single
person
>> > who sticks 2.0.31pre3 (when its out) on a machine and sees if it works
-even
>> > if the stick it on for the day and reboot back to 2.0.27 before they go
>>
>> I had an oops with pre-2, and reported it, but never got a response. My
>> subject was descriptive enough that the appropriate person should have
>> seen it.
>>
>> Is it normal procedure to not see a response to an oops? Now that the
>> bugs are less and less common, isn't it possible to keep a master list,
>> and check them off as time goes on (ie, the person that reported the bug
>> no longer can induce it?)
>
>Great idea. It would be a lot of work. Are you volunteering?

Sounds good to me to. He might not be volunteering, but I am. So, I need
to know some stuff before I begin:

(In approximate order of importance)
1. Who else is volunteering?
2. Can we get a program put in the official kernel source distributions to
semi-automatically report data?
3. What data do we need from the reporters?
4. Anybody volunteer to house this beast (includes an email -> processing,
and processing -> html, and a http server)?
5. Ideas on possible privacy issues.
6. Can we put this in commercial linux distributions (Slackware, Red Hat,
Debian, et al (in NO PATICULAR ORDER))?
7. Anybody already working on this?
8. Would major linux sites give reference (or data) to us
(www.linuxhq.com, www.linux.org, sunsite.unc.edu, etc.)
9. Anything else we should know.

OK, explanation and preliminary answers for those:
1. I can't program well, I don't have a server, I don't have connections.
2. Probably a shell script that would generate and send an e-mail, it
wouldn't be to large.
3. Kernel version, version of critical packages (init, shell, stuff listed
in Changes, etc.), e-mail, name, h/w info (bunch of stuff from /proc),
.config (greped to get out comments), end of some logs, and what else?
4. We would have to have a stable e-mail to send the data too, since it
should still be there even if somebody uses a 2.0.32 kernel when 4.0.42
(not typo) is the standard.
5. Do ppl mind having this data publicly available? Could some of these
data-sources have sensitive data in them (especially logs)
6. Reply on this only if you are authorized to do so, please...
7. URL for that testing suite talked about aprox. 6 mo (?) ago.
8. Debian at least keeps a database of bugs. Would they give data on
kernel-related ones to us?
9. Sky is not the limit, we have to deal with bug-reports from space. <G>
10. Just how much have I gotten myself into?

Can't think of anything else,
-=- James Mastros