lkml.org 
[lkml]   [1998]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: CVS server for linux kernel
    On Mon, 5 Oct 1998, Matthew Kirkwood wrote:

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

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:0.021 / U:30.712 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site