[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Daniel P. Berrange wrote:
On Fri, Nov 07, 2008 at 12:08:23PM -0800, Toshio Kuratomi wrote:
I cannot allay your concerns and I can see your point.  I'd like to
mention, though, that func depends on the following packages with open acls:

pyOpenSSL, python, python-simplejson

So in terms of protecting against $EVIL, restricting provenpackager
isn't very effective.

It is, effective for restricting people in provenpackager from making
unaudited changes to your code, though.  So if you are a conscientious
maintainer who is on top of their bug reports, restricting
provenpackager could be good for everyone.  On the other hand, if you're
a maintainer that has too many packages and other responsibilities and
doesn't get around to fixing things (or at least showing presence on a
bug) quickly, having provenpackager set is a definite detriment.

IMHO, provenpackager is the wrong solution to that problem. Rather than
having a large group of people with commit to (nearly) everything for
fixing minor issues, the focus should be on significantly increasing our
levels of co-maintainership. The ideal should be for every package in the distro to have at least 1 extra co-maintainer, or preferrably 3 or 4. People with a little domain knowledge for the package who can handle both the low-hanging fruit the main maintainer misses, with less risk
of making mistakes due to lack of package specific knowledge. Sure it'd
take more people resources than 'provenpackager' solution, and likely require a big community publicity campaign to kick it off, but long
term it'd be more helpful & safer - particularly for 'infrastruture'
packages (python, perl, etc runtimes & important addon modules) and security sensitive packages (openssl, gnutls, func, koan, etc).
Daniel

Well said. Not just bringing up the problem but offering solutions.

How about we generate some reports on those packages that have one maintainer and ones that we need obviously need backup for? Minor issues that don't require an immediate fix /should/ be addressed with the project (i.e. permissions look wrong in spec file, etc) rather than being changed in CVS by someone and issuing their own builds. That seems to be the responsible thing to do.

I assume Fedora release engineering folks already have something-other-than-provenpackager access for emergency use anyway?

--Michael


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]