String/UI freeze and crying wolf
- From: Kjartan Maraas <kmaraas online no>
- To: GNOME i18n list <gnome-i18n gnome org>, gnome-doc-list gnome org, desktop-devel-list gnome org
- Subject: String/UI freeze and crying wolf
- Date: 24 May 2002 21:41:50 +0200
[sorry about posting this twice, I got the wrong list address for desktop-devel]
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
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)
- 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)
- 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.
(already wearing asbestos)
] [Thread Prev