groups as owners in pkgdb (was: Re: time for perl 5.10.x in devel?)

Chris Weyl cweyl at
Sun Dec 9 19:33:38 UTC 2007

It bounced -- I forwarded back on 11/28.

On Nov 28, 2007 9:21 AM, Toshio Kuratomi <a.badger at> wrote:
> 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 at> 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.

Excellent.  So it sounds like we can rig things such that there should
be no legal issues to group ownership that I see -- though IANAL =)

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

Exactly it, AFAIK.  All members of perl-sig should be subscribed to
this group, so I suspect individual emails to the group members may be
a touch redundant.

If we were to do this prior to any impending work, I'd say make it as
quick and easy as possible (no sense doing something just to rework
it).  I don't know if anyone else is clamoring for this capability

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


I tried to be succinct; if there's additional verbiage needed I'd be
more than happy to update the ticket.

Chris Weyl
Ex astris, scientia

More information about the Fedora-perl-devel-list mailing list