On Wed, 2011-04-20 at 23:52 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > 2 karma points *including* a proventester. That is: > > > > 1 proventester + 1 non-pt > > > > OR > > > > 2 proventester > > > > are sufficient. And yes, that is the current policy. > > Uh, that's the current policy for critical path packages, not for non- > critical packages which require only the autokarma set by the maintainer > (which can be as low as 1) to be reached. Unfortunately security updates are explicitly listed as to be handled like critical path packages, so Adam is correct in the current context, at least if the wiki page is not incorrect. There is a contradiction here: As some people noticed in the thread it is easy to fool the system for conventional updates by setting the karma threshold to a low value as you suggest. For security updates that need to be pushed rather earlier than later these requirements result in them being harder to be pushed. As a consequence if I as a packager were eager to fix a security issue I would indeed have to *not* tag it as a security update to reduce the ETA. This cannot be right and in general the discussion moved to how to fool the system with adjusting parameters etc. and to my surprise there aren't many that object to doing so! I think when it becomes normal to circumvent the system then perhaps we need to rethink it and implement it in a sane way? -- http://thimm.gr/ - http://ATrpms.net/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
