Toshio Kuratomi (a.badger@xxxxxxxxx) said: > A) cvs ACL system that understands groups. c4chris sent a patch that > should do this for the current code. I'll take another look at this and > apply it. It shouldn't actually do anything until we do the rest of the > steps. > B) a new group who's acl allows them to checkout/connect to the cvs > server but not commit. > C) Modification to our acl generating scripts to output the group > definitions and new acls based on them. Something like: > D) Upstream will need to have an account in the FAS. [*]_ > > 1: [all packages] | [anyone] | deny > 2: [all packages] | @cvsadmin | allow > 3: [packages with no current policy] | @cvsextras | allow > 4: [packages with policy] | user1,user2,user3 | allow > > Notice that this definition does not include the new group anywhere. A > user in the new group only gains access by being explicitly listed on a > line like #4. Will still fail without either filesystem level ACLs or permission changes due to being unable to write to the rawh files. Unless I'm misreading? Bill -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly