From Fedora Project Wiki

Revision as of 20:03, 9 March 2010 by Toshio (talk | contribs) (Listing of update proposals)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

There are currently several competing proposals for what an update policy should look like. Listing them all on this page.

mjg's proposal

Introduction

We assume the following axioms:

1) Updates to stable that result in any reduction of functionality to the user are unacceptable.

2) It is impossible to ensure that functionality will not be reduced without sufficient testing.

3) Sufficient testing of software inherently requires manual intervention by more than one individual.

Proposal

The ability for maintainers to flag an update directly into the updates repository will be disabled. Before being added to updates, the package must receive a net karma of +3 in Bodhi.

It should be noted that this does not require that packages pass through updates-testing. The package will appear in Bodhi as soon as the update is available. If sufficient karma is added before a push occurs, and the update is flagged for automatic pushing when the karma threshold is reached, the update will be pushed directly to updates.

It is the expectation of Fesco that the majority of updates should easily be able to garner the necessary karma in a minimal space of time. Updates in response to functional regressions should be coordinated with those who have observed these regressions in order to confirm that the update fixes them correctly.

At present, this policy will not apply to updates that are flagged as security updates.

The future

Defining the purpose of Fedora updates is outside the scope of Fesco. However, we note that updates intended to add new functionality are more likely to result in user-visible regressions, and updates that alter ABI or API are likely to break local customisations even if all Fedora packages are updated to match. We encourage the development of mechanisms that ensure that users who wish to obtain the latest version of software remain able to do so, while not tending to introduce functional, UI or interface bugs for users who wish to be able to maintain a stable platform.

Critique

mether's proposal

Requirements for Critpath 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


Critical_Path_Packages critical path packages list

Requirements for 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

Critique

notting's Proposal

Introduction

We assume the following axioms:

1) Updates to stable that result in any reduction of functionality to the user are unacceptable.

2) It is impossible to ensure that functionality will not be reduced without sufficient testing.

3) Sufficient testing of software inherently requires manual intervention by more than one individual.


Proposal

For a package to be pushed to the stable updates repository, it must meet the following criteria.

  1. All updates (even security) must pass AutoQA tests. Rationale: If a package breaks dependencies, does not install, or fails other obvious tests, it should not be pushed. Period. Obviously, this proposal would not be enacted until AutoQA is live.
  2. Updates that constitute a part of the 'important' package set (defined below) must follow the rules as defined for critical path packages for pending releases, meaning that they require positive karma from releng and/or QA before they go stable. This also includes security updates for these packages. The 'important' package set is defined as the following:
    • The current critical path package set
    • All major desktop environments' core functionality (GNOME, KDE, XFCE, LXDE)
    • Package updating frameworks (gnome-packagekit, kpackagekit)
    • Major desktop productivity apps. An initial list would be firefox, kdebase (konqueror), thunderbird, evolution, kdepim (kmail).

    Rationale: These are the sets of packages where regressions most affect users, and would most prevent them from Getting Their Work Done. Furthermore, while I can accept that there may be some packages in Fedora that cannot find a significant enough testing base for all potential updates, I reject the notion that any desktop widely used enough that we deploy a image or spin for it would fit into that category. I accept that this places a larger burden on QA, and would expect them to be able to contribute testing to this initiative.

  3. All other non-security updates must either:
    1. reach their specified bodhi karma threshold
    2. spend some minimum amount of time in updates-testing, with a tracked number of downloads.

    Proposed time would be one week, but is open to negotiation.

    Rationale: We do want additional eyes on updates wherever possible. We do have one Fedora mirror that Fedora infrastructure controls; we should be able to mine this server for data on updates-testing downloads.

Any update that wants to bypass these procedures would need majority approval from FESCo.

Critique