464640 - Setup a "Firefox3.1" project branch

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

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

Sometime soon after FF3.1beta2, we'll need to create a project branch for FF3.1. 

This project branch is *not* a release branch. Instead it is a project branch, which will be used for the remainder of the FF3.1betas, rcN... and later, for FF3.1.x security releases. From this project branch, release branches will be created - one for each beta, release candidate, and security release.

In advance of starting this project branch work, we should figure out the answers to the questions below.

These questions would have helped speed up creating the ActionMonkey and
TraceMonkey project branches, so we hope these questions and answers will speed
up creating the new FF3.1 project branch. 


*do you want builds?
** which o.s.? 
*** All o.s. or subset of linux, mac, win32, linux-arm
** incremental-build-on-checkin? y/n
** nightlies? y/n
** Are en-US builds enough, with no l10n? y/n
*** Note: If you specifically need l10n, this currently needs dedicated
machines, and 'significantly' longer setup. 
*** If you 'must' have l10n, do you need all locales from m-c or a subset of
locales?

* do you want unittests?
** which o.s.? 
*** All o.s. or subset of linux, mac, win32, linux-arm

* do you want talos?
** which o.s.?
*** All o.s. or subset of linux, mac, win32
** fast talos or full talos or both?
*** Note: talos requires dedicated h/w, so will need 'significantly' more time
to buy, install, configure, calibrate machines. 

*name of branch owner, who will:
** be doing periodic refreshes from m-c
** be contact person for misc setup questions
** decide when to land back project branch onto m-c
** decide when to terminate the project branch

*timeline:
** when can we start project branch (any pre-req landings pending needed before
starting project branch out from mozilla-central?)
** approx expected life span of project branch - if known?

*misc:
** need any changes to toolchain used in m-c?
** need any changes to the compile/link/repack steps used in m-c?
** preference on tinderbox waterfall name?
** preference on where to put builds on ftp.m.o?
*** used for places tinderbox-builds/my-project-branch,
nightly/latest-my-project-branch/, or nightly/2008-08-08-08-my-project-branch/
** preference on name of project branch in hg?

* any other info that might be helpful to us?


Note: RelEng will use this one tracking bug for all of the above
setups, and RelEng will create dependent bugs as needed.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

For the branch name, please not toplevel -- ideally under a new toplevel group, such as http://hg.mozilla.org/releases/mozilla-1.9.1

Comment 2

[Robert Kaiser]

I think "mozilla-1.9.1" is the right name, in whatever level it is - this is _not_ a Firefox project branch though, it is a _platform_ "release series" or project branch, for everything building on Mozilla 1.9.1, be it Firefox and XULRunner, or Thunderbird, SeaMonkey, Sunbird and others who will pull this branch in for their 1.9.1-based releases.

Comment 3

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

Proposed name of branch/clone for FF3.1 project branch:

* https://hg.mozilla.org/mozilla-1.9.1 (for mozilla-central)
* https://hg.mozilla.org/l10n-mozilla-1.9.1/* (for all the l10n repos)

Comment 4

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

(In reply to comment #0)
> *do you want builds?

yes

> ** which o.s.? 
> *** All o.s. or subset of linux, mac, win32, linux-arm

all

> ** incremental-build-on-checkin? y/n

yes

> ** nightlies? y/n

yes

> ** Are en-US builds enough, with no l10n? y/n

in the immediate term, yes, but we'll need them ASAP (for releases, and for nightly development)

> *** Note: If you specifically need l10n, this currently needs dedicated
> machines, and 'significantly' longer setup. 
> *** If you 'must' have l10n, do you need all locales from m-c or a subset of
> locales?

all locales

> * do you want unittests?
> ** which o.s.? 
> *** All o.s. or subset of linux, mac, win32, linux-arm

all

> * do you want talos?
> ** which o.s.?
> *** All o.s. or subset of linux, mac, win32
> ** fast talos or full talos or both?
> *** Note: talos requires dedicated h/w, so will need 'significantly' more time
> to buy, install, configure, calibrate machines. 

all, both

 > *name of branch owner, who will:
> ** be doing periodic refreshes from m-c
> ** be contact person for misc setup questions
> ** decide when to land back project branch onto m-c
> ** decide when to terminate the project branch

vlad, dbaron, gavin, mossop, ted, bsmedberg, anyone from #sheriffs, really

> *timeline:
> ** when can we start project branch (any pre-req landings pending needed before
> starting project branch out from mozilla-central?)

now

> ** approx expected life span of project branch - if known?

approx 1.5 years

> *misc:
> ** need any changes to toolchain used in m-c?

no, though applying the hook from bug 464974 would be nice

> ** need any changes to the compile/link/repack steps used in m-c?

no

> ** preference on tinderbox waterfall name?

Firefox3.1

> ** preference on where to put builds on ftp.m.o?

usual naming convention, so *-mozilla1.9.1

> *** used for places tinderbox-builds/my-project-branch,
> nightly/latest-my-project-branch/, or nightly/2008-08-08-08-my-project-branch/

*-mozilla1.9.1

> ** preference on name of project branch in hg?

mozilla-1.9.1

> * any other info that might be helpful to us?

not that I can think of; you can clone immediately and we'll refresh when it's time to move over

Comment 5

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

(In reply to comment #4)
> (In reply to comment #0)
> > *do you want builds?
>  > *name of branch owner, who will:
> > ** be doing periodic refreshes from m-c
> > ** be contact person for misc setup questions
> > ** decide when to land back project branch onto m-c
> > ** decide when to terminate the project branch
> 
> vlad, dbaron, gavin, mossop, ted, bsmedberg, anyone from #sheriffs, really

Branch owner is "beltzner", as single point of contact.

Comment 6

[Justin Wood (:Callek)]

(In reply to comment #3)
> Proposed name of branch/clone for FF3.1 project branch:
> 
> * https://hg.mozilla.org/mozilla-1.9.1 (for mozilla-central)

I'm with vlad and would prefer:
* https://hg.mozilla.org/releases/mozilla-1.9.1 (for mozilla-central)

As otherwise we'll likely end up with a convoluted top-level.

Comment 7

[[e-mail] (:bhearsum)]

So, any objections to:
http://hg.mozilla.org/releases/mozilla-1.9.1
http://hg.mozilla.org/l10n-mozilla-1.9.1/*

Should l10n go under /releases too?

Comment 8

[Axel Hecht [:Pike]]

Yes, l10n-mozilla-1.9.1 should be next to mozilla-1.9.1

Comment 9

[[e-mail] (:bhearsum)]

(posted to dev.planning too - please respond there)

We talked a lot about branching for Firefox 3.1 in the Platform meeting today. There was also some discussion in the tracking bug (https://bugzilla.mozilla.org/show_bug.cgi?id=464640).

To summarize:
* We will be branching ASAP.
* mozilla-central will be branched to http://hg.mozilla.org/releases/mozilla-1.9.1
* l10n will be branched to http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/ab-CD
* As soon as these repositories are cloned RelEng will start bringing up build infrastructure.

If there are no strong objections by tomorrow morning EST (approx 6am PST, 2pm UTC) I will begin filing the bugs and preparing the patches to get this done. I realize this doesn't give people much time to respond but there in the name of getting it done quickly, this will help a lot.

- Ben Hearsum

Comment 10

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

Amongst other things we'll need
* after cloning, bump the version in mozilla-central. Beltzner, what do you want there in the meantime ? (bug 465576 is making sure nightly updates work with this new version, we should be careful where snippets are published for each branch)
* set Fx3.1 nightly builds to use the Shiretoko branding to avoid confusion with Minefield from mozilla-central
* setup up new nagios monitors for stale files in .../firefox/nightly/latest-mozilla1.9.1/, and the Firefox3.1 tree. Modify existing checks for changes

Comment 11

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

(In reply to comment #10)
> Amongst other things we'll need
> * after cloning, bump the version in mozilla-central. Beltzner, what do you
> want there in the meantime ? (bug 465576 is making sure nightly updates work
> with this new version, we should be careful where snippets are published for
> each branch)

1.9.2 / Firefox 3.2

> * set Fx3.1 nightly builds to use the Shiretoko branding to avoid confusion
> with Minefield from mozilla-central

Correct, thanks

Comment 12

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

Gecko 1.9.2a1pre / Firefox 3.2a1pre then.

Comment 13

[Axel Hecht [:Pike]]

IMO, "base taggig" the repositories before cloning would be a good idea.

Comment 14

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

pushing over to bhearsum, as he's already doing most of work here.

Comment 15

[[e-mail] (:bhearsum)]

(In reply to comment #14)
> pushing over to bhearsum, as he's already doing most of work here.

s/doing/delegating/ :)

Comment 16

[[e-mail] (:bhearsum)]

Here's what we've got so far:
* All necessary repositories have been cloned.
* The majority of the work to do bring up build, test, and talos infrastructure has been done.

Tomorrow, we intend to have all infrastructure up and running. Because of bug 450607 codesighs, and leak tests on both mozilla-central and mozilla-1.9.1 will be reporting to graphs-stage.m.o instead of graphs.m.o for a period of time. Talos machines on mozilla-central and mozilla-1.9.1 will be turned off while we fix bug 450607. 

Once everything is up and running, and tests are reporting to graphs.m.o again we will be leaving the infrastructure to bake over the weekend.

We can open up mozilla-1.9.1 to post-3.1b2 development on Monday, if all goes well.

More excitingly, we can open up mozilla-central to trunk (3.2a1!) development once the following conditions are met:
* Tagging for 3.1b2 is done
* We've merged mozilla-central -> mozilla-1.9.1 to pick up everything up to and including 3.1b2
* We bump mozilla-central to version 3.2a1pre

- Ben

Comment 17

[[e-mail] (:bhearsum)]

We're about to start up mozilla-1.9.1 builds and talos. One very important thing I forgot to mentioned yesterday is that mozilla-central graphs are now labeled as 1.9.2 on graphs.mozilla.org. All future 1.9.1 data will be from mozilla-1.9.1. Please update your bookmarks!

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #17)
> We're about to start up mozilla-1.9.1 builds and talos. One very important
> thing I forgot to mentioned yesterday is that mozilla-central graphs are now
> labeled as 1.9.2 on graphs.mozilla.org. All future 1.9.1 data will be from
> mozilla-1.9.1. Please update your bookmarks!

Hmm, can we rename the currently-named "2.0" to "tip"/"trunk" or something?  We really want one continuous stream for the tip, and only to have a specific version number for release branches.

Comment 19

[[e-mail] (:bhearsum)]

(In reply to comment #18)
> (In reply to comment #17)
> > We're about to start up mozilla-1.9.1 builds and talos. One very important
> > thing I forgot to mentioned yesterday is that mozilla-central graphs are now
> > labeled as 1.9.2 on graphs.mozilla.org. All future 1.9.1 data will be from
> > mozilla-1.9.1. Please update your bookmarks!
> 
> Hmm, can we rename the currently-named "2.0" to "tip"/"trunk" or something?  We
> really want one continuous stream for the tip, and only to have a specific
> version number for release branches.

I like that idea. Alice, what do you think?

Comment 20

[alice nodelman [:alice] [:anode]]

We currently have all of moz-central lined up on reporting as '1.9.2' - but it would make it easier in future to have this just called 'tip' so that we don't have the hassle of updating the graph server db.

Unfortunately, we just went through the hassle this morning to get it all set to '1.9.2' - is this an acceptable state for now?  A switch over to calling it 'tip' requires db updates, patches for talos and build along with a downtime.

Comment 21

[[e-mail] (:bhearsum)]

Here's where we are as of end-of-day Friday:
* Build, unit test, leak test, and talos machines are all coming up.
* We expect nightly builds to be pushed into latest-mozilla-1.9.1 over the weekend. Anyone using these build should get an update offer just like mozilla-central builds.

Left to do:
* Rebrand mozilla-1.9.1 as Shiretoko (ETA: Monday)
* Pull in last set of changes from mozilla-central
* Push a GECKO_1_9_1_BASE tag to indicate branch point

Overall, this has gone really smoothly and pending approval of the necessary parties we're on track to open this up on Monday.

Comment 22

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

Adding two dep bugs for the mac unittest orange-ness.

Comment 23

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #22)
> Adding two dep bugs for the mac unittest orange-ness.

...and a third (bug 466484, with patch) in addition to bug 420911 and bug 420913

Comment 24

[[e-mail] (:bhearsum)]

Since this branch has been open for a week I'm going to declare it FIXED. There are a couple of IT bugs which we're waiting on for m-c parity, but they obviously have not blocked the opening of the branch.