Calendar: Final String Freeze set for June 7th, please use l10n-miramar!
Philipp Kewisch
Following the Thunderbird Schedule, the Mozilla Calendar Project is
now officially string frozen. I have already announced preliminary
string freeze, but since then a lot has happened on the branching
landscape which caused some trouble in calendar land.
Note that the tree has changed, to match for Thunderbird. Instead of
l10n-central, for your locale to be part of Lightning 1.0b4 you must
push to the new l10n-miramar repository. Thanks to Mark for his hard
work on getting things set up.
I'm hoping to get sign-offs set up in the next few days.
Deadline
========
The final deadline for calendar l10n matches the Thunderbird deadline
of ***June 7th***. Since for Lightning there is not much difference
between the nightly and release builds, we will not be providing extra
beta builds. Translated extensions are available on a nightly basis
(sorry, no build-on-push yet!).
Dashboard
=========
This is not fully set up yet (bug 657314), but the dashboard will be
at:
https://l10n-stage-sj.mozilla.org/dashboard/?tree=calendar10x
en-US repository
================
The en-US repositories are at:
http://hg.mozilla.org/releases/comm-miramar
http://hg.mozilla.org/releases/mozilla-miramar
Nightly builds:
http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-miramar/
l10n repositories
=================
The l10n repositories are at:
http://hg.mozilla.org/releases/l10n-miramar
You want to clone yours via
hg clone ssh://hg.mozilla.org/releases/l10n-miramar/ab-CD/
Localized Nightly builds:
http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-miramar-l10n/
Jesper Kristensen
> Hello Folks,
>
> Following the Thunderbird Schedule, the Mozilla Calendar Project is
> now officially string frozen. I have already announced preliminary
> string freeze, but since then a lot has happened on the branching
> landscape which caused some trouble in calendar land.
>
> Note that the tree has changed, to match for Thunderbird. Instead of
> l10n-central, for your locale to be part of Lightning 1.0b4 you must
> push to the new l10n-miramar repository. Thanks to Mark for his hard
> work on getting things set up.
>
> I'm hoping to get sign-offs set up in the next few days.
>
> Deadline
> ========
> The final deadline for calendar l10n matches the Thunderbird deadline
> of ***June 7th***. Since for Lightning there is not much difference
> between the nightly and release builds, we will not be providing extra
> beta builds. Translated extensions are available on a nightly basis
> (sorry, no build-on-push yet!).
>
> Dashboard
> =========
> This is not fully set up yet (bug 657314), but the dashboard will be
> at:
> https://l10n-stage-sj.mozilla.org/dashboard/?tree=calendar10x
There is also another tree on the dashboard named calendar10b3pre. Is
that relevant in any way now or in the future? I don't know what it is,
but I guess it refers to the version of Lightning, which should work for
Thunderbird 3.2. Is that correct? Also, I haven't heard yet if the
developers made a decision to release Thunderbird 3.2 or not.
>
> en-US repository
> ================
>
> The en-US repositories are at:
>
> http://hg.mozilla.org/releases/comm-miramar
> http://hg.mozilla.org/releases/mozilla-miramar
>
> Nightly builds:
> http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-miramar/
>
> l10n repositories
> =================
> The l10n repositories are at:
> http://hg.mozilla.org/releases/l10n-miramar
> You want to clone yours via
> hg clone ssh://hg.mozilla.org/releases/l10n-miramar/ab-CD/
These are for Lightning 1.0b4, but are they also for future versions? If
for example future versions would come (either directly or branched)
from http://hg.mozilla.org/releases/l10n/mozilla-aurora/ then it would
be very nice to know now, so we can push our changes to both places and
avoid work for 1.0b4 being lost in 1.0b5 or whatever the next version is
called.
Axel Hecht
miramar is a one-off effort, you want to have your aurora state golden.
If you're on central, too, you can land the changesets there, and
transplant to aurora, and the cross-push to miramar. Much like I said in
the other thread to flod about central-aurora-beta.
Axel
Philipp Kewisch
<moznewsgro...@something.to.remove.jesperkristensen.dk> wrote:
> There is also another tree on the dashboard named calendar10b3pre. Is
> that relevant in any way now or in the future? I don't know what it is,
> but I guess it refers to the version of Lightning, which should work for
> Thunderbird 3.2. Is that correct? Also, I haven't heard yet if the
> developers made a decision to release Thunderbird 3.2 or not.
removed.
> These are for Lightning 1.0b4, but are they also for future versions? If
> for example future versions would come (either directly or branched)
> fromhttp://hg.mozilla.org/releases/l10n/mozilla-aurora/then it would
> be very nice to know now, so we can push our changes to both places and
> avoid work for 1.0b4 being lost in 1.0b5 or whatever the next version is
> called.
This is always a tricky question. We need to follow Thunderbird's
development process, our releases are always made to work with the
latest release of Thunderbird. This in turn means that we need to
switch branches every time we do a new release.
As Pike mentioned, if you keep comm-central up to date outside of the
string freeze dates, then you'll probably have the least amount of
work. The branches are often made directly from comm-central and I
believe it works the same way with the l10n repos. I now heard that
there will also be tb aurora nightlies, but I have yet to find out
whats going on there.
Thanks for your work!
Philipp
Axel Hecht
Just a few more comments:
The merge from l10n-central to l10n/mozilla-aurora will need to be done
by the localizers, at least for now. There's no single story on
l10n-central localization in this cycle as far as I can see from the data.
For aurora to beta, and beta to release, there's going to be organized
processes that result in well-defined states without the localizer
interacting.
That means, in the long run, the least amount of work should be required
if you just bother about aurora.
I understand that Standard8 is going for the same thing in the long run
for Thunderbird, too. Same for mobile and also seamonkey.
Axel