Reconsidering the Gnome standing FFe

Martin Pitt martin.pitt at
Fri Sep 9 05:07:27 UTC 2011

Hello Scott, release team,

Scott Kitterman [2011-09-08 11:35 -0400]:
> As I understand it, the original purpose of the Gnome standing FFe was to 
> allow Ubuntu to update from Beta Gnome releases to RC and then final just 
> before Ubuntu's release.

Right. The requirement of doing this hasn't changed, but we don't do
these updates for a perpetual stream of new features, so the
"labelling" of these updates is indeed different these days.

> Based just on this, I'm not sure the standing FFe is needed (but I'm
> not very familiar with the current Gnome release cycle, so it may
> be).

In the first couple of Ubuntu releases we actually aligned our release
process and freezes to GNOME's. These days our feature freeze usually
comes a few weeks earlier than the GNOME beta, as we shortened the
development part of the cycle slightly, and also moved the cycle start
and release dates two or three weeks earlier. E. g. 3.1.90 (GNOME's
beta release, at which they start API/ABI/FF/UI freeze) was on August
30, while our FF was on August 11.

For this gap it would be useful to keep the standing exception. If we
don't have it, then we'd either need to keep the alpha versions (which
are usually not even remotely in a releasable and supportable shape),
or always ship the GNOME version from half a year ago (which would
been rather sad for oneiric as 3.0 was, well, a .0 release and thus
still quite bad compared to .2).

Alternatively we could move our cycle back three weeks again. A
10-10-10 incident won't come back again quickly, and AFAIUI this was
the main reason for moving the cycle in maverick?

> Additionally, now that Ubuntu is shipping Unity as it's default desktop, the 
> situation with Gnome upstream integration is a bit different than it has been 
> historically.  A Gnome upstream isn't the complete Ubuntu desktop with Ubuntu 
> patches added onto it, it's Gnome technology with a different shell on top.  As 
> a result, the integration challenge is, IMO, significantly different.

It's actually significantly different, but this applies a lot more to
things that actually change the GNOME stack, such as indicators and
the control center. It affects unity itself a lot less, as it really
quite a separate project. What does affect unity & co are API changes
in glib/gtk, so that's where we need to watch out for. OTOH this is
mostly a matter of communication/coordination there, we can't possibly
ship an alpha release of glib/gtk just because Unity uses an old API
there. We usually just update unity for the final API of the
corresponding GNOME release rather than patching all GNOME packages to
use the inofficial API (as this would also be bad for third-party

> Based on this, I think it's probably prudent to have some additional
> review of Gnome feature changes that arrive post-FF.  Gnome upstream
> is not in a position to understand how such changes might affect
> Unity, only Ubuntu can check that.

Fully agreed. There have been some cases this cycle where this kind of
disruption happened, and which took us some extra time to adapt our
Ubuntu bits; but that's the price you have to pay for diverting so
massively without bringing the stuff upstream, so I guess it's
unavoidable to get the occasional "adapt Unity to GNOME changes after
FF". Did you see cases which weren't handled appropriately/timely?
I'm interested in analyzing those and seeing what we could have
handled better there.

Thanks for bringing this up!


Martin Pitt                        |
Ubuntu Developer (  | Debian Developer  (
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <>

More information about the Ubuntu-release mailing list