Relaxing the Thunderbird stable branch checkin rules for l10n changes?
Simon Paquet
Hi!
Right now, every change in a translation of TB2 needs a separate bug
report and a specific approval from the relevant l10n coordinator. In the
past that was Axel Hecht, now it's me as I have taken over as TB l10n
coordinator. The reason for this rule was probably that the same rule
existed for Firefox l10n so it was applied to Thunderbird as well.
The underlying reason was, as Axel told me, that in the past people did
check in broken stuff, which borked their localization.
In my opinion, this mostly applies to Firefox, but not to Thunderbird.
The reason is that Firefox has always been the first target of
localizers. With Firefox people learn how the Mozilla l10n process works,
they learn to use cvs (and now hg) and some people make mistakes on their
journey to get a working Firefox localization and even afterwards.
Once people start translating Thunderbird they've already much experience
in our way of doing things and the risk of errors is way lower.
Therefore I'm planning to loosen the checkin rules for TB l10n changes on
stable branches by removing the need for the specific approval from me
and only requiring localizers to open up bugs for their proposed changes
and informing me on those (by CC'ing me on that bug).
I'd be interested in getting feedback on that proposal.
Cya
Simon Paquet
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Axel Hecht
another cross-post as a follow-up. The discussion in .planning is taking
a direction that makes me want to write down a few general thoughts
about tree rules.
In my experience in the mozilla project, tree rules do two things, for
the most part:
- the right stuff in the first place
- make all contributors go through the pains of protecting the userbase
from a few problems
= The Right Stuff
For the right stuff, I'm talking about reviews in general, and tree
rules to make stuff pass tests, or include tests if there are no
existing ones.
For l10n, we're compromising a lot here. We have one test,
compare-locales, which is run on the build automation, but there are
tons of testable things which we don't require to be tested. For various
reasons, which all boil down to lack of resource to actually run tests.
Reviews are somewhat different, some teams do have review policies. We
have no general review policy though, as we can't really provider a
reviewer for each language. For technical pieces though, we usually do
request review, in particular for search and handler stuff.
The dropping of a general review rule compared to basically all other
bits in our ecosystem is probably the biggest compromise we do in how
we'd like to treat code going into production/products and how we
actually treat l10n.
= The Problem Protection Stuff
Here, the goal is to maintain our code in a shippable state, and to
protect the userbase of a particular binary bit from regressions. The
latter is currently not that important, as we really only have a
userbase for release bits.
So, the real point here is to have our code in a shippable state. Sadly,
in the ecosystem of malicious evil doers on the internets, we don't know
when we're going to ship a particular code base well in advance. We make
plans, but we continuously change those to address to the current risk
for users, and to balance with other releases. Things get worse by the
fact that for a volunteer with anything resembling a life, our build
cycle is rather close to 24 hours, again, without tests nor an active
nightly userbase.
Bottom line, regression hunting can take up to 4 days of "wall clock
time" from bug landed, regression found, fix landed, fix verified. IMHO,
that's longer than our planning phase, thus I'm in favour of trying to
catch regressions before they land in the tree.
Axel
PS: I don't believe in the "Firefox l10n is gonna make our localizers go
and look at their patches before check-in, do pre-check-in tests
locally, and then verify the fixes on binary bits from ftp" theory.