The guiding principle for this is that no change is risk-free. Thus,
when you request approval, please make your own guestimate on how
important that fix is, and compare it with the fixes we took for the
main release cycle in the previous minor releases.
What we try to do is to cut off the real problems in localizations, the
major embarrassments and the major annoyances, in that order.
As you can see one the wiki page (the second blue arrow box, "Freeze on
no-Crit approvals including L10n!, 4/24/06"), we want to be done with
the approvals by Monday, that is, we hope that we got through approving
or not them after we finish the triage meeting that day. That'd be 12pm
PST for requesting approval. Then you have one week to actually land the
fixes, and back out if something turns on fire. (This is a "hope". Poke
me if you have biggies and didn't see this in time or something similar.)
To get bugs and patches on our radar, please request  blocking22.214.171.124
on the bug, and request approval126.96.36.199 on the patches. Give a rationale
for what the change fixes, and as the approval folks for the release
can't read your language, in some cases a screenshot does good. Esp for
things like dialog sizes etc. When you request those flags, give a
summary of the change, describe how that change impacts the daily usage
of the localized product, and how visible the change is. Make sure that
the patch really focuses on your change, no mozilla translator date
changes or the like.
We hope to see a limited amount of bugs per locale, which means, a
limited amount of issues, a small changeset. How you group that is up to
you. If you have a good story for one patch, it should be one patch, if
there is a significant difference in importance, you may want to have
different patches, and even bugs.
This is the first time that we actually get around to doing this.
Please, keep your knees bent and be aware that you may be competing with
40+ locales having two products. We will be turning down approval
requests, like we do for the main repository. We don't "grade by the
curve" here. To the very least, we have no experience with this just as
you, and I expect that everybody will be suprised in the end. Join the
club to make this a pleasant suprise, and no, I don't know what it takes.
We'll be running a diff over the l10n repository between the 188.8.131.52
release time stamp and the 184.108.40.206 candidates, and any change without
approval will be subject to general back out to the previous time stamp.
So if your patch gets approved, be sure to just check in the approved
changes. Again, mind date changes by tools etc.
Now, to the obvious question, why this late? Because this release cycle
was a monster. Worse than the 220.127.116.11 one, even. My inbox tells me that
we're still working on build problems for tb 18.104.22.168, and I just talked
to Rob Helmer on the phone about getting the tinderboxens up for 1.8.0
without date tag. So, we know why we're late, and even though it's just
roughly half a week left to get requests for approvals out, it's way
better than not to. So that's what we do.
 For reference, requesting approval/blocking means to set the
corresponding flag to '?'. Both those flags are enabled for the "Mozilla
Localizations" product, which is the right product for your bugs.
dev-l10n mailing list
[hidden email] https://lists.mozilla.org/listinfo/dev-l10n
Axel Hecht wrote:
> This is the first time that we actually get around to doing this.
> Please, keep your knees bent ...
This is still in our internal mail queue, but I told you, keep your
If you land changes to your locales, I expect that you sign off
candidates again. That includes a possible respin dance.
I don't expect that we release a locale with approved check-ins without
litmus reports logged on a wiki page, something we're doing optionally
(and yay, we're thankful for any testing reports we get) for locales
The sign off requirement is likely going to be restricted to impact of
change checked in. I.e., if you only check in to mail, we won't require
the Firefox owner to sign off, but Thunderbird very much so.
This is not a definitive announcement, but just a snapshot of my mind a
almost 3am. "Educated guess" is what I'd call it.
dbaron asked in bugzilla, I just want to confirm here.
Please use the release-specific approval and blocking flags, not
The regular release team is going to do these approvals anyway, and they
felt better about having to go through just one flag. As the l10n bugs
will all be in one product, it's not terribly hard to exclude them from
a query, if the amount of requests poses a problem for the other work.
> dbaron asked in bugzilla, I just want to confirm here.
> Please use the release-specific approval and blocking flags, not
> The regular release team is going to do these approvals anyway, and they
> felt better about having to go through just one flag. As the l10n bugs
> will all be in one product, it's not terribly hard to exclude them from
> a query, if the amount of requests poses a problem for the other work.