Stable GNOME updates, how could be do better?

[Bryce Harrington]

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?"

Also, as a rule the stuff added to x-updates are either upstream point
releases (which will have gone through upstream's QA cycle), or is a
fakesync from Debian (implying that it's been tested there).  So this
should help assure us that the code inside the package is tested.

Regarding support, of course we don't make promises about backporting
bug fixes and so on to x-updates (not that we're against it, just we'd
rather focus time on the main development repository).  But I wouldn't
put something in x-updates I did not feel to be a safe update, or that
would give me any sense of reservation in recommending people run it.

> If this PPA is described appropriately, and not prominently announced
> as "you should enable this!!!", there's nothing wrong with it, of
> course. I'm just a little afraid of people seeing it somewhere,
> enabling it, breaking their boxes, and then blaming us. But of course
> that's true for any PPA, so it's not specific to SRUs.

Right, and actually in practice I will pay more attention to bugs
reported against x-updates than I would some other random PPA, since the
Ubuntu-X team controls the QA policies, and since upstream will be more
interested in these bug reports (since they're against newer packages).

Indeed, part of the motivation for setting up x-updates (and its
inverse, x-retro) is a realization that if we *don't* provide something,
then random users will be making backports into random PPAs anyway, for
which we *won't* have any QA control over at all, yet which users will
still be reporting bugs with.  I'd rather spend a bit extra time upfront
and control the situation, so we don't end up wasting even more time
later on.

> > Second, I'm not the only person maintaining it; since it's a PPA, I can
> > enable people I trust (but who may not yet be core-dev) to do updates.
> 
> That's a fair point; it's a good way to get community-maintained
> updates to stable releases.
> 
> >  > 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).
> > 
> > I'd prefer users not feel the need to leave for something else (or at
> > least, not have to switch from Ubuntu).  So if adding -updates enables
> > even a small portion of our userbase to stay with us, it is a win.
> 
> Of course I don't like people having to leave Ubuntu. What I was
> saying is that if someone managed to run a stable release with known
> bugs for three (jaunty) or even nine (intrepid) months, the users
> who experienced dramatic regressions already abandoned it looooong ago,
> so there is little point in spending lots of effort for fixing small
> bugs, and doing it won't actually help to bring back those users.

Oh certainly I wouldn't argue that point.  But most of the benefit we
got from x-updates (and x-retro) came 3 months ago right after jaunty
was released.  Because those backports were immediately available,
people were able to upgrade (or downgrade) just their video driver and
thus were able to keep truckin' with Jaunty.  Certainly they weren't
happy about having the problem in the released Jaunty in the first
place, but at least being able to change driver versions gave them a way
to mitigate their issue locally and stay with Ubuntu.

There's another point worth mentioning along these lines that has been a
big driver for doing -updates, which is to help on OEM or support
customer issues.  In the past we (me, or the OEM team, or support, or
the customer) almost always ended up having to backport X bits for
stable releases in order to test them for solving customer issues,
however this was a huge amount of hassle.  Now, with -updates (and
-retro and xorg-edgers) it is much easier, and can be done in a more
controlled fashion with an understood QA process.

All in all, organizing an -updates ppa has been a huge net benefit for X
and I think it would make my job supporting X *harder* to not have it.

Bryce