Stable GNOME updates, how could be do better?

Luca Falavigna dktrkranz at
Wed Jul 29 13:12:40 BST 2009

Martin Pitt ha scritto:
> 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.

This would happen if more users tested the beta release, but that cannot
be enforced, and a larger portion of Ubuntu users will wait the final
release, and then report bugs.

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

I agree with Martin's thought.

Currently, we have -security, -updates, -proposed and -backports. Things
are quite complex as they are today, probably as developers we don't
realize that, but the majority of our users will trust an update if they
see it via APT/Synaptic/whatever, no matter how many ribbons, warnings
and similer we're going to put into to invite to think about the task
they're going to do.

Another layer would add additional burden to developers with no apparent
improvements for final users (they trust whatever is enabled by default
and avoid forever whatever is disabled). And I don't think saying "go
and try -nonufficial-updates first" will increase overall quality but
will lower it instead.

What about using -proposed for every GNOME stable release? I think we
should definitely trust GNOME release managers, we already do this for
packages we includes in our stable releases without checking line by
line code they publish. If that sounds scary, we could use pinning to
allow update on demand only, so people who are really interested could
confirm an upgrade and test it in a more accurate fashion.

 . ''`.      Luca Falavigna
 : :'  :  Ubuntu MOTU Developer
 `. `'`     Debian Maintainer
   `-      GPG Key: 0x86BC2A50

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : 

More information about the ubuntu-devel mailing list