Closed Bug 485860 Opened 15 years ago Closed 14 years ago

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

Categories

(Release Engineering :: General, defect, P4)

defect

Tracking

(blocking2.0 -)

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: joduinn, Assigned: bhearsum)

References

Details

(Keywords: student-project, Whiteboard: [l10n][automation])

Attachments

(1 file, 2 obsolete files)

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.
Blocks: 485861
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.
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.
We don't even generate an en-US.xpi currently, AFAIK.
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.
(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.
Depends on: 485935
Moving to Future for now.
Component: Release Engineering → Release Engineering: Future
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
Component: Release Engineering: Future → Release Engineering
(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.
I just tried a 

make installers-en-US

and that doesn't work.
Attachment #373127 - Flags: review?(ccooper)
(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!
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.
Blocks: 478420
Component: Release Engineering → Release Engineering: Future
Attachment #373127 - Flags: review?(ccooper) → review+
I've commented over on bug 485935 how the fix there is not release friendly.
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.
(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.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Depends on: 549982
Priority: P3 → P5
Whiteboard: waiting on 549982
Priority: P5 → P4
Whiteboard: waiting on 549982
Whiteboard: [l10n][automation]
Keywords: student-project
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Going to work on this.
Assignee: armenzg → bhearsum
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.
Attachment #373127 - Attachment is obsolete: true
Attachment #479412 - Flags: review?(ted.mielczarek)
(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.
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.
Attachment #479412 - Attachment is obsolete: true
Attachment #479776 - Flags: review?(ted.mielczarek)
Attachment #479412 - Flags: review?(ted.mielczarek)
This patch tested fine on try, too, so AFAICT it's safe for both release and nightly paths.
Attachment #479776 - Flags: review?(ted.mielczarek) → review+
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.
blocking2.0: --- → ?
(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)
This feels like undue risk for beta7, let's wait until after it's out. Also, not blocking, but a+ after.
blocking2.0: ? → -
Sounds good, thanks!
Attachment #479776 - Flags: approval2.0+
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 on attachment 479776 [details] [diff] [review]
patch w/out change to PKG_LANGPACK_PATH
[Checked in: Comment 29]

changeset:   55209:6a3204b41219
Attachment #479776 - Flags: checked-in+
Reading over the launchpad link, I don't think it's actually related to this. Removing it.
Landed cleanly. We should start getting en-US.xpi for free starting with 4.0 Beta 8.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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 ?
(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.
Depends on: 609878
Attachment #479776 - Attachment description: patch w/out change to PKG_LANGPACK_PATH → patch w/out change to PKG_LANGPACK_PATH [Checked in: Comment 29]
Blocks: 630857
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.