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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
