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
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 | firstname.lastname@example.org
devel mailing list