Closed Bug 464640 Opened 13 years ago Closed 13 years ago

Setup a "Firefox3.1" project branch

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Assigned: bhearsum)

References

Details

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.
Component: Release Engineering: Future → Release Engineering
Depends on: 465576
For the branch name, please not toplevel -- ideally under a new toplevel group, such as http://hg.mozilla.org/releases/mozilla-1.9.1
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.
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)
(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
Blocks: 465521
Depends on: 460848
(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.
(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.
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?
Yes, l10n-mozilla-1.9.1 should be next to mozilla-1.9.1
(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
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
(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
Gecko 1.9.2a1pre / Firefox 3.2a1pre then.
IMO, "base taggig" the repositories before cloning would be a good idea.
Depends on: 465730
Depends on: 465735
Depends on: 465736
Depends on: 465744
Depends on: 450607
Depends on: 465749
pushing over to bhearsum, as he's already doing most of work here.
Assignee: nobody → bhearsum
Priority: -- → P2
(In reply to comment #14)
> pushing over to bhearsum, as he's already doing most of work here.

s/doing/delegating/ :)
Depends on: 465989
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
Assignee: bhearsum → nobody
No longer depends on: 465989
Priority: P2 → --
Depends on: 465989
Depends on: 466191
Depends on: 466222
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!
(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.
(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?
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.
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.
No longer blocks: 464164
Depends on: 464164
Depends on: 466333
Depends on: 466392
Adding two dep bugs for the mac unittest orange-ness.
Depends on: 420913, 420911
(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
Depends on: 466484
Depends on: 466713
Assignee: nobody → bhearsum
Depends on: 467379
Depends on: 467385
Depends on: 467413
No longer depends on: 420913
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.
Status: NEW → RESOLVED
Closed: 13 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.