lkml.org 
[lkml]   [1998]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [OT] Roadmap to Improving Kernel Development (was: linus powertrip)
Date
I like this presentation. One of my thoughts this weekend, working on
the reduce Linus' workload aspect, concerned public testing. I imagine a
system whereby patches are public (like Jitterbug). Someone takes a
patch, then tests it thoroughly, and finally reports back to Jitterbug
that it works and corrected the problem. Linus could establish criteria
that (for example) he would not look at patches until there had been N
success stories.

There would be some refinements, since not all testers would be
considered equal. Alan Cox versus Joe Smith. Also, a report might be
fake, so an individual might lose his voting rights. And some types of
fix might be important so that Linus would skip over the default rules.
Some other fixes I have seem come directly from a manufacturor (like the
Cyclades board support) and would be accepted directly. So rules would
have to be flexible.

The big benefit is that patches with success story votes would usually
be of higher quality. Linus could be that much sure that they did what
they said... thereby making his work more efficient. And he could ignore
patches until they had success story votes.

Thanks for listening,

john alvord

On Wed, 30 Sep 1998 19:43:38 -0400 (EDT), Jordan Mendelson
<jordy@wserv.com> wrote:

>
>There has been a lot of talk about how the Linux kernel is getting too big
>to manage... so I thought of a few steps which would make things more
>productive and get changes into the kernel quicker: Right now, the kernel
>is roughly 53 megs of source and can be broken up into a number of
>subsections which are fairly seperate from eachother. These include the
>network subsystem, architecture specific code, and the memory management
>code.
>
>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

CDs @ http://www.cruzio.com/~billpeet/MusicByCandlelight

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.068 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site