philippe makowski a écrit :
2011/7/8 nicolas vigier<[email protected]>:
I think the goal is not to do full regression tests, as we don't have
time for this. But do minimal testing, in 1 or 2 minutes, to check that
basic functionality is still working, to check that the update didn't
break everything. For LibreOffice that could be opening a test document.
Most applications are easy to test. But some require knowledge of the
software, or some configuration files, to test, so we could keep a list
of test commands or things to do and config files.
make sense
I agree
with a list of packages needing special consideration
Fedora have interesting rules about update/testing updates
Once pushed to testing, people are able to +1/-1 the updates "karma",
based on whether or not it seems to be functional for them. If your
update reaches a karma of 3, it will automatically be pushed to
stable. Likewise, if it reaches -3, it will be automatically unpushed.
If your update does not receive enough feedback to automatically push
it to stable, you will have to submit it as a final update yourself.
This can easily be done with the command-line tool, or with the web
interface
I like that approach, in general.
Although if it doesn't work for 1 user, but does for 4 others, it could end up
being pushed despite still having a bug.
(Likely if the bug depends on other apps installed, affecting only a subset of
users.)
they also have "proven tester"
https://fedoraproject.org/wiki/Proven_tester for critical path package
--
André
