Proposed udpates policy change

Julian Sikorski belegdol at gmail.com
Mon Mar 8 22:25:34 UTC 2010


W dniu 08.03.2010 22:59, Matthew Garrett pisze:
> 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.
> 
How about packages that have few people use? I almost never got any
karma on the updates I prepare.

Julian



More information about the devel mailing list