Stable GNOME updates, how could be do better?

Scott Kitterman ubuntu at kitterman.com
Wed Jul 29 22:53:33 BST 2009


On Wed, 29 Jul 2009 13:31:24 -0700 Bryce Harrington <bryce at canonical.com> 
wrote:
>On Wed, Jul 29, 2009 at 07:28:14PM +0200, Martin Pitt wrote:
>> Hello Bryce,
>> 
>> Bryce Harrington [2009-07-29 10:09 -0700]:
>> > First, the developer time is pretty minimal.  Basically, most typically
>> > I'm just doing a s/karmic/jaunty/ and uploading to the ppa, or a
>> > fakesync of a debian release.  I might tweak a version in a control 
file
>> > or toss in a patch, but it's generally a very trivial amount of work.
>> 
>> Right, but that means that there is very little QA on those packages,
>> and thus users who enable it are pretty much entirely on their own.
>
>That's rather an overstatement...  In practice I won't even bother
>putting time into putting something into x-updates *until* I feel
>comfortable that it's lived in the development release (or xorg-edgers,
>or someone else's PPA) long enough to get some testing.  The whole
>principle of an -update PPA is that it has gone through some sort of QA
>process, even if it might not be to the depth or scope that an SRU would
>get.  The principle is to think, "What if every Ubuntu user enabled
>x-updates?  Am I reasonably confident this package won't introduce
>regression risk?"

Due to upstream testing, I think the risk of taking complete updates is in 
some cases lower.  

Additionally, when we had KDE 4.1.3/4 packages in intrepid-proposed we did 
find a few problems that upstream quickly fixed and we pushed into 
-proposed as patches.  Since we were testing their lates release, they were 
very interested in the problems we had and solving them.

Scott K



More information about the ubuntu-devel mailing list