Re: Moduleset Reorganization -- Take two

[Petr Kovar <pmkovar gnome org>]

Hi!

Kenneth Nielsen <k nielsen81 gmail com>, Thu, 14 Oct 2010 10:34:13 +0200:

(...)

> If I give it my best at being a little frexible, I think we can make
> it work from a l10n point of view. The key is information and
> overviews. I think not everybody understands just exactly how
> important damned lies like functionality is to us translators and how
> much we use it. The reason is that we usually touch a lot more modules
> than any other contributor group. We frequently browse through lists
> to find work and access progress. So if... the Apps module set will
> have its own page in damned lies and if... string freeze and release
> dates are present there on that overview list, for the apps that don't
> follow the GNOME release schedule, and if.... the number of those apps
> are kept low, then I think that is still a workable solution.

If asynced release schedules eventually become reality for official GNOME
modules wherever they might be hosted (I still hope it's avoidable, though),
I think many GNOME translators would really appreciate having the following
as a hard requirement:

* string freeze period lasting for a reasonable amount of time (some might
think that having a string freeze for two days is enough, well, it is not),

* string freeze break requests handled the same way that it is now,

* release schedule presented on a special overview page at our l10n
infrastructure, timely (as Kenneth writes; probably less suitable way would
be to announce it to the gnome-i18n mailing list, as it is done now
voluntarily by some enlightened maintainers of unofficial modules (thank
you!).

Surely, having no synced schedule is barely an improvement for l10n
support. Among other things, translators would be unable to do some
common changes (e.g. terminology or QA fixes) throughout moduleset in one
step just before the stable (or development) release.

My 33 hellers,
Petr Kovar