1087335 - Standardise Release Engineering hg branch naming and usage

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, defect)

Description

[Pete Moore [:pmoore][:pete]]

There are two conventions we are using:

1) Just a default branch - whatever lands there goes to production, e.g. tools
2) A default and a production branch - changes are merged from default -> production, and production is automatically or manually updated to the tip of this branch. E.g. buildbot-configs

Considering only hg repos (not git.mozilla.org repos, nor personal github repos not yet migrated to mozilla hosting), we currently have:


Both default and production
===========================
http://hg.mozilla.org/build/autoland/
http://hg.mozilla.org/build/buildbot-configs/
http://hg.mozilla.org/build/mozharness/
http://hg.mozilla.org/build/puppet/ (although also has branch defualt)
http://hg.mozilla.org/build/relabs-puppet/


Production called production-0.8
================================
http://hg.mozilla.org/build/buildbot/
http://hg.mozilla.org/build/buildbotcustom/


Only default
============
http://hg.mozilla.org/build/braindump/
http://hg.mozilla.org/build/buildapi/
http://hg.mozilla.org/build/cloud-tools/
http://hg.mozilla.org/build/compare-locales/
http://hg.mozilla.org/build/mozpool/
http://hg.mozilla.org/build/nagios-tools/
http://hg.mozilla.org/build/partner-repacks/
http://hg.mozilla.org/build/relengapi/
http://hg.mozilla.org/build/rpm-sources/
http://hg.mozilla.org/build/serveS3/
http://hg.mozilla.org/build/slave_health/
http://hg.mozilla.org/build/slaveapi/
http://hg.mozilla.org/build/talos/
http://hg.mozilla.org/build/tools/
http://hg.mozilla.org/build/tupperware/

Some of the repos above are not deployed per se in production (tupperware, rpm-sources, ... maybe others).

I think whatever we do, we should be consistent where it makes sense to be so.

Options

1) Don't have a production tag (we don't have one for many of our repos above) - deploy from default as and when changes land (like we do for tools)

2) Introduce a production branch on all repos that get checked out in a production environment from source

3) Merge several (probably, most) repos together into one larger repo. Then we have:

  *) one repo to deploy
  *) can coordinate deployment of changes to different subprojects with a single commit
  *) can discover code/projects more easily
  *) have relative paths to libraries from one used by another
  *) define config model in one place, and use it across all the tools (e.g. no need for duplicated config across buildbot-configs, mozharness).

This may be a more contemporary approach than using multiple smaller repos with cross dependencies; I believe such a setup is used by e.g. facebook, Google. Maybe this is too much of a big change though.

Comment 1

[Massimo Gervasini [:massimo]]

> 3) Merge several (probably, most) repos together into one larger repo.

\o/ Thanks Pete!

I'm totally for option 3; this will simplify a lot of operations, make easier to land our changes and let us remove duplicate code (I'm just thinking about the retry logic in mozharness and tools)

Comment 2

[Pete Moore [:pmoore][:pete]]

In light of the engineering cost to refactor buildbot parts into a single repo, I decided it made more sense to invest the effort in migrating over to task cluster.

Regarding the other repos, this is still an open question.