Updates proposal - alternative draft 1
 

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Updates proposal - alternative draft 1
 

Hi,

2010/3/9 Rahul Sundaram <metherid@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Updates proposal - alternative draft 1
 

On 03/10/2010 01:12 AM, Michał Piotrowski wrote:
>
> 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.
>
As opposed to fake security threats? In the case of the kernel, if the
new kernel update we rush through without passing via updates-testing
repo doesn't boot you can always boot back into an older kernel but
other packages typically do not have this privelage and we need to be
cautious about this and if there is a really need to expedite the update
for whatever reasons, it is already covered by one point in my proposal
and I repeat:

* Exceptions or expedited update requests must go via release engineering


Rahul

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

Updates proposal - alternative draft 1
 

On 03/10/2010 01:24 AM, James Laska wrote:
>
> Just a heads up. AutoQA describes the framework. We'll need to be more
> specific about what tests we'd want AutoQA to execute against the
> updates.
>

Sure but I don't know all the details and I am not trying to cover
everything but provide the basic idea to extend. If you want to comment
on this specific area with more details, I would be glad to add it to my
next draft.

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

Updates proposal - alternative draft 1
 

On Wed, 2010-03-10 at 00:52 +0530, Rahul Sundaram wrote:
> 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

Just a heads up. AutoQA describes the framework. We'll need to be more
specific about what tests we'd want AutoQA to execute against the
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel