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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
