514305 - Support WinCE in release automation

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P5)

Description

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

The plan is to promote WinCE to a release platform for Firefox 3.6b1 so we need to investigate making that happen. In particular supporting updates from an interim WinCE-only release.

Comment 1

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

So the initial requirements are:
* an en-US build producing zip, cab, and complete mar
* updates from previous releases
* update verify

L10n builds and signing are not required at this point.

For building, I've tested that ReleaseBuildFactory works OK. The files go into 
 $candidates-dir/wince-arm/en-US/, $candidates-dir/update/wince-arm/en-US/
which is fine given we don't need to sign.

Updates is the tricky bit. The easiest way forward is to use a separate patcher config for WinCE, because we'll have a WinCE-only release and because it saves on a huge <exceptions> block to handle the locales difference (similarly shipped-locales). The cost is an extra builder and doing two pushsnips, not so big I don't think.

Update verify we'll ask QA to do in the short term. We'll need devices or and emulators to test the updater in-situ.

So I'm leaning to a WinCE specific extension to release_master.py for now, and it can get integrated properly if it starts to move closer to the other platforms. It'll only have build and updates for now.

Comment 2

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

Oh, and AUS needs some tweaks. At the least, to know how to map a wince-arm platform to Bouncer and AUS equivalents.

Comment 3

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

Attachment: Add en-US build support

Ben, there are several changes in here
* add a buildWinCE param to control doing a WinCE build, en-US only. Enabled for m-1.9.2 and m-c but not m-1.9.1. Later this will also add a WinCE updates step
* update the two release-firefox-mozilla-1.9.2.py for the post branch world, and add basic settings for WinCE-only 3.6a2 release (just planning to manually force a build after manual branch and tag of m-1.9.2)
* add a release mozconfig, compared to the nightly one it tweaks the update channel and enables official branding

Comment 4

[[e-mail] (:bhearsum)]

Comment on attachment 399995 [details] [diff] [review]
Add en-US build support

I know this release is pretty urgent, so I'll r+ this, but I think we can do this a little more cleanly. In my head this seems cleaner, what do you think Nick?:
* add wince to releasePlatforms
* create l10nPlatforms, leaving out wince
* control the schedulers and l10n builders based on l10nPlatforms

It might be better to rename releasePlatforms to enUSPlatforms, too.

Also, could we merge the wince-only patcher config with the main one if we dropped the 3.6a2 entry? Maybe this is something we could do after a couple of simultaneous ones, or after the final version. I think that would be better for maintainability.

Comment 5

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

Attachment: Add en-US build support, take 2

The alternative approach Ben suggested. Logically is this is the same but hopefully more readable. Obviously it assumes that enUSPlatforms is a superset of l10nPlatforms.

Also updates 1.9.2 release config to 3.6a2 & m-c config to 3.7a1. It creates a wince_update_verify that will burn until we figure out a solution there, but looping over enUSPlatforms seems more honest than using l10nPlatforms. Also fixes some tabs in the FtpPoller change source in release_master.py. The changes in repack scheduler and factory are strictly indents only, but even diff -w doesn't figure that out.

Comment 6

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

CC'ing Gozer and KaiRo as the changes here impact automation configs for their apps. (PS: Having a ':kairo' to match on would be awesome!)

Comment 7

[[e-mail] (:bhearsum)]

Comment on attachment 400660 [details] [diff] [review]
Add en-US build support, take 2

Looks good to me. I guess we'll have to removing the hardcoding of platforms in patcher-config-bump.pl pretty soon, too - eh?

Comment 8

[Robert Kaiser]

Those changes also sound nice in the way that they should make it easier to roll en-US-only x86_64 builds for releases to put up as "contributed" builds ;-)

Comment 9

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

Comment on attachment 400660 [details] [diff] [review]
Add en-US build support, take 2

http://hg.mozilla.org/build/buildbot-configs/rev/7e2ddbfa3220

Comment 10

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

Comment on attachment 400660 [details] [diff] [review]
Add en-US build support, take 2

Belay that last comment, I used rebase to handle an upstream change, so the revision changed to
http://hg.mozilla.org/build/buildbot-configs/rev/366c3f955fbc

Comment 11

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

Helps if you push the mozconfigs too
http://hg.mozilla.org/build/buildbot-configs/rev/65d5c2bb22f3

Comment 12

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

Attachment: patcher support (release updates)

Produces snippets like this for a fake 3.6b1 release:

==> aus2.test/Firefox/3.6a2/WINCE_arm-msvc/20090915194311/en-US/releasetest/partial.txt <==
version=1
type=partial
url=http://download.mozilla.org/?product=firefox-3.6b1-partial-3.6a2&os=wince&lang=en-US
hashFunction=SHA512
hashValue=d942245a52e8c1199e150c37c4599a....
size=634701
build=20090916666666
appv=3.6 Beta 1
extv=3.6b1
detailsUrl=http://www.mozilla.com/en-US/firefox/3.6b1/releasenotes/

Comment 13

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

Comment on attachment 401161 [details] [diff] [review]
patcher support (release updates)

Coop, this adds support for WinCE Firefox builds. In bouncer we use 'wince' for the OS, the build system has 'wince-arm' as the platform (so that's what we get in the directory layout in the candidates dir), and the platform identifier in the app requests is WINCE_arm-msvc.

This would be used to create UPDATE_PACKAGING_R10.

Comment 14

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

Comment on attachment 401161 [details] [diff] [review]
patcher support (release updates)

Checking in MozAUSLib.pm;
/cvsroot/mozilla/tools/patcher/MozAUSLib.pm,v  <--  MozAUSLib.pm
new revision: 1.12; previous revision: 1.11
done

Comment 15

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

Attachment: Diff between UPDATE_PACKAGING_R9 and _R10

UPDATE_PACKAGING_R10 created using the procedure in bug 420947 comment #17.

The changes between R9 and R10 are
*  tags in client.mk (to pull the right code)
*! this bug's change to MozAUSLib.pm
*  bug 496491, Bootstrap change, not part of the patcher "build"
*  bootstrap config changes, not part of the patcher "build"
*! fix to tools/update-packaging/make_incremental_updates.py from bug 507405
*  added tools/update-packaging/test_make_incremental_updates.py in bug 444050, not part of the patcher "build"

The items marked *! are the only changes that bear on release updates.

Comment 16

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

Attachment: Create gpg sigs and include in *SUMS files

Adds cab to the whitelist for gpg sigs and hashing.

Comment 17

[[e-mail] (:bhearsum)]

Comment on attachment 406160 [details] [diff] [review]
Create gpg sigs and include in *SUMS files

Landed:
Checking in checksum-files;
/mofo/release/stage/checksum-files,v  <--  checksum-files
new revision: 1.5; previous revision: 1.4
done

cvs commit: Examining .
Checking in sign-files;
/mofo/release/signing/tools/sign-files,v  <--  sign-files
new revision: 1.5; previous revision: 1.4
done

Comment 18

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

Attachment: Fix false bustage in update generation

Every time we do a 3.6 update generation run it appears to fail because it can't bump a WinCE update verify config ("failed bump_verify_configs_4"). Since we can't do verify on WinCE lets stop trying to bump, by removing the line from config from verifyConfigs. Also removes the useless builder by also keying their creation off verifyConfigs instead of enUSPlatforms.

Comment 19

[[e-mail] (:bhearsum)]

Comment on attachment 415802 [details] [diff] [review]
Fix false bustage in update generation

Slightly aside, but it might make more sense to call it verifyPlatforms or updateVerifyPlatforms now that we're keying logic off of it.

What do you think? r=me either way.

Comment 20

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

Comment on attachment 415802 [details] [diff] [review]
Fix false bustage in update generation

Yeah, that's be a good plan. Lets follow up though 'cos it'll require some co-ordination with T'Bird/SeaMonkey/Sunbird.

Also updated verifyConfigs in 2x release-firefox-mozilla-central.py on checkin:
http://hg.mozilla.org/build/buildbot-configs/rev/3bdc5139e4b5

Comment 21

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

Given the recent "deprioritizing" of WinCE, and stopping of WinCE builds in bug
543067, should this be closed as WONTFIX? If the WinCE situation changes, we can always reopen.

Of course, if there is valid work going on here unrelated to WinCE, then never mind, and carry on.

Comment 22

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

The remaining work here is to automate producing updates for WinCE. If we're not going to be producing nightly and release builds for WinCE then I agree we should close this.

Comment 23

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

(In reply to comment #22)
> The remaining work here is to automate producing updates for WinCE. If we're
> not going to be producing nightly and release builds for WinCE then I agree we
> should close this.

Nightly and release builds for WinCE stopped.

Comment 24

[Armen [:armenzg]]

In case we decide to resume any work we will have to undo the work of bug 543067.

Reopen or file a new one when WinCE becomes an active project.

Comment 25

[[e-mail] (:bhearsum)]

I'm being nit picky today -- this is a valid bug (ergo not INVALID) but definitely WONTFIX at this time.