User:Kevin/Updates Policy Changes Ideas Container

This is a unordered list of ideas to change/improve the updates process as put forth by many people in the fedora devel and test lists. This is an attempt to put down all these ideas for fesco to consider and act on as they see fit.

General:

• Just drop all the requirements/go back to before we had any updates criteria. (nuclear option, drop all updates policy).

• back off current setup until autoqa is ready, see what we want to do after that lands.

• Change FN-1 to just security and major bugfix. Nothing else allowed.

• allow packages with a %check section to go direct to stable. Or autoqa adds karma for them.

• setup a remote test env that people could use to test things.

• require testing only for packages where people have signed up to be testers.

• Ask maintainers to provide test cases / test cases in wiki for each package

• have a way to get interested testers notified on bodhi updates for packages

they care about.

• reduced karma requirement on other releases when one has gone stable

• aggregated karma across the releases for the same package version.

• PK updates-testing integration of some kind.

• allow anon karma to count. Or allow it to count less (.5).

• allow maintainer's to +1 their own updates

• setup fedora-qa package or group to more easily bring up more testers.

• Testing is only required for certain packages. Those packages are the packages where problems have occurred before so fesco or other maintainers affected by the changes deem it necessary to supplement the maintainer's testing with outside help.

• • Option: supplement this list with critpath packages where the maintainers desire extra testing. This means that we would no longer be dragging in dependencies immediately... only if updates by the dependency's maintaner to that package are breaking things.

• • updates that only modify the spec could have a lower requirement. (ie, to fix a packaging issue, no changes in the upstream software).

• enhance fedora-easy-karma to know about deps. (ie, if you +1 a firefox update, things that are also installed that firefox uses can be noted for +1 as well (libjpeg or the like). also, if you have libfoo note what things require libfoo so you can determine if it's working right).

• enforced min number of days in testing for some updates?

• have being sponsored into packager add you to proventester as well.

Security updates:

• allow security updates to go direct to stable.

* ask QA to commit to testing security updates QA isn't willing to commit to this at this time.

* allow timeout for security updates before going to stable. FESCo would like to allow a 1 week timeout for all security updates.

Critpath updates:

* allow critpath timeout for going to stable.

Non critpath/security:

* reduce timeout for non critpath from 7 to 3 days. Fesco thinks this is too short with the pushing time.

* change default autokarma to 2 or 1. Fesco thinks this is too small for a default. Maintainers can set it that way if the update is espcially trivial or easy to test.