Re: GNOME 2.0 conversation

[George <jirka 5z com>]

On Wed, Feb 14, 2001 at 12:37:00PM -0500, Havoc Pennington wrote:
> Summarizing a followup I posted, I think we get to pick two of the
> following:
> 
>  a) plan to release a significantly revised devel platform from 
>     its current state
>  b) plan to release a significantly revised user environment
>  c) release in 2001 (vs. say summer 2002)

I don't think those are the only choices really.  What I mean is that it is
not this clear cut.  Though those will most likely be the choices for
libraries other then GTK+ and gnome-libs.

1) gnome-libs is an improved and revised library from gnome-libs 1, though
   I've tried (and I think msot other changes as well) to keep as much source
   compatibility as humanly possible given what needed to be changed.  There
   is even a compat library that can be linked which has the deprecated
   widgets and functionality.

2) GTK+ 2 replaces some stuff that's now in gnome-libs and this needs to
   get some thought.  So, do we want to just dump all the gnome-libs
   redundancies and tell people to use gtk+directly (I do not favour this),
   or do we want to write wrappers that have gnome-libs 1 like API but work
   with GTK+2 internally.

3) GTK+ 2 already introduces a source incompatibility.  Trying to spastically
   keep compat in other libraries may in fact be far more work for everyone
   in the long term then to break compat for saner API/implementation in
   places.  Plus we now do have the chance.  Small API changes are easy to
   fix in user code, but they cannot be done when the platform is to be
   source/binary compat

What I would propose is that we do not do any major overhauls of our
libraries, but that we keep in mind that we can break compat if needed
for sanity sake.  And I think this has been the mode of operation for most
gnome-libs HEAD work in fact (this all reminds me that I've been a lazy pig
and haven't done anything there for a long while even though I promised I
would).  Most things that I did on gnome-libs head involved 1) moving things
into private structures 2) adding GtkArg, then GParam support, 3) porting to
new GTK+, 4) moving truly broken crap into libcompat

I don't want to get stuck in the mode that we were in now (and which this is
sort of promissing to be).  Where crappy, aging libraries are kept int he
devel platform (gnome-libs-1), where some things cannot be fixed for compat
reasons.  I really hate it when someone asks me about some thing in
gnome-libs and I say ... "Oh yeah, if you could use gnome-libs HEAD it does
this and you wouldn't have spent 3 days working around this"

> So I would like to see us articulate which one we are not doing for
> this release. Note that we can still work on a) or b) over the next
> year even if it's not in the release, it just won't have to be
> finished for this release, and the finished version will go out in a
> later release.

Well, I think most changes should aim for the gnome 2 release, but there
should be a backup plan if we can't deliver.  Even with an optimistic
estimate of 9 months, it's a year and a half before next release, which is
an extremely long time for software.  Of course this means that we should not
build interdependencies on things that we can't deliver in 2001 for sure, but
I don't think it should stop us from working on further things.

One reason I worry about this is that working on something that's not in the
upcoming release is utterly unsexy.  Look at gnome-libs HEAD, then look at
the number of recent commits.  What I'm saying is that with this attitude,
things that may take as long or longer then the release cycle will just never
get done.

George

-- 
George <jirka 5z com>
   The great masses of the people ... will more easily
   fall victims to a big lie than to a small one.
                       -- Adolf Hitler, "Mein Kampf", 1933

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers