Stable GNOME updates, how could be do better?
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>
>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
>> > 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
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.
More information about the ubuntu-devel