Stable GNOME updates, how could be do better?

[Loïc Minier]

On Wed, Jul 29, 2009, Martin Pitt wrote:
> So, for stable updates we have several conflicting goals, in the
> descending priority:
>  1. keep it running 
>  2. keep it safe
>  3. make it better

 Absolutely agreed, and we're looking for a balance: not spending too
 much time on SRUs but still fixing some critical or annoying issues in
 stable releases.

 What I dislike about the SRU process is that all updates are treated
 equal: the most trivial updates require a lot of paperwork and have to
 sit for at least ten days, and the most wide ranging updates require
 just as much paperwork and might move to -updates after *only* ten days
 (and perhaps too little testing).
   I wish we'd have a better relation between pain/time to prepare a SRU
 and risk/complexity of the update.  I do understand that even small
 updates can have damaging effects though.

 Should we have some kind of honest risk metric when preparing a SRU?
 Of course the SRU process kind of requires one to ensure that no
 regression should happen, but there's _always_ a risk.  If we can
 quantify the risk better, perhaps that will allow for safer "complex"
 SRUs and to save pain and time on some simpler SRUs.
   I'm thinking that the work on defining upload permissions might allow
 seeing which packages are the most critical ones.  We could also
 consider things like the size of a patch or the popcon data of the
 SRU-ed package.  This could influence variables like number of
 reviewers, number of days in proposed, number of required tests.

 I think we discussed bug scoring on this very same list a while ago, so
 I'm not sure a scoring system for risk or SRU-ability wouldn't be as
 hard to define.   :-/


 [ On a side note, I don't like the argument that we should focus on bugs
 of the development release: most people can't run development releases
 for the caveats we advertize with them (might eat your data and
 children);  we wont catch all bugs and running the latest stable or
 latest LTS is part of the Ubuntu experience too.
   All these little things add up.  I'm sure most developers keep
 receiving requests by friends, family, acquaintances, or random people
 about this or that particular "annoying bug which they keep having and
 they don't understand why such an annoyance isn't fixed in Ubuntu". ]

-- 
Loïc Minier