Updates proposal - alternative draft 1
Rahul Sundaram
metherid at gmail.com
Tue Mar 9 19:22:38 UTC 2010
Hi,
Since it is the fav season for proposals apparently, let me throw in my
Fedora/hat in the ring too. This only applies to updates to general
releases.
For critical path packages
(http://fedoraproject.org/wiki/Critical_Path_Packages) :
* Must go through updates-testing repository
* Only major bug fixes and security fixes.
* Must go through updates testing repository even for security fixes
Rationale: Expedited security fixes have caused some serious regressions
in the past (D-Bus, Bind, Thunderbird updates etc).
* Requires QA team to sign off on these updates and I will leave them
to define the criteria for it. I believe the criteria should be based
on feedback from testers rather than the number of days.
* Exceptions or expedited update requests must go via release engineering
Non-critical path packages
* Don't blindly push every upstream release as update
* Preserve stability and avoid unexpected changes and push updates with
enhancements only if the benefit is considered worth the risk of
potential regressions
Recommendations:
* Run AutoQA on all updates
* Hookup PackageKit to updates-testing repo and allow users to opt-in
and provide feedback easily
* Evaluate extending the criteria based on how well we succeed with a
more conservative update policy for critical path packages
Let me know what you think
Rahul
More information about the devel
mailing list