Reconsidering the Gnome standing FFe

Scott Kitterman ubuntu at kitterman.com
Fri Sep 9 05:47:07 UTC 2011


On Friday, September 09, 2011 01:07:27 AM Martin Pitt wrote:
> 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
> developers).
> 
> > 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 the detailed response.

The things that concern me aren't known issues, but I see FFes coming in as 
recently as this week which are passed off as Gnome standing exception, upload 
with no real review.  Since they aren't really core desktop components, I'm 
not sure how much testing they'll get.

It might work out fine, but without at least a bit of review, it concerns me.

I think the ideal solution would be to adjust the cycle for "P" back to more 
like it was pre-10-10-10 (note: I want this for Kubuntu too).  If we could 
align our feature freeze to Gnome's beta, then I think the standing exception 
could be dropped with no harm.  If not, perhap standing Gnome exception up 
through our Beta 1.

Since  there's this added integration effort (not saying why or is it good, or 
bad, it just is), I think it's prudent to adjust to the new reality in how we 
manage this aspect of the release.  

I was discussing "P" planning with Kate on IRC today and gave her the KDE 4.8 
(what Kubuntu will use for "P") schedule.  If there is Gnome schedule 
information for "P" (I guess 3.4?), it'd be good to get it on the table (if 
it's not already) as she said she plans to work on "P" schedule next week.

Scott K



More information about the Ubuntu-release mailing list