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