enable 64-bit windows builds on release channel

RESOLVED FIXED

Status

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: bhearsum, Assigned: rail)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

According to e-mail, this was supposed to have been done for 39.0. We want to do them in whatever the next release channel build is (39.0.1 or 40.0).
I think this is pretty straightforward. The only funny wrinkle is using {{ version }} as the first released version. This is because I don't want to forget to set it to 40.0 if we don't ship a 39.0.1.

I might be able to leave that part commented out until we ship one, not sure...
Attachment #8630053 - Flags: review?(rail)
Assignee

Comment 2

4 years ago
Comment on attachment 8630053 [details] [diff] [review]
enable win64 in release config template

sweeeet!
Attachment #8630053 - Flags: review?(rail) → review+
Posted patch only enable for 40.0 (obsolete) — Splinter Review
Per e-mail, we'll wait for 40.0:
64-bit holding to 40 should not materially cause problems from my point of
view.  Only word of caution is that all other browsers will be pushing
64-bit by default on windows 10 and this could pose a PR issue.  Risk of
this becoming a story is unknown.

Martin

On Jul 6, 2015, at 5:10 PM, Lawrence Mandel <lmandel@mozilla.com> wrote:

If 40 is enough time (as Javaum said), I think that makes more sense. We
can publish with a 39.0.1 build but if we need to do a point release I
really don't want new issues introduced because we decided to build Win64
builds. (We typically want to push a fix in this case ASAP.)

As y'all said, we can discuss in tomorrow's channel meeting. I already see
this topic on the agenda.

Lawrence
Attachment #8630053 - Attachment is obsolete: true
Attachment #8630467 - Flags: review?(rail)
Assignee

Updated

4 years ago
Attachment #8630467 - Flags: review?(rail) → review+
Reporter

Updated

4 years ago
Blocks: 1168579
We've decided not to release win64 builds in Fx40. We will wait until 41, and the improvements launching there: sandboxing and NPAPI whitelisting, and possibly some other fixes. I've spoken to the relevant folks on platform and we're fine here. Our original plan was a quiet soft-launch in 40, and to make more noise in 41 when we have added safety. We'll launch in 41.
Reporter

Updated

4 years ago
Blocks: 1188493
No longer blocks: 1168579
Comment on attachment 8630467 [details] [diff] [review]
only enable for 40.0

We'll need a new patch here with the version adjusted.
Attachment #8630467 - Attachment is obsolete: true
Reporter

Updated

4 years ago
Assignee: bhearsum → nobody
(In reply to Ben Hearsum (:bhearsum) from comment #5)
> Comment on attachment 8630467 [details] [diff] [review]
> only enable for 40.0
> 
> We'll need a new patch here with the version adjusted.

sanity check, does this bug still block https://bugzil.la/1188493 ?

anything I should be aware about prior to beta 41 release?
Flags: needinfo?(bhearsum)
(In reply to Jordan Lund (:jlund) from comment #6)
> (In reply to Ben Hearsum (:bhearsum) from comment #5)
> > Comment on attachment 8630467 [details] [diff] [review]
> > only enable for 40.0
> > 
> > We'll need a new patch here with the version adjusted.
> 
> sanity check, does this bug still block https://bugzil.la/1188493 ?
> 
> anything I should be aware about prior to beta 41 release?

It does block that bug, but there's nothing actionable here until 41 is about to uplift to release. win64 is already enabled on the Beta channel, so the action here is to make sure it's enabled on mozilla-release before 41.0 is built. Probably best to land the needed patch by the Friday before we build (September 11).
Flags: needinfo?(bhearsum)
Assignee

Updated

4 years ago
Blocks: 1196183
No longer blocks: 1188493
Assignee

Updated

4 years ago
Blocks: 1181014
Assignee

Comment 8

4 years ago
Enabling WNP in the same patch to avoid merge conflicts.
Attachment #8661407 - Flags: review?(bhearsum)
Assignee

Comment 9

4 years ago
touch mozRelease-firefox-win64.cfg.diff
Attachment #8661408 - Flags: review?(jlund)
Assignee

Comment 10

4 years ago
Comment on attachment 8661407 [details] [diff] [review]
configs-enable-win64_and_wnp.diff

302 jlund
Attachment #8661407 - Flags: review?(bhearsum) → review?(jlund)
Assignee

Updated

4 years ago
Assignee: nobody → rail
Comment on attachment 8661407 [details] [diff] [review]
configs-enable-win64_and_wnp.diff

Review of attachment 8661407 [details] [diff] [review]:
-----------------------------------------------------------------

::: mozilla/release-firefox-mozilla-release.py.template
@@ +40,2 @@
>  
> +# TODO: set to an actual version after first win64 on release channel build

is this line still valid now that we have an actual version of 42.0?

@@ +40,3 @@
>  
> +# TODO: set to an actual version after first win64 on release channel build
> +releaseConfig['HACK_first_released_version'] = {'win64': "42.0"}

at first I thought the HACK_ part was just for while it was commented out and you made a mistake but turns out that this is a valid config key: https://dxr.mozilla.org/build-central/source/tools/buildbot-helpers/release_sanity.py#253

though I must admit I don't fully grep
Attachment #8661407 - Flags: review?(jlund) → review+
Comment on attachment 8661408 [details] [diff] [review]
tools_add_mozRelease-firefox-win64.cfg.diff

this is the easiest patch I have *ever* done! my first 0 diff..

so what I gather automation populates this with data for update verify here: https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory.py#3896

but it doesn't like it the file doesn't exist so we are touching it now before hand?

eventually, it will start to look like https://dxr.mozilla.org/build-central/source/tools/release/updates/mozRelease-firefox-win32.cfg?offset=400 ?
Attachment #8661408 - Flags: review?(jlund) → review+
Assignee

Comment 13

4 years ago
(In reply to Jordan Lund (:jlund) from comment #12)
> Comment on attachment 8661408 [details] [diff] [review]
> tools_add_mozRelease-firefox-win64.cfg.diff
> 
> this is the easiest patch I have *ever* done! my first 0 diff..
> 
> so what I gather automation populates this with data for update verify here:
> https://dxr.mozilla.org/build-central/source/buildbotcustom/process/factory.
> py#3896
> 
> but it doesn't like it the file doesn't exist so we are touching it now
> before hand?
> 
> eventually, it will start to look like
> https://dxr.mozilla.org/build-central/source/tools/release/updates/
> mozRelease-firefox-win32.cfg?offset=400 ?

The main issue is that we commit, tag and push the changes generated by that tool, but there is no "hg add" to add new files.
Assignee

Comment 14

4 years ago
Comment on attachment 8661408 [details] [diff] [review]
tools_add_mozRelease-firefox-win64.cfg.diff

https://hg.mozilla.org/build/tools/rev/dcbb6564a776
Attachment #8661408 - Flags: checked-in+
In production
Assignee

Updated

4 years ago
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

Comment 17

4 years ago
Does this mean I should see win64 in https://ftp.mozilla.org/pub/firefox/releases/latest/

If so, then this needs to be reopened.
Assignee

Comment 18

4 years ago
It's in https://ftp.mozilla.org/pub/firefox/releases/42.0/

The "latest" thingy is another bug (can't find it right now) and affects all platforms.
Assignee

Comment 19

4 years ago
I asked oremj to copy the files to the "latest" directory.
You need to log in before you can comment on or make changes to this bug.