It's continuing effort is to facilitate large scale projects like The
Kernel...
-Shawn
-----Original Message-----
From: Jordan Mendelson [mailto:jordy@wserv.com]
Sent: Monday, September 27, 1999 3:32 PM
To: linux-kernel@vger.rutgers.edu
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/
- 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/