407275 - Change name of Firefox 3 M10 to "Firefox 3 Beta 2" for official branding

Status: VERIFIED FIXED

(Firefox :: General, defect, P1)

Description

[Reed Loden [:reed]]

Attachment: patch - v1

+++ This bug was initially created as a clone of Bug #402605 +++

For the release of Firefox 3 M10, we want the browser's full name to be "Firefox 3 Beta 2" to enable side-by-side installs for testers, proper reporting in the press, etc, etc.

We should only land this on the RELBRANCH, not the trunk (like what we did last time).

Comment 1

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

Ummm... I think we should have this landed on trunk *before* we start automated builds. Otherwise we'd have to start the automation, stop after branching but before tagging to allow this change into the relbranch, and then figure out how to restart the automation after branch-but-before-tagging. Ugh. 

Cant we just land this on trunk, and then undo it afterwards, like we are doing for the vista icon (described in a few bugs, but can only find bug#340976 right now)?  Or am I missing something?

Comment 2

[Reed Loden [:reed]]

(In reply to comment #1)
> Cant we just land this on trunk, and then undo it afterwards, like we are doing
> for the vista icon (described in a few bugs, but can only find bug#340976 right
> now)?  Or am I missing something?

The Vista icon patch didn't affect trunk builds because it only affected those with official branding. This patch actually affects trunk builds directly. Any unofficial builds with this patch will look very strange ("Minefield 3 Beta 2"), and the Windows installer will not work normally due to the added NO_INSTDIR_FROM_REG define (it won't look for an already installed Minefield directory, etc.).

If you really think this needs to land on trunk first, it will need to land almost directly before you branch and then be reverted almost immediately after that to make sure it doesn't affect nightlies.

> Otherwise we'd have to start the automation, stop after branching but
> before tagging to allow this change into the relbranch, and then figure out how
> to restart the automation after branch-but-before-tagging. Ugh.

As we seem to want to do this a lot more lately, I think the ability to do such a thing would be a welcomed addition to our automation code.

How hard is it to do what bhearsum mentioned in bug 346214, comment #46?

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

tbh, I'm fine with either of the proposed solutions:

 - land, tag & branch, back out and clobber nightlies to ensure it doesn't affect those
 - pause automation midway through to take this change only as per bug 346214 comment #46

We should probably also either consider modifying our automation code to support this sort of use case or modifying our build flags so that we can change the name based on a build config flag (perhaps as part of --official-branding?). But those are separate bugs.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to comment #3)
> tbh, I'm fine with either of the proposed solutions:
> 
>  - land, tag & branch, back out and clobber nightlies to ensure it doesn't
> affect those

If there's no objection, let's do this.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 291999 [details] [diff] [review]
patch - v1

Requesting M10 approval. The goal here would be to land this only when we're ready to roll automatic builds, then back it out immediately once the automation has completed branching and clobber the nightlies to ensure that the changes only happen in the beta RCs.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 291999 [details] [diff] [review]
patch - v1

from IRC:

12:30 <@beltzner> bhearsum: here's a question: can the automation not take a relbranch as a
                  start point?
12:30 <@beltzner> I'm thinking, f.e., what happens if we find a problem in the RCs?
12:30 < bhearsum> it can
12:31 <@beltzner> right, so why don't we just branch, land the thing there, and then feed
                  automation that branch as the root?
12:31 < bhearsum> hmm
12:31 < bhearsum> that seems like a fine course of action

So, all things being equal, I much prefer that. I realize that this sidesteps the first step of automation (in that we have to manually do a relbranch) but it seems like less futzing about on the trunk.

Comment 7

[Reed Loden [:reed]]

Comment on attachment 291999 [details] [diff] [review]
patch - v1

I don't think beltzner meant to minus this.

Comment 8

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

(In reply to comment #4)
> (In reply to comment #3)
> > tbh, I'm fine with either of the proposed solutions:
> > 
> >  - land, tag & branch, back out and clobber nightlies to ensure it doesn't
> > affect those
> 
> If there's no objection, let's do this.

schrep just popped by. Doing this seems fastest and least error prone, so we're going this way.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 291999 [details] [diff] [review]
patch - v1

a=beltzner, please land and then back it out again as soon as the automation has picked it up

Comment 10

[Reed Loden [:reed]]

Checking in browser/base/content/browser.xul;
/cvsroot/mozilla/browser/base/content/browser.xul,v  <--  browser.xul
new revision: 1.397; previous revision: 1.396
done
Checking in other-licenses/branding/firefox/branding.nsi;
/cvsroot/mozilla/other-licenses/branding/firefox/branding.nsi,v  <--  branding.nsi
new revision: 1.10; previous revision: 1.9
done

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Ben/John: please let us know when the branching part of build automation is done, and we'll back this change out on trunk.

Comment 12

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

Quick update for the record:

At 14:03 yesterday (10th), I notified reed that branching had completed & verified ok, so he could now back out this change. He was ready & waiting, so hit return on the command in the *same* minute.

All done.

Comment 13

[Tony Chung [:tchung]]

Verified on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2

and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2