Updates proposal - alternative draft 1

[Michał Piotrowski]

Hi,

2010/3/9 Rahul Sundaram <metherid at gmail.com>:
> 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

Let's consider a case - there is a giant hole in kernel - and there is
a remote exploit somewhere in the wild. Do we want to wait a few days
or so when package will go through updates-testing? There should be an
exception to this rule for fixes for a _real_ security threads.

> 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

+1

>
> Rahul
>

Regards,
Michal