> 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