Re: New rule
- From: Owen Taylor <otaylor redhat com>
- To: Tristan Van Berkom <tristanvb openismus com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: New rule
- Date: Thu, 21 Oct 2010 14:54:13 -0400
On Fri, 2010-10-22 at 02:26 +0900, Tristan Van Berkom wrote:
> > Except that we're talking about applications that are in the core
> > desktop (gnome-bluetooth, gnome-power-manager, gnome-color-manager,
> > gnome-packagekit, gnome-control-center), or in the default applications
> > (totem in my case, which also got bitten by the sizing changes, and that
> > I have no idea how to fix [1]).
>
> And having core desktop modules depend on an API that's still unfinished
> and still unstable is a good idea... because ?
There's three things going on here:
* As Bastien said, having the core of the GNOME desktop ported to
GTK+ 3 is incredibly useful validation of the new APIs.
* If GNOME 3 is going to ship against GTK+ 3, it has to be ported now.
We can't wait until 3.0 is out in December or January and then
start porting.
* The decision to base GNOME 3 on GTK+ 3 was made when it still looked
like GTK+ 3 was going to be ABI and minor API changes release.
The fact that major API changes are being made now isn't necessarily
a bad thing ... I was never too happy with the idea of a GTK+ that
just broke ABI for no good reason.
*But* it's unexpected, it doesn't really fit in with the planned
release schedule, and causes problems for trying to actually
work on the user parts of GNOME 3.
I think there's definitely a need for the people working on GTK+ 3 to be
respectful of GNOME 3, to make sure that making GTK+ 3 better doesn't
make GNOME 3 worse. That doesn't mean not making API changes, but it
does mean:
- Making sure there is information out about how to fix applications
that need to be fixed. If updating the porting guide is too hard
to do immediately, or you are changing something that was never
in GTK+ 2, then send mail to desktop-devel-list describing the
change and what it takes to deal with it.
- Considering how your changes fit in with the release schedule. If
GNOME 2.91 is going out on Monday, don't land a breaking ABI on
Friday.
- If your change is going to cause major breakage, figuring out
in advance what's going to break and work with maintainers to make
sure that there are fixes ready to go in immediately.
(And, yes, people have often been doing these things.)
In order for GNOME 3 to ship on time, to be a good release, it needs to
build every day. And that's going to require coordination between GTK+
and GNOME.
- Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]