Re: GNOME 2.0 conversation

[Havoc Pennington <hp redhat com>]

George <jirka 5z com> writes:  
> 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.

Answer is case-by-case. For the stock system, probably possible. For
GtkPixmapMenuItem also. For GnomeDialog, not possible. This is the
kind of cleanup work I think we can get done in time though.  What I
don't want to see personally would be new features and widgets. If it
merits a new header file, probably a bad idea, IMHO.

> 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

GTK 2 has some source incompatibility, but mostly for widget
implementors, it's really not very bad for application code (gftp
compiled unchanged a while ago, Dia ported in 1/2 hour). For widget
implementors even it's not really difficult to port, just some trivial
code rearrangment. So we shouldn't use GTK 2 as an excuse to go
nuts. That said, sure some breakage is OK.

Random rules we should follow:

 - If it the breakage results in old code that still compiles but no 
   longer works, it's very Evil. Breakage should break compilation so 
   it can get fixed.

 - Don't break stuff that's deprecated anyhow. Why port to the new
   version of a feature you shouldn't be using?

 - GTK has docs/Changes-2.0.txt plus a more verbose document I'm
   writing, need a gnome-libs equivalent.

> 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. 

Agreed.

When I say gnome-libs work is in conflict with user features, what I
mean by "gnome-libs work" is new features and finishing those. There's
time for cleanup by July or so, but not much else.
 
> Well, I think most changes should aim for the gnome 2 release, but there
> should be a backup plan if we can't deliver. 

What's the backup plan? If you have a half-finished gnome-libs, then
what are you going to release in its place?

I also suspect that we would constantly get the message that "it's
almost done" and thus keep postponing by a few weeks at a time.

Seriously, the only way to meet a timeline is to firmly chop the scope
of the project in advance... if we can't get people to agree to chop
features now, imagine the pain of getting them to agree when the
feature is already in CVS and needs "just a few more weeks."

I shouldn't say chop features though - I mean move them. Put them
somewhere besides gnome-libs. gnome-libs is a sucky place to put
in-progress features. It's a place to put mature features that people
are ready to leave alone.

We have foolishly been creating problems for ourself by bundling stuff
together when the maintainers or hackers working on said stuff aren't
on the same schedule. There's no sense in that.

> 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.

Right, that's why I'm saying freeze gnome-libs and put new features in
separate places, such as the experimental/app-specific libs (GAL,
nautilus-extensions), or Bonobo components. gnome-libs is the thing
that definitely has to have a release before we can do anything else.
Let's pop it into its component modules, so it's more
maintainable. Let's define a clear scope for the libgnomeui module,
and accept features in there only if they are already
finished. In-development or experimental features should go elsewhere.

> 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.
> 

Not if we uncouple things from the release. e.g. GtkHTML - moving
along nicely, not in any release. Imagine the pain if it were tied to
gnome-libs. But in its current location, it doesn't hold up a release
and the release freezes won't cramp its development.

Basically innovation should go on _outside_ the core release
components, so we can keep rolling new releases. Revisions of the
core devel platform should be rare. When stuff is finished and tested,
it can migrate into gnome-libs if that makes sense, in whatever the
next gnome-libs release is. But people should be able to start using
features before they hit gnome-libs.

So what I'm saying is, to make regular releases we shouldn't try to
stop all development on all apps and modules. For apps and modules
that aren't ready, we use an old version or no version, and those apps
and modules can hit the next point release, no problem.

The issue is that sometimes dependencies force us into some bundling,
e.g. the GTK dependency forces us to depend on the GTK schedule, ditto
for the gnome-libs dependency. Since that's true we should be
incredibly conservative about plans for those modules.

This is also one of the big reasons why bloat and
not-really-general-purpose features in core libs that everything
depends on are such a big problem. We need these core libs that really
block everything to be as manageable as they reasonably can be, and
encourage the use of add-on modules and "not part of the platform"
experimental/app-specific modules whenever possible. Otherwise we end
up with this enormous, unwieldy, never-ever-going-to-get-released
software beast.

We have to parallelize development, minimize communication overhead,
avoid forcing stuff into inappropriate schedules... i.e. minimize
interdependencies so the scale of the project is manageable.
Some code duplication is totally OK if it achieves this.

Did I ever say that before? ;-)

Havoc