Re: GNOME 2.0 Schedule

[Havoc Pennington <hp redhat com>]

STEPHEN BROWNE <STEPHEN BROWNE Sun COM> writes:
> Releasing often is fine as long as it is mainly for bug fixes
> and there is no API breakage or significant UI breakages.
> 
> How do we ever expect to be able to support a development
> platform for ISVs if we cannot guarantee API stability and if we
> dont make an effort to get rid of deprecated APIs and widgets.
> 
> The same goes for UI changes. Why deliver a desktop and then change
> the User Interface shortly after because we dont have time to listen
> to the usability people right now?
> 
> I dont know about other Gnome distributors, but from a SUN point of view
> I would really really not like to deliver multiple versions of libs
> (because porting didnt happen on time) and/or change (possibly
> radically?)
> the UI shortly after a fully supported release.
> 
> Support costs would go through the roof. 

Speaking from Red Hat experience, you have to think of it in the
following way. There is a continuously evolving open source
codestream. From time to time (on the Solaris release schedule), you
pull that code's best current version, and you branch/freeze in order
to stabilize what you'll ship. The last few percent of fixage will
need doing in-house, because a few translations, docs, whatever are
always out-of-sync with the state of the code, and there are always
some bugs you'd consider showstoppers. So you have to push your branch
into a releasable state, while taking care _not_ to get new upstream
versions that might ruin your freeze and introduce new problems.

As you're doing that, it's essential to schedule time to submit the
resulting patches upstream - it's easiest to do it as soon as you make
a patch, but as long as you schedule the time later, that works too.

(Random advice: it's also a very good idea if your patches are to
config files rather than code; it's even worth changing code to make
this possible, e.g. moving defaults out of the code into some sort of
file if you want to change the defaults.)

Anyhow, you should not need to upgrade to the latest GNOME until you
make a new Solaris release. There's no reason to keep pulling the
latest stuff. There's also no reason you need to ship GNOME 2.0.0 with
Solaris, rather than 2.0.1 or 2.2.

Doing it this way, your UI and API churn will be limited by frequency
of Solaris releases.


Anyway, why GNOME has to work in a more "churning" way:

An open source project absolutely depends on frequent releases to get
anything done. It also depends on changing things in small increments,
rather than trying to do a big long-term project. This is just how it
works; it's the only way that people can feed back an improvement and
immediately benefit from it. Also, if you let a project go long
without a usable release it rapidly gets in a horrible
100-half-finished-patches state that takes a ton of work to get back
into working order. Frequent releases impose a discipline that is 100%
for the better.

That said, yes while making frequent changes/releases we need to
establish a process for making sure that said changes/releases are
moving steadily in a coherent direction, instead of simply randomly
churning the UI and the API. We do need the UI project, docs, and
translations to sign off on UI changes, for example. 


However, in my mind the first step in all of this - before we can have
a process for _anything_ else - is to start releasing often. Because
if we don't have frequent releases, then _no one cares_ and we can't
even get volunteers to do the work of maintaining a process. So the
release team and release schedule should be our first priority for
now. If we release without feature X, then at least we'll now be
capable of making releases in a planned and coherent way; and that
means we know how to make a release that _has_ feature X, in a finite
timeframe, and it means we have people that are motivated enough to
implement feature X.

Havoc



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