That sounds like a fine idea, but I don't think things are implemented that way. provenpackager is (essentially) a special case, so each additional group would be an additional special case sprinkled throughout the code.

Cc'ing some other people who might be able to speak to this.

adding the group and the permission is easy. limiting the package set not so much.

there is 2 ways to do it. via a group like we have for secondary arches. but that grands blanket access to every package and overrides provenpacker also. so if someone opts out of provenpackager group access the secondary arch groups can still access it.

the other option is to make the group be in pkgdb the same as provenpackager. and add cod to pkgdb to give the access. the acls should propogate normally from there. we would need to double check the acl generating code. this option would require maintaining the list of packages that belong to this group.

The first option is a bigger hammer with less maintenance. but also grants far wider access.

i could be convinced to go the first route but think we should pursue the second one.

Hey thanks for the the quick turnaround. I appreciate it.

I think my preference would be something like:

desktoppackager group members can commit? [ ]

in pkgdb next to the

provenpackager group members can commit? [ ]

thing that's already there, and then we could just have a flag day one morning where we tag all the relevant packages.

If that's "hard", I'm also open to anything easier that achieves the end goal of "everyone on the desktop team can commit to any of the desktop packages"

Adding this to pkgdb would be the right way to do this but for expediency's sake, I can't advocate that. Packagedb was coded to handle two groups in its first release (provenpackager and packager) and allowing or denying those groups was exposed in the webui. Soon after, though, we moved down to one group (provenpackager) and gave setting that to only cvsadmins. Soon after that we moved to having provenpackager on for all but a few packages and no one has manually added and removed group permissions since then.

All this to say that the group handling in pkgdb is in an unknown state right now. It works for the one use case that we have (setting up a package originally) but it's quite likely broken for other things. So adding a new group to the mix may turn up quite a few bugs.

Added to that we have too many web services to maintain with too few developers to manage them and I think we'd be waiting for this to get to the production pkgdb instance for quite a while.

Replying to [comment:7 toshio]:

Adding this to pkgdb would be the right way to do this but for expediency's sake, I
can't advocate that.
Okay, no argument here. I only care about the end goal, not how we get there.

Soon after, though, we moved down to one group (provenpackager) and gave setting that to > only cvsadmins.
hmm, I don't understand this. Like I mentioned above, in pkgdb I have a checkbox already today to tweak provenpackager and i'm not in cvsadmin.

Added to that we have too many web services to maintain with too few developers to
manage them and I think we'd be waiting for this to get to the production pkgdb
instance for quite a while.
understood. Yea, any quick hack is fine with me.

Replying to [comment:8 rstrode]:

hmm, I don't understand this. Like I mentioned above, in pkgdb I have a checkbox already today to tweak provenpackager and i'm not in cvsadmin.

Unless we messed up (admitedly, since I'm in cvsadmin, I haven't checked this recently) the provenpackager checkbox should be set insensitive (ie: it's informational about the provenpackager status. It's not available for you to change the setting of).

Added to that we have too many web services to maintain with too few developers to
manage them and I think we'd be waiting for this to get to the production pkgdb
instance for quite a while.
understood. Yea, any quick hack is fine with me.

Yeah -- Dennis, what do you think? Still uncomfortable doing it the quick hacky route? I am trying to get the packagedb release process more healthy (as I did for fas) but with all the other work that we're doing in Fedora Engineering, I'm not sure if results of that are 4 months away or 12....

any news on this ticket, toshio ?

My time constraints look as bleak as before. I don't think there's anything new from dennis (He's on a plane today). Doing something like the secondary arch folks have is a very big hammer and it's not really justified here as it is with secondary arch (where a problem that they're capable of working on could happen to literally any package)

Suggestion as a workaround:

Keep a list of all packages you have approveacls on that are "desktop" packages, and we can help you setup a script to add someone to all those or remove someone from all those via pkgdb-cli ?
Then at least you can add/remove people from the pool as you like?

I guess the list is basically the packages here:

https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc#gid=

I didn't know about pkgdb-cli. that might be a viable workaround, though, on the aforementioned flag day, we'll probably have to get everyone on the team to run it

(that link is from hughsie's blog post here:

http://blogs.gnome.org/hughsie/2012/03/26/building-gnome-for-fedora-17/

)

Guess what? We are now actually close to having this in place (actually it is, we just need to test it and sort out any bugs).

The way it will work:

• a fas group of type 'pkgdb' is made.
• all folks who need commits are added to it.
• The email for the group is set to a list (private probibly)
• The group is made point of contact and has commit and/or optionally approveacls.
• users can be added/removed from the group as desired by the team.

We are going to be testing in the next week or two, but if you like we can test with you folks too.

I guess this is now fixed via https://fedorahosted.org/fedora-infrastructure/ticket/4596

Should we close?

I think so. ;)

Re-open if there's anything further to do here.

yup! thanks. The main impetus for this feature kind of went away because of workflow changes in the desktop group a couple of years ago. these days one person handles most of the packaging work. Still, i'm very happy the feature got added!

I'm just sad it took us 3 years. ;(

Anyhow, we got there finally...