Firefox 3 RC1 l10n freeze, localization freeze
Axel Hecht
I'd like to propose how we go about strings for Firefox 3 RC 1 and beyond.
en-US: String freeze on Tuesday, April 1st, this would be the last
string freeze we had for Firefox 3. That's already close, can we make that?
code freeze for both en-US and l10n would be one week later, April 8th.
To avoid the recent and historical issues around freezing, I propose to
actually branch l10n for Firefox 3.0.x on April 8th. That way, we can
actually stabilize l10n for Firefox 3 release, and keep it stable beyond
that for security and stability releases. To not impact other apps, we
should make that branch Firefox specific, say, FIREFOX_3_L10N_BRANCH.
From a build view, this shouldn't be a problem. client.mk supports that
since Firefox 1.5, I hope build automation won't mind. If it did, we had
a good week to fix it.
I'd like to have a flag that I can set, so that I can approve patches to
land on that branch. To be future compatible, probably already a release
specific one? firefox3.0.0, assuming the first minor update would be
firefox3.0.1?
To me this sounds like a decent compromise between making things harder
by having yet another branch, and making things simpler, by having that
branch just for Firefox.
I'd be happy to cut the actual branch myself, and to actually just
branch what we need for Firefox, too.
Axel
Mike Beltzner
> en-US: String freeze on Tuesday, April 1st, this would be the last
> string freeze we had for Firefox 3. That's already close, can we
> make that?
IMO proposing a deadline that's 4 days away (2 of them weekend days)
is asking for trouble. I would suggest Thursday, April 3rd, which
gives people just under a week, as well as (hopefully) a day of public
Beta 5 exposure to make sure that we're not missing anything.
Note that strings aren't changing frequently, and each string change
requires ui-review from me or mconnor as well as explicit approval,
and he and I are both being super conservative to protect our
localizers. In my mind I'm trying to ensure that if a locale had opted
in for Beta 5, they should need to spend no more than 3 hours between
April 4th and April 7th to get ready for RC1.
> code freeze for both en-US and l10n would be one week later, April
> 8th.
>
> To avoid the recent and historical issues around freezing, I propose
> to
> actually branch l10n for Firefox 3.0.x on April 8th. That way, we can
> actually stabilize l10n for Firefox 3 release, and keep it stable
> beyond
> that for security and stability releases. To not impact other apps, we
> should make that branch Firefox specific, say, FIREFOX_3_L10N_BRANCH.
> From a build view, this shouldn't be a problem. client.mk supports
> that
> since Firefox 1.5, I hope build automation won't mind. If it did, we
> had
> a good week to fix it.
Should we be branching /cvsroot for this, as well? While it's true
that Mozilla2 work is going on in a separate repository, we will need
a support & stability branch for the Firefox 3 product when it ships.
> I'd like to have a flag that I can set, so that I can approve
> patches to
> land on that branch. To be future compatible, probably already a
> release
> specific one? firefox3.0.0, assuming the first minor update would be
> firefox3.0.1?
If we branch, I'd just as soon continue using the existing
"approval1.9" flag, and then create a new "approval1.9.1" for any
future work on the trunk. That's the way things have worked in the
past, iirc.
cheers,
mike
> To me this sounds like a decent compromise between making things
> harder
> by having yet another branch, and making things simpler, by having
> that
> branch just for Firefox.
>
> I'd be happy to cut the actual branch myself, and to actually just
> branch what we need for Firefox, too.
>
> Axel
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Axel Hecht
> On 29-Mar-08, at 3:46 AM, Axel Hecht wrote:
>
>> en-US: String freeze on Tuesday, April 1st, this would be the last
>> string freeze we had for Firefox 3. That's already close, can we make
>> that?
>
> IMO proposing a deadline that's 4 days away (2 of them weekend days) is
> asking for trouble. I would suggest Thursday, April 3rd, which gives
> people just under a week, as well as (hopefully) a day of public Beta 5
> exposure to make sure that we're not missing anything.
Sounds good to me, too. I'd like to keep both the weekend, and the
Friday/Monday workdays, though, so that we can get both breeds of folks
on board.
I just went through the late-l10n bugs, found 7. The query I used is
http://tinyurl.com/27ad7o, based on the Firefox3 blockers query on the
last meeting notes.
The string count seems reasonable, but if possible, I'd love to reduce
the amount of landings. Like, bugs 424888 and 4242894, or 422919 and
424958 could possibly just land close to each other, instead of breaking
the l10n trees once a day. I don't feel like busting txul or ts concerns
here at all, but if you have late-l10n bugs, spend a thought on it?
> Note that strings aren't changing frequently, and each string change
> requires ui-review from me or mconnor as well as explicit approval, and
> he and I are both being super conservative to protect our localizers. In
> my mind I'm trying to ensure that if a locale had opted in for Beta 5,
> they should need to spend no more than 3 hours between April 4th and
> April 7th to get ready for RC1.
As noted above, there's nothing bad on the radar, I didn't go through
the complete blocker list though. I have faith in you guys juggling that
and standing in between the tree and strings like cerberus :-).
To detail on the l10n workload, I actually hope that our localizers
spend significant time on pounding the builds themselves and hooking up
with their community to gather feedback. And dive into the in-product
pages, as far as ready, and SUMO.
>> code freeze for both en-US and l10n would be one week later, April 8th.
>>
>> To avoid the recent and historical issues around freezing, I propose to
>> actually branch l10n for Firefox 3.0.x on April 8th. That way, we can
>> actually stabilize l10n for Firefox 3 release, and keep it stable beyond
>> that for security and stability releases. To not impact other apps, we
>> should make that branch Firefox specific, say, FIREFOX_3_L10N_BRANCH.
>> From a build view, this shouldn't be a problem. client.mk supports that
>> since Firefox 1.5, I hope build automation won't mind. If it did, we had
>> a good week to fix it.
>
> Should we be branching /cvsroot for this, as well? While it's true that
> Mozilla2 work is going on in a separate repository, we will need a
> support & stability branch for the Firefox 3 product when it ships.
>
>> I'd like to have a flag that I can set, so that I can approve patches to
>> land on that branch. To be future compatible, probably already a release
>> specific one? firefox3.0.0, assuming the first minor update would be
>> firefox3.0.1?
>
> If we branch, I'd just as soon continue using the existing "approval1.9"
> flag, and then create a new "approval1.9.1" for any future work on the
> trunk. That's the way things have worked in the past, iirc.
That'd be fine for me. I'd volunteer to run the triage for the l10n
bugs, can I get write permissions for that flag?
Thanks
Axel
Ben Hearsum
> To avoid the recent and historical issues around freezing, I propose to
> actually branch l10n for Firefox 3.0.x on April 8th. That way, we can
> actually stabilize l10n for Firefox 3 release, and keep it stable beyond
> that for security and stability releases. To not impact other apps, we
> should make that branch Firefox specific, say, FIREFOX_3_L10N_BRANCH.
> From a build view, this shouldn't be a problem. client.mk supports that
> since Firefox 1.5, I hope build automation won't mind. If it did, we had
> a good week to fix it.
Build Automation manually checks out from the l10n repo, actually, so
using LOCALES_CO_TAG isn't going to work here :(. From a Build
perspective I think this would be bad. We've steered away from making
unnecessary changes to automation close to a release and I don't think
RC1 is a good place to change that policy.
Axel Hecht
That's a regression, then, filed
https://bugzilla.mozilla.org/show_bug.cgi?id=426189. I don't think we
should end up creating tree policies about build regression bugs, really.
The argument still stands, for l10n we either need a Firefox-specific
branch, or an equivalent toolset allowing the same kind of monitoring.
If the Firefox and Gecko folks are OK with a Firefox-specific branch for
/cvsroot (and the folks developing other gecko apps), then that's not a
problem, of course.
Axel
Axel Hecht
Axel Hecht wrote:
> Hi,
>
> I'd like to propose how we go about strings for Firefox 3 RC 1 and beyond.
>
> en-US: String freeze on Tuesday, April 1st, this would be the last
> string freeze we had for Firefox 3. That's already close, can we make that?
>
> code freeze for both en-US and l10n would be one week later, April 8th.
As chatted with beltzner in the sub-thread, and discussed on today's
meeting, string freeze is going to be Thursday, April 3rd, 23:59 PDT.
That's the last string freeze for Firefox 3, if you have patches with
string changes, make sure to have the late-l10n keyword set, and ring
all bells and whistles to get the bugs triaged.
> To avoid the recent and historical issues around freezing, I propose to
> actually branch l10n for Firefox 3.0.x on April 8th. That way, we can
> actually stabilize l10n for Firefox 3 release, and keep it stable beyond
> that for security and stability releases. To not impact other apps, we
> should make that branch Firefox specific, say, FIREFOX_3_L10N_BRANCH.
> From a build view, this shouldn't be a problem. client.mk supports that
> since Firefox 1.5, I hope build automation won't mind. If it did, we had
> a good week to fix it.
>
> I'd like to have a flag that I can set, so that I can approve patches to
> land on that branch. To be future compatible, probably already a release
> specific one? firefox3.0.0, assuming the first minor update would be
> firefox3.0.1?
The branching got cut, we're going to go for two cvs modules tracking:
- Firefox subdirectories for all shipped-locales
- Firefox subdirectories for all-locales
I'll be filing a bug to get those scriptified and running, and to get
bonsai-l10n to know about them.
Axel