[Desktop13.04-Topic] GNOME plans review

[Jeremy Bicha]

On 15 October 2012 13:50, Sebastien Bacher <seb128 at ubuntu.com> wrote:
> That's going to be a controversial topic but I want to suggest we stay on
> stable GNOME this cycle, the reasons are (in random order):

Well you've been following GNOME development for longer than many of
us. What is it that's making GNOME 3 releases more unstable than GNOME
used to be? Is it just that GNOME development has sped up and the
developers don't care enough about API stability?

> - GNOME is not communicating early enough on what is coming for us to
> discuss next cycle at UDS (see nautilus 3.6 in quantal)
>
> - GNOME is shipping stables with transitions half done (see gstreamer 1.0
> this cycle) which is not something we want in Ubuntu

The other big example this cycle is ibus. GNOME 3.6 doesn't work
properly without a not-released-as-stable version of ibus.
http://pad.lv/1045914

> - our "feedback loop" with GNOME is not really working nowadays, they don't
> have time to look at most bugs and we hit regressions and sit on them until
> somebody on our side has time to look at them, which means neither GNOME or
> us benefits much from tracking unstable GNOME...
>
>
> On the con side though:
>
> - it gives us less opportunity to work with upstream on resolving issues

This will hurt GNOME some too as a decent amount of issues are
reported first on Ubuntu. This will send some sort of message to GNOME
but I'm not sure that there's much of a conversation happening though.
In general, I think it would be a bad idea if we completely and
permanently switched to shipping the old stable release instead of the
latest stable release and the bug disconnect is one reason.

>From the way I see things, GNOME doesn't really support their stable
releases much either. The final point release is only two months after
the .0 release.

> - the new version of libraries might have APIs our app writers might want to
> use

While maintaining the GTK milestones is a headache, it would also be a
headache not to have them in Ubuntu.

I don't think this strategy will really save much work. The GNOME
milestone releases are likely to be packaged in a PPA any way. On the
other hand, I got involved on the Desktop team because there was
packaging work that needed to be done and the GNOME3 PPA made it seem
like less of a hurdle to contribute to.

I think most GNOME apps shouldn't cause any issues for the Ubuntu
desktop. There are about 2 weeks from Alpha2 to Feature Freeze, and
Alpha 2 approximately corresponds with the 3.7.5 release. By then, it
should be clear which apps could cause problems and there is time to
get the safe ones in.

> One element to think about also is how that would impact the GNOME remix if the plan there is not ship the latest GNOME...

Seb, I blame the remix idea on you. ;) Anyway, if the GNOME remix
becomes an official flavor, I was hoping to then ask for permission to
include the GNOME3 PPA due to our unique overlap with the flagship
Ubuntu release. It's still a bit of a handicap as I don't think we
could gain that trust if we included things that regressed Unity.

If we don't fork ubuntu-control-center and ubuntu-settings-daemon off
from gnome-control-center, then I don't believe it will be possible to
ship GNOME Shell 3.7/3.8 next cycle. The last two cycles we've shipped
the latest GNOME Shell but with bugs due to incomplete g-c-c/g-s-d
support in Ubuntu (for 12.04 it was http://pad.lv/965921 with keyboard
shortcuts not able to be configured from System Settings and for 12.10
it was 1045914 with a missing keyboard layout status menu). It's a
reasonable guess that for 3.8, the GNOME developers will move
aggressively to kill fallback mode and make optimizations and GNOME
Shell will depend on those newer optimizations.

A big reason for the GNOME remix is to show that you can contribute to
GNOME from Ubuntu. I worry about what happens when most users are
using a different distro than most developers. Shipping an outdated
GNOME means that we have a much less compelling story to tell these
developers.

Jeremy