Stable GNOME updates, how could be do better?

[Scott Kitterman]

On Wed, 29 Jul 2009 10:09:05 -0700 Bryce Harrington <bryce at canonical.com> 
wrote:
>On Wed, Jul 29, 2009 at 01:02:27PM +0200, Martin Pitt wrote:
>> > 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 have been experimenting with an x-updates PPA since Jaunty, and have
>been happy with the results.  Based on my experience I think some of the
>concerns are overstated:

We've been doing something similar for KDE in Kubuntu.  We pushed 4.1.3/4 
to intrepid-proposed/updates after PPA testing.  We put 4.2.3/4 in a PPA, 
but did not push it to -proposed/-updates due to both policy concerns and a 
minor regression that upstream did not pursue due to differing views on 
what Qt version we should have used.

All in all, I think these efforts have gone well and been well received by 
our users.

I think the workload concern is a non-issue as we are going to package it 
anyway.  

I think our experience shows we can both deliver a good improvement to our 
users as well as recognize when to hold off to keep the promise of -updates 
being regression free.

Scott K