Stable GNOME updates, how could be do better?

[Martin Pitt]

Hello all,

I'm speaking in my role as Ubuntu stable release manager here.

Sebastien Bacher [2009-07-29 12:15 +0200]:
> The SRU policy is strict and doesn't allow to ship those updates easily,
> does anybody has some ideas on how we could do better and make those
> updates available to our users by some way?

From my point of view I don't consider this making it "better", but
"different". We did not grab the current SRU policy out of thin air,
but it was established after we got seriously burned several times
with updates which broke things.

As a premise, does everyone agree that a single regression in a stable
release is infinitely worse than fixing 10 small bugs? After having
installed a new release for more than a month, I dare to claim that
most users of that release either learned to live with its bugs and
found workarounds, or have already left it for something else (be that
a newer or older Ubuntu release, another Linux distro, or another OS).
In other words, the older a release is, the fewer bugs we need to fix
in it, since that will help fewer and fewer people.

Just as a random anecdote, I went to my sister over the weekend, and
while I was there, I upgraded her Intrepid laptop (just -security and
-updates, no -proposed). After that, GNOME wouldn't start any more, I
just got a black screen and a mouse cursor. I fiddled with
.xsession-errors, kernel/gnome-session/pulse downgrades and some other
things, but it was impossible for me to fix it in half an hour (then I
ran out of time, we had to leave). So I resorted to taking the laptop
with me, reinstalling it with Jaunty, and have it sent back to her.
This is a real disaster, and we have to avoid these things by all
means! I should probably not have touched the box in the first place,
but I thought it would be a good idea to keep it updated (at least for
the security updates). Usually, if she encounters a bug, then her
approach is "don't do that then", or she phones me for help and a
workaround.

So while we obviously didn't break everyone's Intrepid (we would have
heared about it), this still sucks. Even with the current SRU policy
we allowed too many (or the wrong) updates. I'm obviously not saying
that this was the fault of a GNOME package, I didn't have enough time
to debug the issue unfortunately.

Ubuntu is a mainstream distro now, and people rely on it more and
more. We aren't a "techies only" release like Warty any more, after
all, and have quite a high responsibility nowadays.

We must avoid regressions in updates at all costs, and thus need to
have a good knowledge about which kinds of changes go into a stable
release update, and the SRU procedure must ensure that this kind of
review and testing is feasible. Even if it doesn't ruin the entire
boot/login, a regression in a tool that you use every day is still
unacceptable for an OS which runs on many million production machines
out there.

So, for stable updates we have several conflicting goals, in the
descending priority:

 1. keep it running 
 
 We must avoid introducting regressions through updates at all costs.

 2. keep it safe

 We obviously need to fix critical issues like security
 vulnerabilities and data loss bugs.

 3. make it better

 Fix major regressions from earlier releases and bugs which impede a
 lot of users.

There is also another point which is often neglected by both us as a
distro as well as upstream: Every bug that we fix in a stable release
cost us a bug fix in the development release (while backporting
existing fixes is easier, you need to consider the necessary overhead
of testing the fix in the stable environment, and processing all the
uploads/packaging through the SRU team). IMHO it would be so much
better to fix bugs in the development release, and thus make the
_final_ releases better, instead of trying to keeping to play catch-up
in SRUs.

> One way would be to have a second source of updates which would not
> be "certified" in addition of the -updates which follow the strict
> sru policy, this one would not be enabled by default but easy to
> configure for users. Any other though?

Since this wouldn't be enabled by default (as you confirmed on IRC),
it would be similar to backports in the "opt-in, low barrier" sense,
but wouldn't get new software or major new versions. However, this
would make the cost:benefit ratio dramatically worse: You spend a
third of the developer time compared to a real SRU, but you only help
1/10000 of users (those who manually enable this pocket).

So frankly I don't personally see much value in having this new
component, but I don't object to having it, if other people consider
it useful.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090729/6afd6abc/attachment.pgp