Updates Criteria Summary/Brainstorming

Michael Cronenworth mike at cchtml.com
Mon Nov 22 19:42:11 UTC 2010


Kevin Fenzi wrote:
> Other concrete ideas?

Quite frankly, I do not care for any of the ideas you mentioned. Here's 
some of my own:

* Reduce quarantine time from 7 days to 3 days

Reasoning: Mirror syncing. I'm not going to actively seek out and 
install 30 packages from koji every single day. I'd rather do a "yum 
update" and catch everything in updates-testing because those are what 
are needing testing. Mirrors typically need 24 hours to sync so 3 days 
will actually allow 2 days of testing. One day for me to install and an 
extra day just in case I don't update that day (weekend, etc). This just 
fits my needs though, so feel free to tell us why 7 days was chosen.

* 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.

* Implement "fedora-qa" meta-package

-Installs fedora-easy-karma for karma through TUI.
-Installs PackageKit plugin to give karma through the gnome-packagekit 
GUI. (Nothing exists yet, but I'm gonna get started on one soon)
-Auto-enable updates-testing.
-Provide a program to generate AutoQA scripts (in the future?)

This could be a checkbox in anaconda during the software selection. If 
we want to make QA a serious feature of Fedora it needs more exposure! 
Making QA easier and highly advertised would only help our cause.


Leave everything else as it is. There are only a handful of complainers. 
Fedora, for the most part, has become update error free. Yes, there are 
still kinks in the process. Let's iron them out. Also, once AutoQA 
starts churning against our packages then more of this becomes moot. 
Let's not forget about it.

Once we have enough manpower some of the other ideas about creating 
tester groups might be feasible but as it is today they would be more 
harmful than helpful to implement.


More information about the devel mailing list