A lot of this is rehashed ideas, but no one has layed out a good plan of
attack on how to deal with the situation.
Right now the current process (as documented in the MAINTAINERS file) for
submitting a patch is to make sure it cleanly applies, release a few ALPHA
versions for people to test and then submit it to the appropriate
subsystem maintainer. This needs to be expanded, a lot.
1) We need a bug tracking system split into the several subsystems which
exist in the kernel.
a) Each bug report should have the ability to allow other users
with different system configurations to add their configuration
to the list of affected machine types. This will make it possible to
tell if it is a hardware problem, compiler problem, etc much
easier. Maybe even a little message system which will allow
message posts to communicate about a specific bug.
b) The bug reports should require very specific information
including the motherboard, the current .config file, a cat of
various /proc/ files, the last messages that appeared on the
syslog, email address of bug submittee, etc.
c) Searchable bug interface, so someone can check to see if a bug
is already entered into the system.
d) Email updates to the person(s) who submit the bug reguarding
closure. This is very important as we want to be able to send the
person patches to try out.
e) Step-by-step bug submittion process. This should all be web
based (everyone has a web browser right?). Email bug submissions
would require a maintainer to do extra work (check if bug already
exists, etc), so working with a web based submission form we can
have the user offload some of that work for us. User should be
guided through searching previous reports for the error message or
kernel version, submission of the bug, etc.
f) Only allow bug reports on *OFFICIAL* releases! This is
important as it gets very, very, very confusing to track bugs on
some oddball patch which no one can get ahold of.
2) A patch repository should be once again established. LinuxHQ was at one
time a very good place for this, however ever since the original
maintainer left things haven't been the same.
a) This should probably be tied into the bug tracking system to
create a unified system for updates and fixes.
b) Patches should be classified into categories such as a fix to a
specific bug, a maintainer version update, spelling or other
minor mistakes, etc.
c) Some sort of automated test program should make sure that a
patch applies cleanly to a kernel and automatically reject a
patch if it does not cleanly patch.
3) A *private* CVS/RCS/Aegis (whatever) system exclusively setup for Linus
and other people listed in the MAINTAINERS file. This will reduce the
number of problems that we see with vger.
a) Linus should control access to this repository exclusively, so
we don't see random joe-blow uploading patches.
b) A mirror to this should be provided to specific sites for
*public* access. Public access will significantly reduce the
amount of traffic generated by people downloading kernels (poor
kernel.org).
c) Daily snapshots are probably not a good idea as they promote
increased bandwidth waste :)
d) Force documentation of each and every single change. I mean
real documentation, when you patch the kernel you state what
you are patching it for and why it is being changed. This should
allow bugs popping up in a specific version to be isolated easily
(or at least, easier).
4) This official bug-track-patch-track-etc information on how to get to
it, where mirrors are, etc should be listed in the top-level README file..
or dare I say it... it's own IMPORTANT file.
5) It has been suggested before that the kernel be split up into
architecture-specific versions. This would make the kernel source smaller,
however I see no practical way of splitting up the kernel. CVS style
revisions come close... but it still isn't practical.
6) WHERE-TO-GET-A-NEW-KERNEL file added to the source tree with a full
list of mirrors. No one likes it with when kernel.org gets overloaded and
it usually ends up in linux-kernel posts.
The number of posts on linux-kernel would be significantly reduced if
these points were implemented. There is so much traffic now on
linux-kernel that no one has time to read it all any more, bugs get
overlooked.. people who have serious problems have nowhere else to turn
and become fed up. I just wish someone like RedHat would put some serious
money into kernel development (change a some of those MAINTAINED lines in
the MAINTAINER file to SUPPORTED). There are some developers (Donald
Becker comes to mind) which are responsible for a dozen or more drivers
and realistically can't handle them all.
A good, clean system for tracking bugs, patches, changes in kernel
revisions would go a long way to improving productivity. Linus obviously
doesn't have the time to keep track of the entire linux kernel, so the
only patches which he should have to look at need to be tested with a
group of people who experience the problem, retested and finally submitted
to him for final approval.
Finally, Linus should, needs to be, and must remain the end-all to any
kernel submissions. This isn't saying that he shouldn't delegate someone
to help... but it should be understood that managing a large project like
the linux-kernel would be extremely difficult without someone like Linus
managing the entire thing.
Jordan
-- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/