On Wed, Sep 22, 2010 at 11:08 PM, Kenneth Nielsen <k.nielse...@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. _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n