Re: New rule

[Tristan Van Berkom <tristanvb openismus com>]

On Thu, 2010-10-21 at 17:52 +0100, Bastien Nocera wrote:
> On Fri, 2010-10-22 at 01:48 +0900, Tristan Van Berkom wrote:
> > On Thu, 2010-10-21 at 17:33 +0100, Richard Hughes wrote:
> > > How about, if you plan to break API, it's mandatory to write entries
> > > in the migration guide. Heck, even a quick email to the mailing list
> > > explaining how to convert code might be nice.
> > > 
> > > I'm getting really tired from people changing big parts of the API a
> > > few days before release, and then release teams expecting developers
> > > to produce tarballs that actually work. gtk-2.91.1 is broken for
> > > GtkComboBoxText, and gtk git master is broken for any GtkApplication
> > > using application. libnotify just changed API in a major way, which
> > > means we can't even use old tarballs until everything settles down.
> > > devhelp won't compile, so we can't even use the viewer application.
> > > 
> > > Could somebody please port all my projects. I've got better things to
> > > do than re-port all my stuff without a migration document. Again.
> > 
> > Initial thoughts, I suppose it's good to have a head start on 
> > catching up to GTK+ 3.0 by porting early, however the cost of
> > that is dealing with api shifts (all in all I think we should
> > appreciate the effort but in no way require this of anyone,
> > trying to catch up to GTK+ means you are helping us test new
> > api paths; that's great).
> > 
> > However I expect a general latency of around 3 or 4 months
> > after GTK+ 3.0 is actually released for very active projects to 
> > catch up and port.
> > 
> > If anyone expects to release GNOME 3.0 apps with GTK+ 3.0 release
> > all at the same time, I have to say that's a bit far fetched.
> > 
> > We should instead recommend that people port their applications
> > to GTK+ 3.0 *once we have an API*; after 3.0 is released.
> 
> 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 ?

> Porting after GTK+ 3.0 is released would set us back a number of months.

It should alleviate the pain of porting to an unstable API and changing
your code lots of times.

And applications that port to the new api after GTK+ 3.0 is 
released would only be released, a number of months afterwards.

How is it reasonable to expect anything different ?

> And it doesn't fix our problems of applications being unportable to the
> current GTK+ 3.x branch either.

If apps are actually not portable at all to the new api, that's
definitely a problem we should address before actually releasing a 
new stable api.

The api is a work in progress, the porting guide is also a work in
progress. I see little sense in wasting peoples efforts in rewriting
porting guide sections for any micro-point release based on an api
that may be subject to change before a stable release.

-Tristan

> 
> [1]: Thanks for the very helpful "RTFM" I got from the hackfest, if I
> could build devhelp, I surely would read those.