On 3 Jun 2017 8:33 am, "Pierre-Yves Chibon" <pingou(a)pingoured.fr> wrote:
On Fri, Jun 02, 2017 at 08:52:22PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jun 02, 2017 at 09:42:48PM +0200, Pierre-Yves Chibon wrote:
> With the deprecation of pkgdb2, pagure will make it even easier to give
> access to a package, if someone wants to help you maintain a
> just grant them access to the project on pagure. They will only
> that project and not anything else.
If somebody is given access to the package on pagure, does it allow them
do non-scratch koji builds and submit updates for that package?
Koji builds yes since koji does not check for packager membership, it is
a sync script who is allowed to do what.
We could make this script check the packager membership, that might be a
place to enforce it.
Bodhi I believe also check this, maybe Randy could confirm this.
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
I think to abandon the packager group for non-scratch builds would be a
The sponsorship to packager status is an important part of ensuring that
those joining the community are aware of the guidelines so they are more
able to follow the guidelines when updating a spec.
I think this would be less of an issue if koji required the packager group
(and not just an acl check of the package) to build the non-scratch
It would also be less of an issue if packages built didn't just end up
straight on rawhide but rather had to go through a bodhi gate, which is
where perhaps a packager acl check could also exist so that someone with
acl in pagure for that package could build it but not have it appear in any
Fedora repos unless they are in the packager group.
If I had the opportunity to choose the setup I think I'd lean towards,
anyone can authenticate to the dist-git via pagure (I'd even lean towards a
full open setup via oauth etc and not fedora account only). Anyone can PR
that is authenticated. Anyone in the packager group can be added to the acl
list for a package. Use that acl list to manage who can merge the PR and
who can build in koji and issue updates in bodhi.
I think that would result in the best balance of openness whilst preserving
the importance of what it means to join the packagers group in terms of
trust that the knowledge is there for the guidelines.
At least that's my two cents, even if it needs a little engineering in
pagure, koji and bodhi to get there.
Better to take our time and do something that will continue to provide a
solid base and standards than to shortcut and regret it later ;)