Proposed udpates policy change

[Luke Macken]

On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> 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.

I don't think this is ideal.

I'm having déjà vu from a lot of these discussions & proposals -- we've
been here before.  When I created bodhi, it initially disallowed pushes
directly to stable.  This behavior... didn't sit well with The
Community, for a variety of reasons.  As you can tell by the uproar in
every single one of these threads, if these same restriction are put in
place again we will lose a lot of important contributors.

Instead of re-implementing old controversial behavior, lets look at some
recent behavioral changes in bodhi and see if we can build on top of
those to solve these problems.

For example, I recently implemented various policy restrictions for
critical path/no frozen rawhide updates for pending releases.  In order
for a critical path update to get marked as 'stable' for a pending
release, it must have at least +1 karma from releng/qa members, and at
least +1 from an authenticated user.  These values, of course, are
configurable.

I think a much better solution would be to require similar critical path
policies, across *all* releases, not just pending ones, while still
allowing non-critpath packages to go directly to stable.

Requiring a static amount of karma across all updates is not going to be
sufficient, especially with the current karma system (which I think
needs improvement).  Especially now with the easy-karma script, people can
+1 dozens of updates at a time, reaching +3 will be almost too easy for
certain packages, and yet not not easy enough for others.  Having
configurable karma thresholds for different packages seems to be
sufficient, and it allows package maintainers to use their intuition to
tweak these thresholds accordingly to fit their workflow and tester
base.  For example, the kernel maintainers disable karma automation
entirely, and one could argue that this flexibility is important.

Regarding the current karma system, I think Doug Ledford brought up some
good ideas in the earlier thread 'Bodhi karma feature request', and
I know other bodhi developers agree.

With an improved karma system, stricter critpath update handling, AutoQA
integration, and giving The User more fine-grained control over what
types of updates they actually want, I think we'll be much better off
than we currently are.

luke