Time-based vs. feature-based releases

[Christian Rose <menthos gnome org>]

tis 2003-08-26 klockan 02.03 skrev Duarte Loreto:
> We are still about 15 days ahead of final 2.4.0 release. It is in the users 
> best interes to have the keys there. It is in our (translators) best 
> interest to have those strings translatable. If some teams don't have the 
> time to translate them, at least those that have can do the translation. If 
> the strings get inside untranslatable, noone will be able to translate them 
> even having the time.
> 
> If the new strings are a bit incorrect (as they really are because HTTP(S) 
> should be uppercase as it is an acronym, like URI should also be, and 
> because of missing quotes, etc), at least they are there. And when we 
> translate, we can translate "correctly", open the bug and wait for the 2.4.1 
> to just remove the fuzzy mark as our translations were already correct...
> 
> This may sound a bit selfish as I spend the last two days going over all 
> gnome core modules looking missing accelerators and typos and normalizing 
> some expressions. But I usually think this way: "As a GNOME user (and 
> evangelist with my wife) I think it is best to have apps working correctly 
> although some strings are not translated than having a 100% translation 
> stats but then having problems using GNOME or explaining hackish workarounds 
> to my wife so that she can use her GNOME".

I don't know if many translators remember this, but in the past GNOME
used a feature-based release scheme. That meant that new GNOME releases
were only done when all features were done and close to all bugs were
fixed etc.

While nice in theory, in practice it always meant that GNOME releases
were delayed for *years* because there was always something that wasn't
"perfect", and many users were annoyed because GNOME seemed to never
make new releases, and important features or fixes that they needed and
that had been present in GNOME HEAD for sometimes a year or more wasn't
released in stable releases that distributions could use.

This was also very bad for translations. Since stable releases were
delayed for very long times, new or updated translations took forever
until they ended up in the distributions where most users actually had
access to them. All these things sucked bigtime, and in particular for
our users.


Nowadays, GNOME instead uses a time-based release schedule. That means
that release dates are decided and published well in advance, and the
releases will be made irregardless of if all features are ready in time
or all bugs are fixed or not. Things that are not ready or "perfect"
will have to wait for the next release; simple as that.

While this means that no release will be "perfect", it means that we
make regular, updated releases that our users get to use in their
distros, and they thus regularily get access to all the nice features
and fixes and new and updated translations that have been made in CVS in
the (not unlimited) time since the last release.

I know which one of these release schemes I prefer. With feature-based
releases, a user that needed translations for a certain language could
wait forever even though the translations for that language had been in
CVS HEAD for a long time, just because the GNOME release was delayed
because of other issues; issues that might not be relevant or useful at
all to that particular user.

With time-based releases, it's important to respect the freezes though,
so that the regular releases can be made on time. We don't want to do
releases full of bugs from things that were added in the last minute, or
even the last two weeks. In order to make sure things are not full of
critical bugs and that they actually work and don't seem too broken to
our users, we need a certain amount of testing, and a week or two is
very little time for doing that, not to speak of fixing those things and
everything that depend upon them. Things need to be *frozen* --
otherwise, if you poke in one place, other things need updating or new
testing, for which there is no time.

An excellent example of this is adding/changing messages after we've
entered string freeze. Added messages almost always contain typos or
consistency problems or other problems (as we as translators should
know) and then we are facing a new problem: Either breaking the freeze
again or showing erroneous messages to our users for a very long time.
If the freeze is broken again, translators need appropriate time to
update and verify their translations again, for which there may no time
-- and then we have new bugs. And so on.

The freezes are there for *our* benefit as translators, and for our
users' benefit in actually getting new timely versions of our software
with the stuff that has been improved. But it requires that we and
everyone else respects the freezes and can move on to work on improving
the next release instead of continously delaying or adding bugs to the
sudden-to-be-released release.

So those of you translators who have already translated GNOME 2.4 to
100%, have tested your translations and are now restless, move on to
translating with HEAD of the modules that have branched, instead of
wasting time requesting string changes/additions to our
very-soon-to-be-released GNOME 2.4 release. Those simply shouldn't
happen in GNOME 2.4.x. Go play with HEAD, and respect the freeze on
GNOME 2.4.


Christian