Closed Bug 544107 Opened 14 years ago Closed 14 years ago

[Tracking bug] Set up partner repack for EU ballot builds

Categories

(Release Engineering :: Release Requests, defect, P3)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: coop, Assigned: coop)

References

Details

The EU ballot is approaching. We want to track the builds that get served for the ballot over a long-term and separately from regular Firefox builds. It seems that using the partner repack process is the best fit for generating custom ballot builds since it can give us a unique update channel across a range of localized builds and is already hooked in to release automation.

joduinn: who should we be pulling in to discuss the specifics of the update channel?
Kev: you mentioned something about *not* being able to do these ballot builds using the partner repack process. Care to elaborate on that?
I don't recall saying that, but anything's possible with my brain. My intent is to use the std process for repacks, only thing I said we were blocking on was the specific customizations we need to make. Repacks should be fine.
1) date for this has moved up. Need to handover these repacks to QA this week. 

2) this is only for windows. No need for repacks for linux, mac.

3) The only customizations that I am aware of is the update channel/blocklist channel name. I suggest "euballot" but open to other suggestions. Everything else should be same as a vanilla Firefox build.


Seth: can you give us a list of locales in the EU that we need partner repacks for?
Severity: normal → major
Things I am waiting on:

- final decision on whether a customized first-run page will be used for ballot repacks. if so, I will also need the final, localized URL for that first-run page.
- list of locales the builds need to be generated for. assuming they're the member countries, but I seem to recall Patrick mentioning there was a smaller subset. From bug 546131 I will make the assumption that we will generate repacks for the locales below. If this is an invalid assumption, please let me know as soon as possible.

bg ca cs cy da de el en-GB es-ES et fi fr fy-NL ga-IE gl hr hu is it lt lv nb-NO nl nn-NO pl pt-PT ro ru sk sl sv-SE tr

Things I have

- AUS channel. I'm just going to use release-cck-euballot and drop the normal inclusion of "mozilla" in there. If anyone has any objections, please let me know asap.
- Custom support page. We'll be setting the app.support.baseURL to http://support.mozilla.com/1/%APP%/%VERSION%/%OS%/%LOCALE%/eu in all repacks

Once I have the confirmation on the things I need, I'll fire them over to Tomcat. It'll take less than a couple hours to put everything together and get them checked into the HG repo.
(In reply to comment #4)
> Things I am waiting on:
> 
> - final decision on whether a customized first-run page will be used for ballot
> repacks. if so, I will also need the final, localized URL for that first-run
> page.
Interesting. I was under the impression we were going to use the same pre-existing, already localized first-run page for EUBallot as we already have for the vanilla builds. Who can make this call?


> - list of locales the builds need to be generated for. assuming they're the
> member countries, but I seem to recall Patrick mentioning there was a smaller
> subset. From bug 546131 I will make the assumption that we will generate
> repacks for the locales below. If this is an invalid assumption, please let me
> know as soon as possible.
> 
> bg ca cs cy da de el en-GB es-ES et fi fr fy-NL ga-IE gl hr hu is it lt lv
> nb-NO nl nn-NO pl pt-PT ro ru sk sl sv-SE tr

Note the list of locales (above) were for the browserchoice website, plus a few additions. There is a different set of locales that we provide Firefox for in EU countries. There is yet another different set of locales that Microsoft provides Windows in those same EU countries. 

If in doubt, we can alway create too many repacks and delete out any we find are not needed. 


> 
> Things I have
> 
> - AUS channel. I'm just going to use release-cck-euballot and drop the normal
> inclusion of "mozilla" in there. If anyone has any objections, please let me
> know asap.
WFM.


> - Custom support page. We'll be setting the app.support.baseURL to
> http://support.mozilla.com/1/%APP%/%VERSION%/%OS%/%LOCALE%/eu in all repacks
> 
> Once I have the confirmation on the things I need, I'll fire them over to
> Tomcat. It'll take less than a couple hours to put everything together and get
> them checked into the HG repo.
Locales for the build are:


English        en-GB
German        de
French        fr
Italian        it
Spanish        es-ES
Dutch        nl
Polish        pl
Swedish        se
Romanian    ro
Danish        da
Portuguese    pt-PT
Croatian    hr
Hungarian    hu
Greek        el
Norwegian    no
Finnish        fi
Czech        cs
Bulgarian    bg
Slovak        sk
Lithuanian    lt
Slovenian    sl
Latvian        lv
Estonian    et


In addition, we have 10 locales which are not on the ballot but which are either widely used in EEA today or are official languages in the EEA or which our community has provided, which we should also consider offering:

Catalan        ca
Frisian        Fy-NL
Basque        eu
Russian        ru
Welsh        cy
Icelandic    is
Galician    gl
Turkish        tr
Gaelic        Ga-IE
Maltese        mt


We would want to offer the updated First Run only for:
English en-GB
German de
French fr
Italian it
Spanish es-ES 



I believe the First Run URL is:

http://www.mozilla.com/%locale%/firefox/%version%/firstrun/eu/ 

Would like confirmation from JSlater.



In the Help menu (Help -> For Internet Explorer Users), this will be redirected on SUMO's side.

In the first run screen, it will be:
https://support.mozilla.com/%locale%/kb/Windows+start+page
just a quick note that the maltese locale (mt) is not available and will not be generated, and the Norwegian builds have two locales, nb-NO and nn-NO, so there are two repacks for Norway. I don't know which one should be offered, so will generate them both.
Sorry, for Norwegian we should offer nb-NO as default.  We'd like to offer nn-NO,but it is about 10% use cases and we don't have a clear mechanism to offer alternatives from the ballot screen yet.
Depends on: 546404
First cut at the repacks have been generated and are currently being QA'd by Tomcat. Information about the QA and signing process can be found in bug 546404, and information on the repack customizations used can be seen at:

https://wiki.mozilla.org/Partnering:Repacks:Firefox3:EUBallot
I'll specifically pick up this bug from the releng side to make sure the repack configs get landed, etc.
Assignee: nobody → ccooper
Priority: -- → P3
Summary: Setup partner repack for EU ballot builds → [Tracking bug] Setup partner repack for EU ballot builds
Depends on: 538453
Depends on: 544415
Depends on: 546682
Summary: [Tracking bug] Setup partner repack for EU ballot builds → [Tracking bug] Set up partner repack for EU ballot builds
We think everything is in place now for Friday's EUballot launch. To verify, I went to 

http://download.mozilla.org/?product=firefox-latest-euballot&os=win&lang=es-ES

... which downloaded a spanish build from a mirror site which I installed on my home computer, and verified it is using the EUballot specific blocklist, channel, startpage, etc as specified in https://wiki.mozilla.org/Partnering:Repacks:Firefox3:EUBallot. All was perfect.

We're keeping this bug open to track the rest of automation work we need to do for future FF3.6.x releases, and the corresponding FF3.6.x EUballot releases. However, we believe RelEng is now ready for the release later this week. 

If you see anything that is not correct, or we missed, please let us know by commenting in this bug.
Depends on: 547845
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Component: Release Engineering: Custom Builds → Release Engineering: Releases
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.