485860 - change automation to also post en-US xpi, just like any other locale

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P4)

Description

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

As part of a release, we post the xpi file for every locale onto ftp.mozilla.org. However we do not post the en-US xpi file. We should post the en-US xpi, just like all the other locales.

Background: A user who downloads a non en-US locale, can download the xpi for another locale, and use LocaleSwitcher to switch between the two locales. However, this means that they need to be able to see and download the other xpi. Because we do not post the en-US xpi, users can switch to any locale *except* en-US.

The workaround for now is to have users *start* by downloading the en-US build, and then get any of the other locales that they want. However, we should fix this to make all locales equal, and just post en-US xpi like we do for all other locales.

Comment 1

[Tomer Cohen :tomer]

Fixing this will help resolve bug 479952, which is also tracked by ubuntu issue 333799 (https://bugs.launchpad.net/firefox/+bug/333799/). 

Other Linux distributions may have similar reported bugs.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

My memory claims that en-US.xpi is not like other ab-CD.xpi in some important way, but refuses to elaborate further and defers to Benjamin.

Comment 3

[Robert Kaiser]

We don't even generate an en-US.xpi currently, AFAIK.

Comment 4

[Benjamin Smedberg]

I think that it could be created fairly simply by doing

make -C browser/locales langpack-en-US

It might be possible to do this as part of the standard `make package` step, even.

Comment 5

[(no longer active)]

(In reply to comment #4)
> I think that it could be created fairly simply by doing
> 
> make -C browser/locales langpack-en-US

Yes, that seems to work fine for me too.

Comment 6

[alice nodelman [:alice] [:anode]]

Moving to Future for now.

Comment 7

[Benjamin Smedberg]

Can this be re-triaged now that bug 485935 is complete? The langpacks are already being posted for nightlies, so I think all that is necessary is that the renaming script for releases know about them and put them into the proper place.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-3.6a1pre.en-US.langpack.xpi

Comment 8

[[e-mail] (:bhearsum)]

(In reply to comment #7)
> Can this be re-triaged now that bug 485935 is complete? The langpacks are
> already being posted for nightlies, so I think all that is necessary is that
> the renaming script for releases know about them and put them into the proper
> place.
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-3.6a1pre.en-US.langpack.xpi

If we get rid of this block: http://hg.mozilla.org/build/buildbotcustom/file/cd2b80c3d9b8/l10n.py#l877

I think we'll get this for free. Before that was there the automation would try to build en-US as part of l10n release builds. Let's do that before 3.5b4 builds start and see if that works...don't think we have enough time to do anything more before that.

Comment 9

[Axel Hecht [:Pike]]

I just tried a 

make installers-en-US

and that doesn't work.

Comment 10

[[e-mail] (:bhearsum)]

Attachment: don't skip en-US when parsing a locales file

Comment 11

[[e-mail] (:bhearsum)]

(In reply to comment #9)
> I just tried a 
> 
> make installers-en-US
> 
> and that doesn't work(In reply to comment #9)
> I just tried a 
> 
> make installers-en-US
> 
> and that doesn't work.

Guess we won't land my patch before b4, in that case!

Comment 12

[[e-mail] (:bhearsum)]

Sounds like this won't be happening real soon. Maybe we'll look at doing it between 3.5b4 and the next release but for now, I'm futuring this.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

I've commented over on bug 485935 how the fix there is not release friendly.

Comment 14

[fcp]

There seems to be an English XPI file:
ftp://ftp.mozilla.org/pub/firefox/releases/3.5.6/en-US.xpi
However, I do not know the status of this file.

Comment 15

[[e-mail] (:bhearsum)]

(In reply to comment #14)
> There seems to be an English XPI file:
> ftp://ftp.mozilla.org/pub/firefox/releases/3.5.6/en-US.xpi
> However, I do not know the status of this file.

We're not supposed to be shipping that yet. Must've slipped through for 3.5.6.

Comment 16

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 18

[[e-mail] (:bhearsum)]

Going to work on this.

Comment 20

[[e-mail] (:bhearsum)]

Attachment: generate en-US.xpi in the right place

This patch works fine with and without MOZ_PKG_PRETTYNAMES=1 on linux. Haven't actually tested the upload stuff yet. Ted, assuming this tests OK, what do you think?

I also stopped the XPIs getting dropped into 'install' in the non-pretty case. I can't think of a reason why they should go there.

Comment 21

[[e-mail] (:bhearsum)]

(In reply to comment #20)
> I also stopped the XPIs getting dropped into 'install' in the non-pretty case.
> I can't think of a reason why they should go there.

Actually, I'm not going to do this. Axel told me that there could be some 3rd party tools (narro, other l10n support infra) that may depend on this. This bug doesn't need that change, so I'm going to avoid that risk.

Comment 22

[[e-mail] (:bhearsum)]

Attachment: patch w/out change to PKG_LANGPACK_PATH [Checked in: Comment 29]

I tested this on Mac, Linux, and Windows -- they all worked fine and uploaded the XPI to the right place in the context of a release factory.

Comment 23

[[e-mail] (:bhearsum)]

This patch tested fine on try, too, so AFAICT it's safe for both release and nightly paths.

Comment 24

[[e-mail] (:bhearsum)]

Drivers, this patch will enable us to start shipping an en-US.xpi langpack file (like we do for all other locales), low risk, and has been tested in the nightly build and release build scenarios on all platforms. I'd like to land this before beta7, but it can wait until later if that's not possible.

Comment 25

[[e-mail] (:bhearsum)]

(In reply to comment #24)
> Drivers, this patch will enable us to start shipping an en-US.xpi langpack file
> (like we do for all other locales), low risk, and has been tested in the
> nightly build and release build scenarios on all platforms. I'd like to land
> this before beta7, but it can wait until later if that's not possible.

(again, setting the flag this time)

Comment 26

[Benjamin Smedberg]

This feels like undue risk for beta7, let's wait until after it's out. Also, not blocking, but a+ after.

Comment 27

[[e-mail] (:bhearsum)]

Sounds good, thanks!

Comment 28

[Finn Sørensen]

Seems silly to me to delay this for 'stability' worries; 1) if the default lang pack 'basically' fails anyway, the build's failing anyway (hopefully!); 2) en-US lang pack will mainly be used by rather specific usergroups - translators and intl. supporters, who either knows how to file a bug or knows who can - and the XPI probably won't show up in related sites at all before further bugs has been filed (AMO, installers list of 'all' pages). 

So only those few on a need-to-know anyway would know where to look for the resulting file anyway - and we could often use it.

From Ben's own arguments against (via IRC), I'll grant that he is right: Those who got that far, can most probably also do their own build. And it's just one build cycle, it's on its way anyway.

Still, I'd say go and not postpone.

Comment 29

[[e-mail] (:bhearsum)]

Comment on attachment 479776 [details] [diff] [review]
patch w/out change to PKG_LANGPACK_PATH
[Checked in: Comment 29]

changeset:   55209:6a3204b41219

Comment 30

[[e-mail] (:bhearsum)]

Reading over the launchpad link, I don't think it's actually related to this. Removing it.

Comment 31

[[e-mail] (:bhearsum)]

Landed cleanly. We should start getting en-US.xpi for free starting with 4.0 Beta 8.

Comment 32

[Nick Thomas [:nthomas] (UTC+12)]

We didn't get a 4.0b7-candidates/build1/en-US.xpi, but neither is there an en-US.xpi in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/4.0b7-candidates/build1/linux-i686/xpi/. Is that what you expected ?

Comment 33

[Axel Hecht [:Pike]]

Bug 578393 regressed packager.mk, http://hg.mozilla.org/mozilla-central/rev/ab6d8c5a300a

Comment 34

[[e-mail] (:bhearsum)]

(In reply to comment #33)
> Bug 578393 regressed packager.mk,
> http://hg.mozilla.org/mozilla-central/rev/ab6d8c5a300a

Thanks Axel, I filed bug 609878 on this.