Re: GNOME 2.0 planning: A longer range roadmap

[Maciej Stachowiak <mjs eazel com>]

Havoc Pennington <hp redhat com> writes:

> Maciej Stachowiak <mjs eazel com> writes: 
> > 
> > ??-12-2001 - GNOME 2.0
> > 
> ...
> > 
> > ??-12-2002 - GNOME 3.0
> > 
> 
> I think I started this discussion out wrong, and we made it too
> complicated. What about this plan:
> 

I am somewhat confused by your reply. I don't understand why you
quoted just the above part of my message. Is your proposal below in
lieu of trying to make a longer-term roadmap, or a complementary
effort which will guide how we set up the roadmap?

>  - each release forever in the future is focused on user environment
>    features, as befits a desktop project

I 80% agree with this, except for the fact that we are trying to build
a platform for others to build on in addition to a desktop. You'd
better believe devel platform tasks are critical release blockers for
Windows and MacOS releases.

>  - for each compat-breaking release, we consider adding stuff to
>    libgnome, libgnomeui [1] that has been stabilized in a separate
>    module, and do cleanups for existing libgnome, libgnomeui features.
>    New features should never be "born" in libgnome or libgnomeui or
>    made a requirement for releasing those libs. The feature adds and
>    source-compat-breaking cleanups have to go in by a freeze date well
>    before the final release.

I agree somewhat about new features not being born in these
libraries. However, I wonder why you don't propose the same policy for
Gtk or GLib; the former is about twice as large as libgnomeui and the
latter about twice as large as libgnome.

I also really like the idea of having an API freeze date for the whole
GNOME world that is well before the ship date - as in months before,
not weeks before. Anything not done by that date should be backed out.

> 
>  - new devel platform modules can be added at any point release, 
>    as long as the maintainer considers the module ready to support
>    and is willing to freeze source/binary until the next
>    compat-breaking release.

Now this raises the point of new features being developed in modules
already part of the platform, besides just libgnome and
libgnomeui. For instance, for gnome-vfs we want to add authentication
callbacks, we want to add some new calls like
gnome_vfs_get_file_info_and_open to optimize performance, we want to
add more modules like ssh and rsync, we want to add caching,
etc. These are features that, in most cases, couldn't be done in a
separate module unless that module cut and pasted the current
gnome-vfs first.

>  - libraries do not have to be devel platform modules, they can be
>    "stuff the panel and Nautilus happen to share" or
>    "unreleased/experimental."  In general we should require #define
>    I_AM_THE_PANEL_OR_NAUTILUS type of stuff for these so people don't
>    use them accidentally.

I agree we should make more use of libraries that are not part of the
platform. However, I don't think the needed #define should be that
silly. How about just -DGNOME_USE_UNSTABLE_APIS.

> 
> Thus, we only have to worry about stabilizing the applications, and
> are never in a rush to stabilize supported APIs. The
> experimental/nonpublic libraries are considered parts of applications.
> 
> Basically we don't really ever want to stop development on devel
> platform or on user features, but the 1.5 year release cycle is really
> lame and detrimental to the project. So we make the project release
> cycle depend only on user features, and have devel platform work go on
> in parallel, much as GtkHTML, GTK+, Bonobo, etc. have been doing
> recently while gnome-libs remains frozen.
> 

The thing is that devel platform changes are sometimes directly tied
to user features. So for instance release goals like "make everything
use GConf" or "make everything use gnome-vfs" imply needed devel
platform changes (the latter could maybe get done as additions in a
separate module only), but also have a definite user benefit if
completed. I think we should explicitly have target releases in which
to complete such features, rather than letting them happen as they
may. 

In the case of gnome-vfs, since we can probably change all of the user
environment without incompatible changes to gnome-libs, the target
could be 2.2 rather than 2.0; maybe only some of the work will get
done for 2.0. But I still like having a target rather than leaving it
nebulous.

This is the whole reason for my proposal that we look more than one
release out, and tentatively schedule various features for one of the
releases. That doesn't necessarily mean it has to be a blocker for
that release, it just means that is what we are shooting for. 

And people (me and you included I'm sure) are probably way happier to
have their feature scheduled for some specific later release than to
be left out of 2.0 with no further statement on the matter.

 - Maciej