Stable GNOME updates, how could be do better?

[Martin Pitt]

Loïc Minier [2009-07-29 20:47 +0200]:
>  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).

That's indeed a fair point.

I think that metrics like "size of the patch" or popcon data would
make the system too complex, and also the patch size isn't very
correlated to the potential regression risk.

What do you thihnk about starting with two classes, like "system" and
"apps"? "system" would be packages which affect boot and general
startup (kernel, X.org, libraries, bash, gnome-session), "apps" would
be packages which, when being entirely broken, confine the broken-ness
to itself (pidgin, totem, firefox). We could require 14 days of
testing and at least two verification acks for system packages.

I'm inclined to say that a broken Firefox or OpenOffice.org is still a
catastrophe, since it's a central piece of productivity for many
people, but at least there is always the possibility of uploading
another version with a fix again. If X.org or the kernel get broken,
or GNOME doesn't start any more, this is pretty much impossible to
repair for a casual user. So the classification should still make
sense even in this case.

Conversely, I don't see how the SRU process for "apps" could be made
simpler. It's pretty minimal under the assumption that we need (a) a
place where to document it (bug report) and (b) testing that the
package still works. If you have suggestions for simplifications,
please do mention them. (Although it's a bit off topic for this
discussion).

> 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.   :-/

Right, and further above you just complained that the SRU process was
already too complex. :-)

> [ 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);

I wasn't suggesting they should. Our current development community is
big enough to supply us with enough bug reports already, I feel. It
certainly would be great if more people could test the alpha and beta
live systems for hardware compatibility, though, since that's not
something the relatively small development community can cover with
testing.

> 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". ]

I do, mostly for driver issues, and long-standing bugs. My wife is
nagging me for months about the GNOME printer dialog being broken when
printing several pages to one. So she just keeps working around it.

But in fact I also get a lot of complaints that I get is "I updated
ubuntu, and now my killswitch is broken" (which was one of the cases
where I blundered an SRU, a seemingly perfectly obvious and small hal
patch didn't work in the hardy environment because the kernel had a
bug for particular Dell killswitches).

Based on my personal feedback, people get seriously p***d off by
regressions in -updates (understandably), and just annoyed by existing
bugs.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)