Chris, if this bounces from the list, feel free to forward it there.
Chris Weyl wrote:
On Nov 28, 2007 6:25 AM, Tom spot Callaway <tcallawa@xxxxxxxxxx> wrote:
On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the
pacakgedb, telling who is really allowed to touch the package?
and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an
"email alias" or a packagedb "alias" (should such thing exist)) as
owner ;)
Which, we can't do, without dirty hacks, currently.
You should talk to Toshio about this.
I'm unfamiliar with the limitations of the accounts/grouping/packagedb
system, but if we can have the accounts system enforce a requirement
that members of one group must be a subset of another group (e.g.
perl-sig group members must be members of the cla-done group), would
this satisfy the requirement that all package owners have signed
CLA's?
Yes, this part is currently possible. We're changing over to an LDAP
backend and better web frontend in a few months, though, so I don't know
the limitations and abilities of that system.
One other thing is that people would need to be a member of cvsextras as
well as cla_done in order to login to the cvs server.
Can we have a group own a package?
Not currently. Pseudo groups like the current perl-sig can own a
package but a real group cannot. This requires a bit of recoding in
order to change.
OTOH, letting a group be comaintainer (equivalent rights to owner) of a
package is fairly complete (there are a few places where we are
currently checking for cvsextras explicitly, but we can change those to
list other groups without much difficulty.
The biggest area where group ownership won't work precisely right at
this time is in the webUI. cvsextras is our only current group and we
aren't showing all the acls for it, just the commit acl. For the
perl-sig, I imagine that you'll want to have at least commit,
watchbugzilla, and watchcommits set. I can code this into the
commandline tool admins are using to set permissions but doing the same
for the webUI will require some rethinking of what it should look like
and how complex it should be.
I'm buying what Ralf is saying here: to attempt to have collective
ownership via individual ownership and extensive co-maintainers is
another variant of "dirty hacks".
Agreed. If you want to move forward with getting this working in the
packagedb you should open a ticket[1]_, we can try and record all the
changes we need in the packagedb and account system to enable the
change. Then I can talk to the FAS2 author to be sure it won't cause
him any grief when we migrate and we can code something up.
We're shooting to deploy FAS2 in February. So if there are
interdependencies between FAS and pkgdb that should wait on that
deployment we would do so after that.
.. _[1]: https://hosted.fedoraproject.org/projects/packagedb/newticket
-Toshio
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
