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 -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
