Closed Bug 554398 Opened 14 years ago Closed 14 years ago

Tracking bug for build and release of Firefox "Lorentz" 3.6.3plugin1

Categories

(Release Engineering :: General, defect, P2)

x86
All
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: benjamin, Assigned: bhearsum)

References

()

Details

Attachments

(7 files, 3 obsolete files)

12.78 KB, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
2.83 KB, patch
bhearsum
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
5.83 KB, patch
nthomas
: review+
nthomas
: checked-in+
Details | Diff | Splinter Review
2.64 KB, text/plain
Details
702 bytes, patch
catlee
: review+
nthomas
: checked-in-
Details | Diff | Splinter Review
2.30 KB, patch
bhearsum
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
2.55 KB, patch
coop
: review+
bhearsum
: checked-in+
Details | Diff | Splinter Review
Fully localized beta of Firefox 3.6.3 from the Lorentz branch. Locales pulled from 1.9.2. We'll likely be code-ready late today or tomorrow. Issues pending:

* updates. I believe this update should be available on the 3.6 beta channel. cc'ing beltzner to confirm.
* version number. It could just be 3.6.3beta1, or something more complicated like 3.6.3betaplugins1 or something.
* expect weekly betas for a few weeks at least
There are a few outstanding issues in release automation support that need sorting out (details in bug 542142). I'll do my best to get those wrapped up as soon as possible but I can't promise we'll be ready by tomorrow.

(In reply to comment #0)
> * version number. It could just be 3.6.3beta1, or something more complicated
> like 3.6.3betaplugins1 or something.

I've done testing using 3.6.2plugin1 and 3.6.3plugin2. If you think 3.6.3beta1 is sufficiently obvious for end users then OK, but I'd prefer to have plugin in there somewhere.
Status: NEW → ASSIGNED
OS: Windows 7 → Windows 95
Priority: -- → P2
bsmedberg: 

Unclear from https://wiki.mozilla.org/Platform/2010-03-23... are you expecting to do both this Lorentz beta *and* also FF3.7a4 this week?
See Also: → 554392
(In reply to comment #0)
> Fully localized beta of Firefox 3.6.3 from the Lorentz branch. Locales pulled
> from 1.9.2.

This means all locales that have translated the strings that landed yesterday, and opted in ? Or are you asking for merging of en-US strings to the untranslated locales ?
Do you want official branding ? On the beta update channel I expect. Any other modifications from the 1.9.2 release mozconfigs ?
http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla2/linux/mozilla-1.9.2/release/mozconfig
and also macosx and win32
* we have (or will have) fallback English strings hardcoded, so that locales don't have to translate the new strings. So all the locales for 1.9.2 should work fine for the beta even if they haven't made any changes at all.

* I am expecting to do both this week. If that is overload, the lorentz beta has priority

* Yes, official branding on the beta update channel. I don't think we need to make any changes to the mozconfigs, I don't remember making any when Lorentz was cloned or any time after that.

3.6.2plugin1 is fine
Thanks for the info - wondering if you meant 3.6.3plugin1 though. IIRC we needed that to update 3.6.2 users on beta (since 3.6.2plugin1 < 3.6.2 in the version comparators eyes). 

What was the decision about 3.6.2 -> OOOP being a background or advertised update? (what we used to call this minor and major). If advertised could you provide an URL equivalent to 
  http://www.mozilla.com/en-US/firefox/3.6/details/index.html
to provide the offer content.

Axel, are you going to make changes to l10n-changesets_mozilla-1.9.2 or should we start a l10n-changesets_firefox-lorentz ? Might get a bit tricky if we have a OOOP beta and a 3.6.x release going on at the same time while using one file.
I'd like to have a separate file, can I haz that as a hg copy of the 1.9.2 one to boot with?
argh yes, 3.6.3plugin1, my typo

I believe we are planning on this being a background update for 3.6.2 beta users. beltzner, please confirm
(In reply to comment #7)
> I'd like to have a separate file, can I haz that as a hg copy of the 1.9.2 one
> to boot with?

Sure thing.
These are based on the staging release I did, and cross-checked against existing 1.9.2 configs.
Assignee: nobody → nrthomas
Attachment #434719 - Flags: review?(bhearsum)
This looks scary huge but what I'm doing is
* for linux and mac, 
 * breaking the existing firefox-lorentz -> mozilla-1.9.2 
 * creating a new firefox-lorentz dir, symlinking everything except release back to mozilla-1.9.2
 * copying mozilla-1.9.2/release/mozconfig to firefox-lorentz/release/mozconfig 
* for all platforms setting the update channel to beta for lorentz releases

* assorted syncing up where staging has gotten out of date (eg 1.9.2 beta -> release)

I've done a rsync -aL on the repo and verified
* the only difference between 1.9.2 and lorentz is the update channel for releases
* staging matches prod
Attachment #434736 - Flags: review?(bhearsum)
Comment on attachment 434736 [details] [diff] [review]
[buildbot-configs] mozconfig changes

looks good to me
Attachment #434736 - Flags: review?(bhearsum) → review+
Comment on attachment 434719 [details] [diff] [review]
[buildbot-configs] Release configs, less source revision

Need to set useBetaChannel = 0 here to avoid getting release channel snippets. Otherwise it looks good to me.
Attachment #434719 - Flags: review?(bhearsum) → review+
status: ready to start builds and get as far as the end of l10n repacks. Working on a fix so that signing copes with the versioning, and need to create a skeleton patcher config.
OS: Windows 95 → All
(In reply to comment #8)
> I believe we are planning on this being a background update for 3.6.2 beta
> users. beltzner, please confirm

In that scenario we'd need to know where the release notes are to be hosted, since that normally ends up as the Details link in the update UI. Previous examples
 http://www.mozilla.com/%locale%/firefox/3.6/releasenotes/
 http://www.mozilla.org/projects/devpreview/releasenotes/
The bumper script is fine with magicking the 'null's away; I've not set a 'from' to avoid getting a bogus past-update line. The details url is almost guaranteed to be wrong after the response to comment #16, expecting to fix the snippets later. Also tweaked the filename slightly compared to the release config (moz192-branch-lorentz-patcher2.cfg instead of moz192-branch-lorentz-update-patcher2.cfg) since the extra 'update' seemed superfluous.
Attachment #434840 - Flags: review?(bhearsum)
Comment on attachment 434840 [details] [diff] [review]
[cvs] Skeleton patcher config to make the bumper a happy camper

Looks good to me
Attachment #434840 - Flags: review?(bhearsum) → review+
Had a brief meeting with beltnzer/chofmann/dveditz regarding branding/versioning/update strategy.

* official branding
* 3.6.3plugin1 version
* we will *not* do unprompted update for existing 3.6(.3) beta users. We will *probably* do a prompted (major) update, plus make a concerted publicity effort to draw downloads. At that point we will have two streams of users, the 3.6 beta users and the lorentz beta users. Details TBA. Are there docs available for what web pages need to exist for a major update offer?
Oh, and I think we're code-complete for beta, but I have a couple verifications to do and one bug to examine before signoff.
You can look in http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/tags/production/en-US/firefox/ to see the assorted docs needed for a major/minor update.

We'll likely need some text explaining OOPP added to the standard beta testing pages (see http://www.mozilla.com/en-US/firefox/3.6.2rc/whatsnew/ and http://www.mozilla.com/en-US/firefox/3.6.2rc/releasenotes/).

The major update prompt details can be found at http://www.mozilla.com/en-US/firefox/3.6/details/ (for 3.6). I would imagine we will want to mention the OOPP there as well for 3.6.3plugin1 (will be located at http://www.mozilla.com/en-US/firefox/3.6.3plugin1/details/).
"go" for builds of Firefox 3.6.3plugin1. Changeset: http://hg.mozilla.org/projects/firefox-lorentz/rev/a66f3a1f6872
Summary: Tracking bug for build and release of Firefox "Lorentz" 3.6.3beta1 → Tracking bug for build and release of Firefox "Lorentz" 3.6.3plugin1
Comment on attachment 434840 [details] [diff] [review]
[cvs] Skeleton patcher config to make the bumper a happy camper

Checking in moz192-branch-lorentz-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz192-branch-lorentz-patcher2.cfg,v  <--  moz192-branch-lorentz-patcher2.cfg
initial revision: 1.1
done
Attachment #434840 - Flags: checked-in+
Adds source revision (a66f3a1f6872) and tweaks patcherConfig to the name I used in attachment 434840 [details] [diff] [review]. Carrying r+.

http://hg.mozilla.org/build/buildbot-configs/rev/0aaa86380155
Attachment #434719 - Attachment is obsolete: true
Attachment #435010 - Flags: review+
Attachment #435010 - Flags: checked-in+
(In reply to comment #21)
> I would imagine we
> will want to mention the OOPP there as well for 3.6.3plugin1 (will be located
> at http://www.mozilla.com/en-US/firefox/3.6.3plugin1/details/).

We will get that location by default from the release automation. We can point the updater somewhere else if you want, will just take a bit of time.
That URL is fine, I'll figure out how to edit mozilla.com as I've never done that before.
Tagging has started for build1.
bsmedberg, feel free to ping me on IRC or over email if you need help editing the pages on mozilla.com
Attached file l10n failure
(In reply to comment #5)
> * we have (or will have) fallback English strings hardcoded, so that locales
> don't have to translate the new strings. So all the locales for 1.9.2 should
> work fine for the beta even if they haven't made any changes at all.

Benjamin, Axel - We have a problem here. All but the 'is' locale stops after compare_locales, before we make and upload the repacked binaries. This is a log for the failing case.

The behavior for nightly and release repacks is different. For nightlies we merge from en-US strings for anything missing in a locale, and only warn on failure. For releases we don't merge, and stop the run immediately on errors (like missing strings). Respectively:
 http://mxr.mozilla.org/build/source/buildbotcustom/process/factory.py#2166
 http://mxr.mozilla.org/build/source/buildbotcustom/process/factory.py#2738

I can't tell if we should be enabling merging here, or if the fallback is done in the crash reporter code so we should not be halting on exit status of 1 from compare_locales.
dolske has spoken:

<nthomas>	dolske: you know about l10n for the plugin crash reporter ?
<dolske>	yeah, what about it?
<nthomas>	did you write in a special fallback to en-US strings ?
<dolske>	yes, for Lorentz.
<nthomas>	so for https://bugzilla.mozilla.org/show_bug.cgi?id=554398#c29 we should just be ignoring locales that are missing strings ?
<dolske>	nthomas: I believe so. The code will attempt to get a localized string as normal, and if that attempt fails it uses a hardcoded english string.

So we should be ignoring the compare_locales failure.
These are the nightly settings, with the intention of making compare_locales go orange but not bail on the rest of the run.
Attachment #435089 - Flags: review?(catlee)
Attachment #435089 - Flags: review?(catlee) → review+
Comment on attachment 435089 [details] [diff] [review]
[buildbotcustom] Temporary workaround

http://hg.mozilla.org/build/buildbotcustom/rev/1f74385abd77
Attachment #435089 - Flags: checked-in+ → checked-in-
(In reply to comment #13)
> (From update of attachment 434719 [details] [diff] [review])
> Need to set useBetaChannel = 0 here to avoid getting release channel snippets.
> Otherwise it looks good to me.

Dang, I forgot this. We'll still get separate snippets for the beta channel but they'll point to ftp.m.o. Probably not a big deal if we're doing a advertised (major) update to an audience we normally serve from ftp. Direct installer downloads will come still come from the mirrors.
Sob. I'll need to hack compare-locales to support "ignore", "error", "report" in filter.py, filed bug 555178. Otherwise we'll never get on reliable terms on 1.9.2 again.
Depends on: 555178
Should I be creating webpages at
http://www.mozilla.com/en-US/firefox/3.6.3plugin1rc/whatsnew/ or
http://www.mozilla.com/en-US/firefox/3.6.3plugin1/whatsnew/ or both? It's not clear to me how the "rc" ends up in that URL.
Oh, I found the mozilla.com .htaccess rules which do the "rc" redirect during the beta period.
Depends on: 555332
I moved website stuff off to bug 555332
bsmedberg declared "halt, will need respin" in email at 18:34pm today.
Depends on: 544345
Depends on: 555729
Depends on: 555800
I pushed the filter.py change from mozilla-1.9.2 to GECKO1923pre_20100325_RELBRANCH in lorentz to avoid having to use attachment 435089 [details] [diff] [review] again.
 http://hg.mozilla.org/projects/firefox-lorentz/rev/789a512409df
This assumes that we're going to do a 3.6.3plugin1 build2, and that all the changes on default after GECKO1923pre_20100325_RELBRANCH was cut are merged to the named branch.

If bsmedberg prefers doing 3.6.3plugin2 build1 then we should land all the OOPP changes, then do a push which lands and backs out the filter.py change, and use the revision where its landed to cut the new relbranch.
This is for re-using the relbranch, needs the final source revision.
Tweaks usBetaChannel to false, since I forgot to do that for build1 and it blew out the snippet uploads. Otherwise the same as attachment 436068 [details] [diff] [review].
Attachment #436068 - Attachment is obsolete: true
Undoes the damage from erroneously using useBetaChannel=0 for build1.

We're not sure yet when these 3.6.x -> lorentz updates will be needed yet, and at the next lorentz release we'll have to move to the major update prefs to allow lorentz -> lorentz update generation.
Attachment #436418 - Flags: review?(bhearsum)
Assignee: nrthomas → bhearsum
I've transplanted all the remaining fixes, and the patches for the 3.6.3 chemspill onto the GECKO1923pre_20100325_RELBRANCH. "go" for 3.6.3plugin1 build2

http://hg.mozilla.org/projects/firefox-lorentz/rev/bbf4a432c498
Attachment #436418 - Flags: review?(bhearsum) → review+
Depends on: 557195
Attachment #436416 - Attachment is obsolete: true
Attachment #437018 - Flags: review?(ccooper) → review+
Comment on attachment 437018 [details] [diff] [review]
3.6.3plugin1build2 config, with changeset

cd25d3b31e75
Attachment #437018 - Flags: checked-in+
Comment on attachment 436418 [details] [diff] [review]
[cvs] Un-beta-fy the patcher config

Checking in moz192-branch-lorentz-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz192-branch-lorentz-patcher2.cfg,v  <--  moz192-branch-lorentz-patcher2.cfg
new revision: 1.4; previous revision: 1.3
done
Attachment #436418 - Flags: checked-in+
Shipped.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: