Re: GNOME 3.0 in March 2011
- From: Vincent Untz <vuntz gnome org>
- To: desktop-devel-list gnome org
- Subject: Re: GNOME 3.0 in March 2011
- Date: Thu, 29 Jul 2010 12:55:04 +0200
Hi Bastien,
Le jeudi 29 juillet 2010, à 09:56 +0200, Bastien Nocera a écrit :
> I believe I also mentioned that problem in various discussions at GUADEC
> and I would have expected the release team to come up with a good
> definition before telling people to backtrack on the changes required by
> the release team (like the goal to build 2.31.5 against GTK3, which
> would probably have happened before any GSettings port).
It's important to stress out there's no automatic choice of what's the
best way to handle things for a module. Here's an attempt to better
explain the situation and how to move for maintainers:
+ your module has not been ported to GTK+ 3: easy, just continue your
work, and keep pushing for the GNOME 3 goals from a platform
perspective (build with GSeal, port with GSettings, etc. and when
possible add a --enable-gtk=2.0/3.0 configure flag)
+ your module has already a configure flag to select which GTK+ to
build against: same as earlier, except that you already did your work
(good!)
+ your module has been ported to GTK+ 3: that's the case which is
causing concerns. We explicitly do *not* want people to just go back
to GTK+ 2 (that would be a regression towards GNOME 3). There are
three solutions:
- add a --enable-gtk=2.0/3.0 configure flag: for some modules, it's
really easy to do and it's enough. Frédéric did it for a few
modules, and here's an example in gcalctool:
http://git.gnome.org/browse/gcalctool/commit/?id=a2250ad2
- just release a new 2.30.x release with additional fixes: this is
perfectly fine, especially if the development in master is
explicitly targerted at GNOME 3. A good example here is gedit.
- create a gnome-2-32 branch out of the gnome-2-30 branch: you can do
this to achieve the same result as the previous option, but you can
also backport fixes that imply string/ui changes this way.
Now there's the question of how to decide which way is best for you.
Again, I would say it's up to the very short term goals of the
maintainers: some people might want to get some great features out to
new users in September, while some people only need to get some fixes
out, for example.
I hope that helps a bit. Thanks to Bastien for the discussion here in
the Hague that helped clarify part of what's missing in the
communication from the release team.
Vincent
--
Les gens heureux ne sont pas pressés.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]