It bounced -- I forwarded back on 11/28.
On Nov 28, 2007 9:21 AM, Toshio Kuratomi <a.badger(a)gmail.com> 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(a)redhat.com> 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
yet.
> 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.
Done!
https://hosted.fedoraproject.org/projects/packagedb/ticket/109
I tried to be succinct; if there's additional verbiage needed I'd be
more than happy to update the ticket.
-Chris
--
Chris Weyl
Ex astris, scientia