Granting to you specifically is possible but I'm not sure precisely who we'd want to say this is desired by the owners of the packages. Perhaps something along the lines of permission asked on the perl-sig mailing list. Then, after a few days without objection, I grant it for every package that has the perl-sig for watchcommits?

(Re: groups, this is something I'd like to see added to the pkgdb but it's a bit of work and no one's desired it enough to step up with a patch ;-)

Accept my apology for not backing this request up a fedora perl developer. I've been asked to submit this request by Marcela Maslanova. I will poke her to support me.

I'm reviewing all commits from Petr and he'd handled all request very well. I suppose you can grant him access, because he'll be mainly working on packages which are owned by me. At the moment we are working on all modules, which didn't pass perl-5.12 rebuild to solve whole issue faster.

If anyone is against access to his/her cvs, then please write comment into ticket.

I've no objection to Petr having access. But I wonder if it's better to go for the provenpackager route rather than a manual solution. It's not like he's some random contributor that could run wild - there's always a big red stick to beat him with if he oversteps the mark.

(and yes, perl-sig could really do with a provenperlpackager group. since there's already code for provenpackager, it doesn't look too difficult to extend that for one additional hard-coded group. not the ideal solution, of course, but we are by far the biggest sig that needs it)

I've recently joined the team to assist Marcela Maslanova and Petr Pisar.
I'd like to ask whether it would be possible to grant commit permissions for all perl packages to me (psabata) as well? The reasons are the same as Petr Pisar has already stated in this ticket.

Replying to [comment:5 psabata]:

I've recently joined the team to assist Marcela Maslanova and Petr Pisar.
I'd like to ask whether it would be possible to grant commit permissions for all perl packages to me (psabata) as well? The reasons are the same as Petr Pisar has already stated in this ticket.

That's true. Could have both Petrs granted access into these cvs?

There's been no objections. I'm working on doing this today.

This is now done.

As Ralf pointed in his email I believe watchbugzilla, watchcommits & commit would be enough. Aproveacl should have only maintainer. Also please remove all permission on Ralfs packages.

Can I remove approveacls for any package that they are comaintaining? If so I can do it in the db with a simple query. If not, there's some clientside coding and testing to make this happen.

Also -- I don't see anything in Ralf's email about removing all of their permissions for all of his packages. Just approveacls.

I've gone ahead and removed approveacls for ppisar and psabata for every package.

Please remove ppisar and psabata from any package for every permission!

Personally, I already set the permission flag for all my packages to denied for ppisar and psabata, because they're a) newbies, they b) didn't proof any packaging knowledge and they c) don't have a meaningful wiki page (which I consider as an absolute minimum for a Fedora contributor).

No.

I've already stated that I will remove permissions for ppisar and psabata if someone with approveacls/ownership of a set of packages gives me the list of packages that they want them removed from. There's no equality in removing ppisar and psabata's permissions for every single package and some people would have (ppisar was already granted comaintainership of all of mmaslano's packages before this ticket was even opened.)

If you believe they are too green to even have comaintainership of any packages, a much better approach would be to take the issue to FESCo. There is already a ticket open which somewhat addresses this issue: https://fedorahosted.org/fesco/ticket/403 There are several issues raised in that ticket that could lend itself to your goal. kanarip raises the question of whether the bar for being sponsored into the packager group needs to be raised, for instance.