[announce] FF 3.1 beta 2 code freeze Monday Nov 10, 2008, 11:59 PM California Time
Seth Bindernagel
I'm tempted to just write [end of message], but wanted to make a few things clear.
Firefox 3.1 beta 2 code freeze is Monday, November 10, 2008, 11:59 PM California Time.
As always, please ping any of the l10n-drivers if you have any questions. I will be around all weekend on IRC (irc nick sethb) and on email.
These are some handy resources:
* Axel's l10n dashboard:
http://l10n.mozilla.org/dashboard/
* L10n Tinderbox:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n
* Mercurial tips and tools:
http://developer.mozilla.org/En/L10n_on_Mercurial
We would love for all locales to participate in at least one beta release before 3.1, and since beta 2 is to be the last beta, the time seems ripe right now for your locale. :) This is a great opportunity for users to try out new features in Firefox 3.1 using the browser in their language. It will likely provide more feedback on the localization itself as well, so it's a win-win situation.
Hope you are all doing well. Please let us know how we can help.
All the best,
Seth
http://blog.mozilla.com/seth
Alexandru Szasz
And what's the time limit on pushing localizations for beta 2?
Is it safe to keep working on hg head ? related to Are we going to branch
the l10n repositories, or is somebody else doing that for us ?
--
Alexandru Szasz
Axel Hecht
No, en-US hasn't landed all string changes yet. I don't have an ETA on
that yet, either. I'll keep you posted as soon as I know.
Axel
Axel Hecht
As I mentioned now in a new thread, yes, we string frozen.
As for branching, the outcome of the discussion is mostly clear,
http://groups.google.com/group/mozilla.dev.planning/msg/3ac20eec28865d40
is the final proposal from beltzner. We'll clone the l10n repos for the
stable work, and you'll continue to work on both repo trees on
'default'. The tree rules will change on the 3.1.x ones as we make
progress in the release process there. More on that as we get there.
Beta 2 should be wrapped up on Monday, 23:59 PST.
Axel
Ankitkumar Rameshchandra Patel
http://hg.mozilla.org/l10n-central/gu-IN/file/0e60bdbad963
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
--
Regards,
Ankit Patel
http://www.indianoss.org/
Robert Kaiser
> As for branching, the outcome of the discussion is mostly clear,
> http://groups.google.com/group/mozilla.dev.planning/msg/3ac20eec28865d40
> is the final proposal from beltzner. We'll clone the l10n repos for the
> stable work, and you'll continue to work on both repo trees on
> 'default'. The tree rules will change on the 3.1.x ones as we make
> progress in the release process there. More on that as we get there.
This will be a major headache for comm-central localizations, as
comm-central will stay unbranched but use the branched mozilla tree as a
base for development towards the next stable releases of Thunderbird,
SeaMonkey and probably Sunbird, based on Mozilla 1.9.1.
I have no clue what that means for locales.
Robert Kaiser
Axel Hecht
I'd think that your life would have sucked either way, as you can't have
multiple branches live in the same working copy in hg. Didn't verify
that, but hg update doesn't take a local dir as argument according to help.
No idea, you may have to clone twice, and have different L10NBASEDIRs
for mozilla-central and the rest of the comm-central family.
Axel
Robert Kaiser
> No idea, you may have to clone twice, and have different L10NBASEDIRs
> for mozilla-central and the rest of the comm-central family.
Or just use the branched L10n repos for our trunk development, which
sounds much easier.
Robert Kaiser
Ben Hearsum
Much easier for you, or for localizers? :)
Robert Kaiser
For each of us in development, localizers, build configs, tools (e.g
dashboard) and logic, having one single L10n repo for a comm-central
tree is easier - after all, comm-central will be a
mozilla-1.9.1-branch-based repo after branching, so using the branch
L10n repos is the logical thing to do.
The only problem I see is Axel watching L10n trees for non-allowed
checkins and pushlog currently not supporting him to watch only
directories that affect Firefox.
Robert Kaiser