> Apart from the notification, surely this can be done at the back-end level
> with file permissions (ideally ACLs even 8) ?
Generally, filesystem perms, even ACLs, aren't quite enough to deal with
the kind of permissions you'd want in a repository, and given the
discussions of proceedure here, the kernel is going to need some pretty
detailed perms work if it goes into CVS.
I've written a near-complete set of back-end scripts for the SEUL
repository that enable an extreme amount of permissions control with very
little overhead (necessary constructed files are cached), and a lot of
extensibility. It's very capable of dealing with the issues involved in
putting the kernel in CVS with N developers accessing it. I've mentioned
it to Alan already, and if the kernel does end up in CVS at some point in
the future, I'd very much like to help with the process.
> . . . but surely people trusted to alter lumps of the kernel can be
> allowed a shell (or at least a UID) on some central box?
Presumably, yes. Ideally, though, branches would be used fairly
extensively to allow trusted subsystem maintainers to do their work
independently of the main trunk, checkpoint these changes at a known
working state (as in, actually compile and test by numerous people), then
hand them off to Linus for OK and integration.
IMO, branching is one of the coolest things about CVS. A perfect example
would be the 'ac' series kernels. They would be a separate branch, or set
of branches, that could be checked out as a whole from the repository for
testing, still be 'official' from Alan, logged and change controlled, and
relatively easily kept in sync with the main kernel.
Another thing we might want to look into is using Tinderbox and Bonsai
from the Mozilla project. In fact, that would be extremely cool, allowing
a lot of detail on kernel development and history to be surfed on the web
(Bonsai), and kernels to be automatically built on a set of machine of
various architectures (Tinderbox). I'm sick of QA as a job, but I'm
willing to make an exception to help set such things up for the kernel ;-)
In my spare time I'll play with CVS some more and see about the best way
to manage branching and such for the kernel. Likely some changes will be
needed in CVS itself to add enough hooks for proper operation, but I'm not
too worried about that.
TTYL,
Omega
Erik Walthinsen <omega@cse.ogi.edu> - Staff Programmer @ OGI
Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
__
/ \ SEUL: Simple End-User Linux - http://www.seul.org/
| | M E G A Helping Linux become THE choice
_\ /_ for the home or office user
-
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/