390789 - Mozilla2 tools tracking

Status: RESOLVED WORKSFORME

(Core Graveyard :: Tracking, defect)

Description

[(not currently active) Ted Mielczarek]

Per the Gecko 1.9 meeting on August 1st, we're not in a position to switch to the mozilla-central Hg repository for everyday work currently, due to a lack of tools equivalent to what we use now.  This is a tracking bug to try to spell out everything we need to get to that position.

1) Tinderbox builds - the plan is to use Buildbot.  bug 377929 has patches to get repeating builds going against the code in mozilla-central.  This won't get us parity with our current tinderbox builds.  We'll need nightly build generation, unit test boxes, and perftest boxes.  bug 384943 is about porting tinderbox-client features to buildbot, so that should get us the nightly build generation.

2) Bonsai integration or Bonsai replacement.  As others have noted, the Hg web interface gives some of the features of Bonsai.  It does not provide querying for checkins in a date range, which is a heavily used Bonsai feature.  I think reed was investigating adding Hg support to ViewVC, this might be a better solution.

3) LXR/MXR - we can probably use the existing LXR/MXR code, but it will need to know how to checkout a Hg repository.

4) L10n builds - In mozilla-central, client.mk had all of its CVS logic removed, and client.py now does the checkout work.  It does not currently have support for L10n builds.

5) Non-Firefox builds - The mozilla-central repo currently only has Firefox and XulRunner sources.  client.py can certainly be extended to handle other projects.  I think we need to have a solution in place here before we can go turning off CVS.

6) Release automation - I have no idea how this will impact the release automation work.

I'm sure there are other things I'm missing, but this is what I've culled from various discussions.  Not everything has its own bug filed yet obviously.

Comment 1

[Benjamin Smedberg]

I'm not sure it's even possible to have a bonsai query-by-date replacement the same way we have for CVS: the dates for HG changesets appear to be the original commit date, or in some cases the merge date. The common case (now) of querying "what landed in this timeframe which caused X regression" needs to be querying the date a changeset got pushed.

Out-of-order changesets: http://hg.mozilla.org/tamarin-central/

Comment 2

[Robert Helmer [:rhelmer]]

(In reply to comment #0)
> 1) Tinderbox builds - the plan is to use Buildbot.  bug 377929 has patches to
> get repeating builds going against the code in mozilla-central.  This won't get
> us parity with our current tinderbox builds.  We'll need nightly build
> generation, unit test boxes, and perftest boxes.  bug 384943 is about porting
> tinderbox-client features to buildbot, so that should get us the nightly build
> generation.


I don't think the idea in bug 377929 is necessary; roughly, we need to:

1) upload mozconfig to slave
2) check out client.py and run it
3) create symbols/upload them
4) create nightly MARs and upload them
5) upload packaged build

These all sound like makefile targets to me... perhaps even mozconfig settings, so there's just step 1 and 2?


> 2) Bonsai integration or Bonsai replacement.  As others have noted, the Hg web
> interface gives some of the features of Bonsai.  It does not provide querying
> for checkins in a date range, which is a heavily used Bonsai feature.  I think
> reed was investigating adding Hg support to ViewVC, this might be a better
> solution.
> 
> 3) LXR/MXR - we can probably use the existing LXR/MXR code, but it will need to
> know how to checkout a Hg repository.


I think opengrok should be reconsidered, since it replaces both and supports mercurial already (does it do bonsai-style queries though?), pretty sure we discounted it before because it didn't support CVS, but does that really matter?

I think that in any case we should leave the current bonsai alone for CVS, I'm not confident that we'd catch regressions if we make changes to bonsai, and the CVS branches will be alive for a while still.


> 4) L10n builds - In mozilla-central, client.mk had all of its CVS logic
> removed, and client.py now does the checkout work.  It does not currently have
> support for L10n builds.


Axel is working on a buildbot l10n setup, he has it working I believe.

 
> 6) Release automation - I have no idea how this will impact the release
> automation work.


Release automation is pretty encapsulated:
http://wiki.mozilla.org/Build:Release_Automation

I think that it'll affect the Tag step, Build and (l10n) Repack; we know we need to do this anyway.

Comment 3

[J. Paul Reed [:preed]]

(In reply to comment #2)
> I don't think the idea in bug 377929 is necessary; roughly, we need to:
> 
> 1) upload mozconfig to slave
> 2) check out client.py and run it
> 3) create symbols/upload them
> 4) create nightly MARs and upload them
> 5) upload packaged build
> 
> These all sound like makefile targets to me... perhaps even mozconfig settings,
> so there's just step 1 and 2?

I think there's more than that; I don't think steps 3-5 should be in the makefiles; they should be in something like bug 384943 describes. It's interesting to note that parts of it already are in the makefile, namely the complete nightly generation and that makes sense... but then there's all this weirdness around how we do partials and handle them.

Rhelmer: I thought you wanted to use Release Automation for nightlies? Some of these steps are currently handled during releases by Bootstrap. Theoretically, would this continue to be the case, or?

> > 6) Release automation - I have no idea how this will impact the release
> > automation work.
> 
> Release automation is pretty encapsulated:
> http://wiki.mozilla.org/Build:Release_Automation
> 
> I think that it'll affect the Tag step, Build and (l10n) Repack; we know we
> need to do this anyway.

Right now, most of those steps call the tinderbox client directly to do their work; hopefully, in The New World, they could just call the Python version of that harness (in which case, the encapsulation got us a lot, and it's... "easy" ;-)

Comment 4

[Robert Helmer [:rhelmer]]

(In reply to comment #3)
> (In reply to comment #2)
> > I don't think the idea in bug 377929 is necessary; roughly, we need to:
> > 
> > 1) upload mozconfig to slave
> > 2) check out client.py and run it
> > 3) create symbols/upload them
> > 4) create nightly MARs and upload them
> > 5) upload packaged build
> > 
> > These all sound like makefile targets to me... perhaps even mozconfig settings,
> > so there's just step 1 and 2?
> 
> I think there's more than that; I don't think steps 3-5 should be in the
> makefiles; they should be in something like bug 384943 describes. It's
> interesting to note that parts of it already are in the makefile, namely the
> complete nightly generation and that makes sense... but then there's all this
> weirdness around how we do partials and handle them.


Makefile targets would likely call scripts to handle the more complicated things like creating partial updates (for example); I think this is mostly academic though. I'm not particularly wedded to either idea, we can have makefiles that call scripts or scripts that call makefiles (we currently have both!).


> Rhelmer: I thought you wanted to use Release Automation for nightlies? Some of
> these steps are currently handled during releases by Bootstrap. Theoretically,
> would this continue to be the case, or?


For the 1.8 and 1.9 release branches I absolutely do... for moz2, we have some room to simplify before we get to the release stage (I hope!). Currently there are several layers of indirection in the release automation (Buildbot->Bootstrap->Tinderbox->client.mk), let's simplify if possible (why not Buildbot->client.py?)


> > > 6) Release automation - I have no idea how this will impact the release
> > > automation work.
> > 
> > Release automation is pretty encapsulated:
> > http://wiki.mozilla.org/Build:Release_Automation
> > 
> > I think that it'll affect the Tag step, Build and (l10n) Repack; we know we
> > need to do this anyway.
> 
> Right now, most of those steps call the tinderbox client directly to do their
> work; hopefully, in The New World, they could just call the Python version of
> that harness (in which case, the encapsulation got us a lot, and it's... "easy"
> ;-)


I am not convinced of the need of a "build harness" apart from the automation tool, the build system, and the scripts that the build system calls. Not saying it's wrong, more that I just don't understand the benefit and need convincing :)

This is just a small part of the puzzle, but we should definitely come to a consensus on this, so we can have a shared goal. Let's discuss outside of bugzilla (build newsgroup?).

Comment 5

[Axel Hecht [:Pike]]

AFAIK, we haven't even started to think where to put localized files in the new world.

I'll need to get an in-depth tutorial on what actually happens on the hg repository, and how dependencies work. And how permissions work.

For localizers, it'd be nice to have a way to get to just the data that they need for localizing, too. IIRC, hg doesn't provide partial pulls, though.

We should have an out-of-bug discussion on that, I guess.

Comment 6

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

We'll need try servers and build servers for Mercurial also. See bug#412347, 411538.

Comment 7

[Benjamin Smedberg]

The tryserver already works with mercurial... although there are some improvements that can be made to do repo+patch or repo+patchqueue.

Comment 8

[Mike Schroepfer]

> > 2) Bonsai integration or Bonsai replacement.  As others have noted, the Hg web
> > interface gives some of the features of Bonsai.  It does not provide querying
> > for checkins in a date range, which is a heavily used Bonsai feature.  I think
> > reed was investigating adding Hg support to ViewVC, this might be a better
> > solution.
> > 
> > 3) LXR/MXR - we can probably use the existing LXR/MXR code, but it will need to
> > know how to checkout a Hg repository.
> 
> 
> I think opengrok should be reconsidered, since it replaces both and supports
> mercurial already (does it do bonsai-style queries though?), pretty sure we
> discounted it before because it didn't support CVS, but does that really
> matter?
> 

There were also some concerns expressed when I raised this in the news groups:

http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/9e3ce02df38a3e83/64f90a8c01898a3f

But OpenGrok has gone through 2 major releases since then.  Vlad uses it locally and loves it.  Takes 3 minutes to set up so might be nice to run alongside the new MXR for mozilla-central.

Comment 9

[(not currently active) Ted Mielczarek]

I think we're clearly at good-enough in our tooling for day-to-day usage. There are some pain points, but they either have individual bugs filed or should have those bugs filed separately.