[Desktop13.04-Topic] GNOME plans review

Sebastien Bacher seb128 at ubuntu.com
Tue Oct 16 10:47:57 UTC 2012

Le 16/10/2012 06:08, Jeremy Bicha a écrit :
> 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?
I think there a different factors there:

- we never had great quality, Ubuntu is trying to address that and aim 
at better testing, less bugs, no regression, etc where GNOME didn't make 
that shift (yet?)

- GNOME2 has been "less dynamic" than GNOME3  (at least the 2.n version 
during the Ubuntu time, which was not the start of the 2 serie, by then 
things were already settled down and in maintenance mode) which also 
made for less breakages

- GNOME started to focus on "GNOME OS" and give less importance to what 
distributors think or do. It's a fair choice, they think they should 
better focus on building the best system they can do and should not 
compromise to "accommodate" others. I'm not even sure they see 
distributors as partners or if they just aim at deprecating those by 
shipping GNOME OS directly...

> 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.
Well, maybe we can see that the other way around. If we ship the stable 
serie we will fix bugs there, so by side effect we actually help to make 
the stable serie maintained. It might be a good move for GNOME and its 
users (for sure having stable series better maintained is a win for 
everyone right? distributations are supported for years and there are 
going to be lot of users benefiting of that).

> 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.
Well, my issue is not packaging, it's the number of people who come to 
us complaining that we landed GTK regressions in Ubuntu and that stopped 
them in their work... that includes:

- the people looking at the archive and build issues

- the people writing software on/for Ubuntu (ask the software-center 
guys how much time they spend tracking issues with GTK)

- the people dealing with library transitions (look at e-d-s in quantal, 
we ended up dropping e.g evolution-indicator from the archive because we 
couldn't find somebody who could keep up with the changes)

If we were just landing a new glib,GTK serie at the start of the cycle 
we would still have issues, but likely less of those (stable GTK ought 
to have less regressions than unstable versions leading to stable 
right?) and we would have them at the start of the cycle (where at the 
moment we often still fight new GTK regressions around beta1 and beta2 
time...). It's somewhat similar to the toolchain in my opinion.

>   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.
Right, most apps are fine (they sometime turn out to be problematic, the 
new file-roller this cycle being an example, upstream rewrote quite some 
code and it has been really buggy since), the issue is that GNOME has a 
tendency to get everything depending on the last glib,GTK versions, so 
it somewhat forces us to update those...

>> 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. ;)
Heh, fair enough ;-) I'm glad you picked the idea and I wished things 
were easier to work out there that they are at the moment...

> 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.
Right. Is there any reason we think "GNOME remix" has to be the most 
recent GNOME? If Ubuntu values quality shouldn't "Ubuntu GNOME remix" 
try to aim for being a solid GNOME remix rather than a crack of day 
GNOME remix?

Debian is not shipping the latests GNOME but it's still a quite popular 
choice for developers as a good GNOME desktop solution. OpenSUSE with 
its 9 month release cycle often ship GNOME n-1 in their stable as well.

Btw is their a "mission statement" for GNOME remix somewhere? Users have 
fedora if they want the latest version of everything, I think it would 
be fine and more oriented toward end user to set up on "a bit less new 
(but still new enough) but with increased quality", what do you think?

> 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.
Well, those are only pieces of the puzzle, important ones that we use 
for unity as well though ... but I don't think "forking" is the solution 
if the only disagreement is the version to use because that question 
will happen to other pieces of the stack (gdm for example in 3.6).

The "drop fallback code" that will happen in 3.8 is another thing that 
makes me want to be cautious this cycle. We don't know exactly how the 
changes will lay out. What pieces will we need to replace for 
Ubuntu/Unity. What does that means for "GNOME classic"?
> 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.
Yeah, that's the most annoying issue. If we have a "next-cycle-GNOME" 
ppa where the work is baked up it would benefit everybody though:

- GNOME remix could decide to use it
- developers could opt it in
- we would have the new stack somewhere to play with, run tests on, etc
- we would be ready early in the next cycle
- we wouldn't be impacted by the release cycle too much
- it should be easier to open that up for contributors, it might have a 
good impact on community participation

Sebastien Bacher

More information about the ubuntu-desktop mailing list