Messages in this thread | | | Date | Mon, 21 Jul 1997 11:32:50 -0500 (CDT) | From | Mark Evans <> | Subject | Re: Linux Kernel Bug-list Website |
| |
On Mon, 21 Jul 1997, Horst von Brand wrote:
> There are bugfixes and random patches at <http://www.linuxhq.com> > allready. The Debian crowd has a bug reporting system going for years > now. Why do it again, and not just try to link together what is out there?
I agree, I try to catalog most of the bugfixes and enhancements at LinuxHQ. As for using the bug reporting system that Debian uses, here's my thoughts on this:
Debian, Apache, GNU, etc. are all very controlled development environments. They lend themselves to using a centralized tracking system. Linux on the other hand has a very open development model. Linus utilimately produces the kernel release, but input is taken from many sources. I doubt very seriously that most of the kernel developers are ready to sign up for a controlled reporting system, it simply isn't how Linux development is done (which is one of Linux's strengths in my opinion).
In my opinion, what I've been doing at LinuxHQ is the right thing to do, catalog the kernel patches, tracking when one has been included in a kernel release or when one is obsolete. This doesn't not impose any additional requirements on kernel developers or any kernel hacker.
I'm not saying that there isn't room for improvement, but I think trying to create a centralized bug tracking system where programmers must adhere to certain rules for reporting, testing and fixing bugs isn't the right answer either.
> The big problem I see is who gets to certify that (a) the bug is real, not > some misconfiguration or user error, and (b) check that it really _is_ > fixed by some patch or a new release.
I can tell you from first hand experience, this is a full time job! My approach has been to include patches on LinuxHQ with a reference to the patch developer and let them work out whether or not it is a bug. By watching the linux-kernel mailing list I'm able to filter most 'not necessary' patches out. Usually someone on the list will point out a config or setup option to solve the problem.
> I'd also note that the problems to solve are fundamentally different for > even/odd kernels: Stable kernels are _supposed_ to be "bug free", releases > last a _long_ time; development kernel releases are, umh..., "featureful" > and last a couple of days.
Tracking fixes in stable .vs. development kernels should probably be handled a little differently. Stable should imply 'works pretty well on most systems', I'm not sure you can ever call something completely bug free. As for the development kernels, well there is always something broken in them and there are usually a lot of version specific patches out there to fix things.
Anyway, I'm willing to enhance what I'm doing at LinuxHQ to help track fixes, etc. But, I think trying to duplicate the efforts of other more controlled development projects will fail.
Just my four cents worth...
-- Mark Evans Linux v2 Information Headquarters mevans@ecsnet.com http://www.linuxhq.com
| |