Messages in this thread | | | Date | Mon, 27 Sep 1999 16:32:13 -0400 | From | Jordan Mendelson <> | Subject | The Linux Kernel Project Management System (INITIAL PROPOSAL) |
| |
This is just an initial proposal and some basic design information. I feel that it is necessary that kernel development evolve past the current model. With all the growth of Linux, more and more kernel related problems will arise along with more and more kernel developers and soon I feel the source will be unmanagable.
Questions and comments are welcome.
-----------
Linux Kernel Project Management System by Jordan Mendelson (jordy@wserv.com) 19990927
Overview
The Linux kernel is unlike most open source projects. Developers of the kernel source do not have the direct ability to write to the tree. Instead, patches must be submitted to the maintainers and undergo a peer review process. This system of management works very well for large projects with a large number of developers.
The official process for patch submission is to test your patch on your machine, have your patch tested by several other people and then finally submit your patch to the maintainer. This provides a good method for peer review, but all too often patches are submitted directly to Linus or Alan with little or no peer review process.
Bug reporting and tracking is done by hand. Bug reports are submitted to the maintainers or to the linux-kernel mailing list containing information about the crash or deadlock. These reports almost always are missing information necessary to diagnosing the problem. It is also difficult to track trends where people with the same hardware are all experiencing similar trouble. A bug tracking system would provide a good method for doing this.
The Linux kernel source is not currently maintained in an official central repository like other open source projects. CVS has become a very popular method of distributing and maintaining up-to-date versions of project source on various developers' machines. Unfortunately, CVS lacks the functionality necessary to maintain changes as separate entities and a simple method of distributing source among several repositories. The alternative solution is written by Peter Miller and is known as Aegis. Aegis supports all the features required for large project development including distributed repositories, change sets, and simultaneous active branches.
Documentation about internal kernel changes is sparse at best. During some of the larger changes in the 2.3.x series, the only documentation on these changes was scattered posts on the linux-kernel and other mailing list. Several features of the kernel source have not been exploited due to lack of documentation; people simply don't know they exist. With a management system in place, a self-documenting system of changes would provide a method of viewing these sort of changes in a patch-by-patch basis. This is not an ideal system for documenting the kernel, but it is better than what currently exists.
Detail
The idea is to create a single point where a developer or user could report bugs, view bug reports, submit patches, comment on existing patches, and receive information about synchronizing their kernel source directly with one of the repositories.
In my opinion, the best method of doing this would be web-based. Viewing patches and source online with the aid of tools such as LXR has proven invaluable.
Access to the Linux Kernel Project Management System should be limited with accounts. Read-only access should not require any type of account and free access should be given in this situation. It would provide you with the ability to synchronize your local source tree with a repository, view unofficial patches, and view bug reports.
User accounts would be required for anyone needing the ability to submit patches, comment on bug reports or existing patches.
Because Linus and Alan are the only ones to my knowledge that can directly release an official kernel tree, it may be acceptable to provide direct Aegis write access for them allowing direct manipulation using the Aegis command-line tools.
The bug reporting and tracking system can be a modified version of Bugzilla. Bugzilla has proven itself to be a very adaptable and usable system. The bug reporting system should allow bug reporting directly from the console without a web browser via an automated program that would gather system information, however the bulk of bug reports should be done with a web browser. The bug reports should contain all critical information including system components, crash information, etc.
The peer review system should be web based. The web provides an efficient means of managing something as complex as the Linux kernel. Patches should be sorted into individual sets, new patches, accepted patches, and denied patches. You should be able to comment on the patches. Patch comments should be delivered via email by the author if requested. It should be as tightly integrated with Bugzilla as possible as Bugzilla already implements most of the features required for the peer review system.
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/
| |