Re: String/UI freeze and crying wolf

[Stanislav Visnovsky <visnovsky nenya ms mff cuni cz>]

On 24 May 2002, Kjartan Maraas wrote:

> Hi.
>
> Lately there has been some discussion around string/ui freeze for the
> 2.0.0 release. The main problem is that the freeze hasn't been
> hono(u)red and this has caused frustration among translators and
> documenters because they've been chasing a moving target.
>
> But, looking at it from the developer's view it's clear that they as
> just as much chasing a moving target and arguably the string freeze
> happened too soon. Various pieces of ui/functionality has just recently
> been completed and other pieces are still up for a rewrite (after
> 2.0.0).
>
> Also the large effort done by the ui-review team showed us a big lack of
> consistency and quality control of the UI as a whole. It would be sad if
> all this work wasn't included in the release.
>
> So - what can be done?
>
> - Carry on as we do now and force the freeze on the developers (ie.
> revert ui changes if they happen)

I think they need to happen really soon (=> let the already commited
there), but there is still some time left (June 17th for the last commits
of translations?) and then we should do something like KDE x.x.1 release
quite soon (about a month after GNOME 2.0, it should be for translation
updates and bugfixes, no pre-releases needed).

>
> - Look at how other projects handle this. Take KDE as an example; they
> did the 3.0.0 release and then froze things to make 3.0.1 a ui stable
> translations release. (and of course any necessary bug fixes as long as
> they don't touch strings / change ui)

KDE approach (my own experience):

1. Providing good enough standard interface and detailed style guide (in
other words, it's harder to develop inconsistent interface) and hard
janitorial work (usability team and others).

2. As to messages consistency/cleanup, the work is done by proof-reading
team (by en_GB translators) most of the time.

KDE x.x.1 releases are for less active teams to finish the translation and
to translate the docs (+ bugfixes without the message changes or
showstoppers). There is long enough message freeze before x.x.0 as well
(and the freeze broken from time to time as well) and it is not lifted for
x.x.1 releases- most of the active translation teams can get 100%
translations for x.x.0 release already.

>
> - Discuss other possible ways to handle this
>
> Please let us know what you think about this. What should be done now,
> what can be done long term to make the process more streamlined and how
> to make lives easier for both the translation/docs camps and the
> developer/release team camps.

1. dotPlan is not clear.
 - remove old schedules and left only the current one (I mean remove or
   hide those horrible "Revised schedule" notes)
 - markup important freeze dates
 - define the terms (what does UI FREEZE mean = no commits of translatable
   messages without approval of release team or something?)
 - set the last date for translation commits (it is PACKAGE DUE dates?)

2. Stick to the release plan
This way we can force developers to stop adding (hidden) features but to
squash bugs and stop adding new messages. And the release team needs to
enforce the deadlines.

3. I feel we have too many prereleases leading to lowering of their
importance for developers IMHO. I would suggest 2 betas and 1 release
candidate as a starting point.

And we should add a UI review period, since it's hard to get GNOME really
consistent.

Best regards

Stanislav