short window for taking changes for 1.5.0.3
Axel Hecht
we're opening a short window for requesting approval on changes to l10n
for the next minor update on Firefox and Thunderbird, version 1.5.0.3.
The surrounding schedule is on
http://wiki.mozilla.org/Firefox:1.5.0.3:Schedule
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 [1] blocking1.8.0.3
on the bug, and request approval1.8.0.3 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 1.5.0.2
release time stamp and the 1.5.0.3 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 1.5.0.1 one, even. My inbox tells me that
we're still working on build problems for tb 1.5.0.2, 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.
Axel
[1] 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.
Axel Hecht
<...>
>
> This is the first time that we actually get around to doing this.
This is still in our internal mail queue, but I told you, keep your
knees bent.
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
without changes.
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.
Axel
Axel Hecht
Please use the release-specific approval and blocking flags, not
approval-l10n.
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.
Axel
Kostas Papadimas
Thanks for the info Axel.
Here is the bug for approval for the Greek thunderbird translation:
https://bugzilla.mozilla.org/show_bug.cgi?id=334922
Axel Hecht
For those that got approval so far, and for those that do on Monday:
Please mark your bugs fixed after check-in. Verify that the fixes you
want in are in, there will be nightlies in
http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0-l10n
and
http://stage.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8.0-l10n/
thanks to brave rob who managed to fight down all the issues that those
builds had. Be sure to pull builds newer than 21-Apr-2006 15:10.
Tinderboxens to watch are
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8.0-l10n and
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8.0-l10n-ab-CD
(your locale code, as always).
The right branch tag to check in to is MOZILLA_1_8_0_BRANCH.
To those that have requested approvals so far, thank you very much for
the good quality of requests. Rationale was precise, patches were small
and right, feedback on questions came promptly, check-in comments were
on the spot.
To those that have not requested approvals, thanks for keeping down the
workload.
Axel
PS: Once you got approval for either the blocking or the approval flag,
don't touch it. Unless you want to revoke your request completely.