Updates Criteria Summary/Brainstorming
kevin at scrye.com
Mon Nov 22 20:29:45 UTC 2010
Here's the latest list of ideas culled from this thread.
Note: these are NOT my ideas, I am just gathering them up so fesco can
Feel free to add more concrete ideas, or let me know if I missed one
you had posted. If folks could avoid "me too" or posts that contain no
new information it would be easier for me to gather the actual
I've split things into "General", "Security", "Critpath" and "non
security/critpath" to help organize them.
Keep the ideas coming...
* Just drop all the requirements/go back to before we had any updates
* 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.
* 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.
* setup fedora-qa package or group to more easily bring up more testers.
* allow security updates to go direct to stable
* ask QA to commit to testing security updates
* allow timeout for security updates before going to stable.
* allow critpath timeout for going to stable.
* reduce timeout for non critpath from 7 to 3 days.
* change default autokarma to 2 or 1.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101122/c1e6a24d/attachment.bin
More information about the devel