Concerns about 'provenpackager' and why I didn't mass ACL open

[Michael DeHaan]

Jesse Keating wrote:
> On Fri, 2008-11-07 at 14:44 -0500, Michael DeHaan wrote:
>   
>> As I understand it, in general, provenpackager status requires packaging 
>> a certain number of packages (N).    In my opinion, this is insufficient 
>> and potentially dangerous and package access should be given under an 
>> "as needed" basis. 
>>     
>
> Small correction here.  Against my advise, the "has more than 5
> packages" mark was only used for the initial seeding of the
> provenpackager group.  From this point on, the way to get in is to
> request membership via the account system, and somebody already in the
> group has to approve the membership.  

This still seems a bit broad and unchecked to my liking.

The use cases for this are mainly what?   Maintaince of packages 
breaking other packages?

How large do we forsee this group being?

> It isn't the same sponsorship type
> thing that getting into packager has, once you approve somebody you're
> not ultimately responsible for them.  But we did want to make it
> something somebody has to explicitly ask for, rather than be
> auto-granted whether they want it or not.
>   
>> I am not really comfortable with opening that up.
>>
>> So, anyway, that's my logic ... if anyone can persuade me that releasing 
>> new code is /not/ possible through the provenpackager system, I think I 
>> could be persuaded to flip things, but right now, I can't see an 
>> advantage in doing so.
>>     
>
> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide.  But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time.  There are plans to enable co-maintainers to
> submit updates too, but that would again be specifically granted people,
> rather than members of a larger group.
>
> All that said, I don't think your logic is wrong, and I think it has
> been well thought out.  I just wanted other folks to know where you were
> coming from on these particular packages, mostly because it had seemed
> in the past you were very much in favor of a more open system.
>
>   

I'm definitely big on collaboration and openness and all that -- not so 
much on extending that decision as to when and what
to release of every software component.

If proven packagers cannot access non-rawhide updates, that's a 
reasonable check, but is EPEL still not exposed (i.e. can a proven packager
use the build system and then EPEL testing will pick up the code just 
like rawhide)?

I am basically looking at this in terms of the entire distro, and the 
potential for exploit -- those packages
are just the ones I keep an eye on to explain my actions there.

We obviously can watch the commit logs for package CVS, though something 
subtle has the chance to get
through.   I want to be sure our bases are covered.

--Michael