Updates Criteria Summary/Brainstorming
kevin at scrye.com
Sat Nov 20 22:35:43 UTC 2010
ok, I dug through the devel list for the last month or two and wrote
down all the various ideas folks have come up with to change/improve
Here (in no particular order) are the ideas and some notes from me on
how we could enable them. Please feel free to add new (actual/concrete
ideas or notes):
* Just drop all the requirements/go back to before we had any updates
* Change FN-1 to just security and major bugfix
This may be hard to enforce or figure out if something is a major bugfix.
* allow packages with a %check section to go direct to stable
Bodhi would have to have a list or some way to note these packages,
it would also need to change as they were added/removed. Perhaps it could
just be an AutoQA +1 for having a check section?
On the con side, some checks may be simple and may not note things
that are fedora only issues.
* setup a remote test env that people could use to test things.
This would be lovely with some kind of cloud setup. Have a set of base kickstart
files and a package/tester could request an instance, install the update, test, and then
the instance would be removed. We would need a timelimit of some kind,
and not sure there is any HW in infrastructure for this, but it would sure be cool. ;)
Perhaps working with the cloud sig we could use EC2 instances for this?
* require testing only for packages where people have signed up to be testers
Packages without 'official' testers could bypass testing or have some lower karma
requirement. We would need for this a list of packages that have had people sign
up to test.
* Ask maintainers to provide test cases / test cases in wiki for each package?
Test cases are not easy to make, many maintainers won't can't do so, but
it would be lovely to have even a base checklist of things that should work
in the package everytime.
* have a way to get interested testers notified on bodhi updates for packages
they care about.
We would need to add some kind of tester list to pkgdb, and bodhi would need to be
able to get this to mail them when a update changed state.
We may not get many people signing up for some packages, but this might be a
good way to know what packages we have testers for and get them more involved
in testing. Ideally it could mail them on update submission at least.
* reduced karma requirement on other releases when one has gone stable
Bodhi would need to note when a update went to stable if the exact same
version (with dist tag differences) was in testing for other releases.
It could then allow less karma to go stable, or add +1 from the other
update going stable.
Other concrete ideas?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101120/7a0eea9a/attachment.bin
More information about the devel