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. 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. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel