Updates proposal - alternative draft 1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux