Proposed udpates policy change

Matthew Garrett mjg59 at
Mon Mar 8 21:59:29 UTC 2010

This is the policy that I expect to be discussed during the Fesco 
meeting tomorrow. This is entirely orthogonal to the ongoing discussions 
regarding whether updates in stable releases should be expected to 
provide features or purely bugfixes, and I don't see any conflict in 
introducing it before those discussions have concluded.


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.


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.

Matthew Garrett | mjg59 at

More information about the devel mailing list