Updates Criteria Summary/Brainstorming

Jesse Keating jkeating at redhat.com
Mon Nov 22 19:51:28 UTC 2010


On 11/22/2010 11:42 AM, Michael Cronenworth wrote:
> * Allow direct-to-stable
> 
> If "Signed-off" bodhi checkbox (web) or command option (tui) is provided 
> by the maintainer certifying that the maintainer believes the update 
> will work. The check should default to off, and always off, to require 
> human intervention. If the update fails to work then the maintainer 
> should be punished. Said punishment should be written up (yay another 
> policy) and might consist of losing the ability to push direct-to-stable 
> or loss of package ownership. I would prefer this option to be 
> *retroactive* in that the old offenders (dbus, firefox, thunderbird, 
> PackageKit, etc.) already lose their option to be d-t-s. You might put 
> in a clause to allow a "time-out" period where packages could be allowed 
> to be d-t-s again.
> 
> In retrospect, having direct-to-stable be "opt-out", instead of "opt-in" 
> as it is now, might cool the waters for some of the more noisy 
> maintainers. I'd be happy with this as a compromise to be a protection 
> feature and still allow liberal Fedora updating.
> 

You should clarify this.  It is possible for an update to go "direct to
stable".  If it gets sufficient karma between the time the update is
submitted (when people on bugs will get a ping) and when the next releng
push occurs (onceish a week dayish), the update will by-pass
updates-testing and go directly to stable.

For an update with an autopush karma level of 1, that could easily
happen, particularly if it's an update to fix something people actively
care about (read filed a bug about)

It sounds like what you're asking for is the ability to have a 0 karma
autopush limit.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


More information about the devel mailing list