Le 16/10/2012 06:08, Jeremy Bicha a écrit :
On 15 October 2012 13:50, Sebastien Bacher <[email protected]> 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
--
ubuntu-desktop mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
