GNOME 2.24: Worst release cycle I have been a part of [l10n/i18n]
- From: "Kenneth Nielsen" <k nielsen81 gmail com>
- To: "GNOME i18n" <gnome-i18n gnome org>, gnome-devel-list gnome org
- Subject: GNOME 2.24: Worst release cycle I have been a part of [l10n/i18n]
- Date: Sun, 12 Oct 2008 14:08:03 +0200
Hello my fellow GNOME enthusiasts
Ok so knowing that there is a tendency towards "Too Long Didn't Read",
if you think this looks to long, just skip to "A set of interesting
stats".
Now that the GNOME 2.24 release is well delivered, I though it was
time for a little evaluation. I am a translator, and as such I often
get exposed to the problems that are included, in trying to get a
bunch of hired people and volunteers working well together on a single
project. Some of these problem arise from communication problems
between the different groups and their lack of knowledge about how the
other group works, and they sometimes end up giving one or the other
group extra work. All of this is not uncommon, but this release left
an impression on me as being one of the worst ones I have had the
"pleasure" of working on. Lets recap!
gdm: I know that this particular problem has much more far reaching
implications than just translation, but let me emphasize how it looked
from the point of translators. Remembering last releases trouble with
gdm i decided to go proactive and on August 4 (right after module and
feature freeze, and release minus 1month20days) i wrote an email
asking which version we would be shipping. There is a total string
difference of 665 strings in between say version gnome-2-20 and trunk,
so it does have some effect on out workload. I was told that it was
pending a release team decision and that we would be informed within
two weeks. The next I heard of it was a mail on Sep. 22 (release minus
2days !!!!!) telling us that gdm trunk would be used. Thanks a lot.
libgweather: On August 4 (release minus 1month20 days)we were informed
of a major update in libgweather-locations. This update was so large
that it decreased all teams translation stats by about 5-6%. Obviously
the change had required a lot a work, and so could have been partially
committed earlier to give us some more time. But what is significantly
worse is, that in the following discussion on the gnome-i18n list
several incorrections in the string selection rule was identified
which can only lead me to the conclusion that the state of completion
this work is in, does not at all warrant the effort we were asked to
put in it. So thanks to libgweather-locations we, the Danish
translation team, were on Sep 25 able to proudly present[1] that fact
that we had gotten gnome 2.24 translated up to a whooping 96%, no no
not 100% as in the last two releases but 96%, nice! I am by way the
still working on it, where on occasion my left pinky cramps up from
all the "f C-j y tab" sequences in emacs.
evolution: Ok so this is not a problem that is limited to evolution,
it is just that much more visible here because it is such a big
module. In evolution this time there was an update of 368 strings, the
problem is that while going through it, I realized that a very large
part of these strings I had to update, was due to a change from ' or
" to " (I know there were at least 35 of the latter kind, the
first one is a little harder to grep for). This means, that if the
relevant devs had a some point taken ~15 minutes to discuss string
conventions, this update could have been avoided all together,
nice!!. What makes it all a little more funny is that I still saw some
' and "s left which means, that I can only assume that I will be
at it again next time. IF this is a general tendency, that means that
10% of the strings we have to update (that's about 4-600 strings) only
needs update because someone didn't bother making a convention, and
therefore essentially pi**** all over our efforts.
A set of interesting stats.
===========================
This is a list of modules, which the GNOME status page has told us on
the gnome-i18n list, that there has been made changes to AFTER string
freeze on Sep. 1 and until release. (I already sorted the ones out we
were told were false alarms).
eog 21. sep.
gtk+ 19. sep.
hamster-applet 17. sep.
cheese 15. sep.
tomboy 15. sep.
glib 15. sep.
hamster-applet 15. sep.
anjuta 15. sep.
hamster-applet 15. sep.
gnome-utils 8. sep.
mousetweaks 6. sep.
anjuta 4. sep.
gnome-session 4. sep.
deskbar-applet 3. sep.
Now I count 14 changes in there and _11_ individual modules. Surely
there is some amount of false alarms, and some legitimate freeze
breaks (i.e. the ones that are due to bugs that have been reported
very late in the release schedule). But there is also a fair amount of
"Ohh are we in string freeze"
"Don't worry, these strings will not be seen by anyone ;)"
"Calm down, this is not _technically_ a string freeze break, because
we just forgot to mark them for translation/add the file in
potfiles.in"
and
"Ehh, I have had this patch laying around for a couple of months now,
which fixes this really ugly thing, I really like to have it in and I
just forgot to commit it, would that be OK?"
's in there. Ok let my say this once so clearly that even a 10 year
old should be able to under stand it. IT DOES NOT MATTER FOR
TRANSLATORS whether it is technically a string freeze or not, new
strings means that we will have to update the module once more, and
really there are better things to spend our time on. Not knowing about
the freezes and old patches! Come on, you are asked to stay of of the
strings for 20 freaking days each release, how difficult can that be!
All right so in short.
Get a grip everyone!!!!
or this is going to stop being funny, in fact, if it hadn't been for
good company and large amounts of red wine during this translation
update, this release wouldn't have been.
Kenneth Nielsen
[1]http://www.dansk-gruppen.dk/
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]