643656 - [dashboard][l10n-master] Update l10n-master to 2.0 branch work etc

Status: RESOLVED FIXED

(Localization Infrastructure and Tools :: Administration / Setup, task)

Description

[Axel Hecht [:Pike]]

Attachment: shuffle repos to build and their code names

We need to update the l10n-master for the 2.0/2.1 branch work. I'll catch tb update and calendar update with it.

CCing the SeaMonkey folk fyi.

I'll need an update on mobile for this, see bug 643622.

Here's what the patch does:

Add fx_central (no version number, as this will be the streamlined process).
Move fx40x to 2.0.
Add fennec40x. Drop fennec11x. fennec_mc stays.
Drop tb30x, keep tb31x, rename tb32x to tb33x.
Move calendar11x to calendar10x, drop the old calendar10x.

All of this will need to go along with some serious db munging to make the right db objects point to the right places.

Comment 1

[Axel Hecht [:Pike]]

Attachment: patch v 1.1, renamed fx_central tree

Sorry, attached an outdated patch, this one really creates fx_central (instead of fx5x of the previous patch).

Comment 2

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 520823 [details] [diff] [review]
patch v 1.1, renamed fx_central tree

Looks good to me, thanks!

Comment 3

[Mark Banner (:standard8)]

Comment on attachment 520823 [details] [diff] [review]
patch v 1.1, renamed fx_central tree

Looks fine to me (Note that we'll probably be very soon reshuffling tb33x as we transition to building from releases/mozilla-2.0 and releases/l10n-mozilla-2.0 as soon as the version number of mozilla-central gets bumped).

Comment 4

[Axel Hecht [:Pike]]

Does that mean that you'll stop building tb against mozilla-central at all, or that you do combo's of builds against both central and 2.0 with different version numbers?

Also, yeah, sad, I was hoping that not too many folks would need to actually use the 2.0 repos for real work, but I see the point.

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> Does that mean that you'll stop building tb against mozilla-central at all, or
> that you do combo's of builds against both central and 2.0 with different
> version numbers?

We are currently planning that we'll keep building against both central and 2.0. However there is probably going to be a period where we don't have nightlies for the central part of the builds.

> Also, yeah, sad, I was hoping that not too many folks would need to actually
> use the 2.0 repos for real work, but I see the point.

Unfortunately we need core to reflect what we're likely to ship.

Comment 6

[Robert Kaiser]

Also, we'll need the same for SeaMonkey. sea21x needs to go l10n-mozilla-2.0 and a new one (sea22x?) follow -central.

It's still a bit unclear how SeaMonkey will deal with the new structure, probably at least some part of the new "branches" needs to be shadowed, but the team needs to discuss that still.

Comment 7

[Philipp Kewisch [:Fallen][☁️📆]]

Given Thunderbird's changes to mozilla-2.0, is this something we should follow? We should defintely do this on the build side to avoid build issues, but we may be able to get around moving l10n folks to l10n-mozilla-2.0 since we won't be doing more than one release at a time.

On the one hand this probably means less pain for Pike and also the localizers that have already translated strings on l10n-central, on the other hand it may be confusing that Thunderbird 3.3 will use l10n-mozilla-2.0 while the corresponding Calendar version uses l10n-central.

I really don't mind which route to go, maybe one of you has an opinion which would be better?

Comment 8

[Axel Hecht [:Pike]]

Leak: l10n-central may be going away. For Firefox l10n it's going to loose its impact, the big chunk is likely to come on -experimental.

Anyway, for this iteration, the fixes are in, thus marking this bug FIXED.

Comment 9

[Axel Hecht [:Pike]]

tools tsunami, sorry.