Michael DeHaan wrote: > 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. provenpackager is the wrong solution to many problems. To me, the provenpackager/packager split was a welcome thing because it allows us to contain the *packager* group more strictly. provenpackager is not as useful because it is broadly what the old packager group was. If we were designing a group-style solution specifically to fit the need of having people who can step in and make corrections to packages then I'd advocate for a level above provenpackager that has stricter entrance requirements. >> 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). This makes a lot of theoretical sense but has had mixed results in practice. I can recall at least two drives to get comaintainers for packages in the past. This has had some more people sign up for comaintainership for some packages but it hasn't gotten us near to 100% coverage. Some of the things it doesn't address: Trust: If I'm a new contributor who just needed to get X.Y.Z in because I just started using it on my shiny Fedora Desktop, I may not have any contact with any other Fedora Contributor. If I don't trust the provenpackager group with this software, I'm not likely to trust an unknown packager who asks to be a comaintainer either. In fact, if there was an over-all group of people who seldom make a mistake and know packaging and software backward and forward, I'm more likely to entrust that group with the ability to modify my package than the random packager. Non-Responsiveness: If the package in question is getting bug reports from people about the low-hanging packaging bugs but the bug reports are not being answered even if there are two or more maintainers, there still needs to be a way for the changes to be applied to the packages. We also need to have a means of adding comaintainers when the maintainer does not answer the requests to add a comaintainer. A non-responsive, forced comaintenance policy would help deal with the second part of this problem. Interest in fixing an error that is easily checked for: Contributors like Michael Schwendt have written and run checks for specific packaging errors and then opened bugs for them against many packages. When the bug is not replied to, they have written patches. When those aren't acknoledged they have applied them where the acls are open. When the acls are closed the process breaks. A non-responsive: forced acl opening policy would work for this. Interest in a package: If the packager is the only one interested in doing work on a package, then there won't be a comaintainer. That doesn't mean that the package won't have common problems so that someone looking for common problems won't need to get changes applied to it later. > > 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? Some reports I'd be interested in seeing would be: 1) Open bug reports vs number of comaintainers 2) Unanswered bug reports vs number of comaintainers 3) Newer upstream versions (in rawhide) vs number of comaintainers > 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? > At the moment, the cvsadmin group has the ability to make commits despite what acls are in place. I don't think we're often called on to make changes to a package due to non-responsive maintainers, though. Instead, we have opened the acls and orphaned packages for non-responsiveness and people who are more interested in the package have then taken over and done the work. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
