Re: String additions to 'anjuta.master'
- From: John Barstow <jbowtie amathaine com>
- To: Kenneth Nielsen <k nielsen81 gmail com>
- Cc: GNOME i18n list <gnome-i18n gnome org>
- Subject: Re: String additions to 'anjuta.master'
- Date: Thu, 23 Sep 2010 00:07:56 +1200
On Wed, Sep 22, 2010 at 11:08 PM, Kenneth Nielsen <k nielsen81 gmail com> wrote:
>
> Ahh, so you don't think that it is a problem that we pretty much every
> release seem to have strings materialise within the last 14 days
> before release? As I already said, of course I don't blame John for
> fixing the problem, quite the contrary. I do however think that the
> fact that we are even in this situation, is more a matter of
> priorities of programmers, than a problem with resources.
>
I think the underlying issue is that for the last several releases
there is at least the perception that string freeze is taken less and
less seriously. String freeze breaks are stressful for translation and
documentation teams trying to reach or maintain anything over 80%
coverage, just as code freeze breaks are stressful for release
managers trying to finalize a release.
It would be helpful if someone could go through the archives/git logs
and determine if there really has been an increase in freeze break
requests. It would also be helpful to more aggressively triage such
requests; looking casually through the archives I see a fair number of
string freeze breaks allowed that could just as easily been deferred
to the next release.
Ideally the translation and documentation teams would be accorded the
same respect during UI and string freeze that release managers are
accorded during code freeze. Just as your bug fixes need to be triaged
and frequently deferred during code freeze, your string changes need
to be triaged and frequently deferred during string freeze.
We know that UI bugs are painful to ship; when we ship translation
bugs due to deadlines we feel the same pain and frustration. I think
that's why we allow freeze exceptions as often as we do; we want users
to have the best possible experience. One of the big differences is
that developers have roughly four to six months to fix the bugs in
their handful of modules (more if they are clever about branch
management); most translation teams cannot even begin work until
string freeze and then they have to cover all modules.
We're not magical elves, we are small teams just as under-resourced as
the development teams trying to master technical vocabularies in two
languages in a short timeframe. We have the same standards of
craftsmanship and the same desire to give users a great experience. So
if we say "please revert this change" or "please respect the string
freeze" - which we as a group probably need to do more often -
understand that it's the only way we can keep our workload manageable.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]