escapewindow | hg-git part iii: we're live

live

As of about 7pm PDT last Friday (October 11), gecko-dev (née beagle) and gecko-projects are live. Here's the newsgroup post. Here's gecko-dev on github and git.mozilla.org. Here's gecko-projects (with a README.md on how to use it) on github. The logs, repo_update.json files, and mapfiles are temporarily living here. The bug is here.

Both of these repositories are RelEng-supported, and have SHAs that match gecko.git.

If you use git for your gecko development, please start using these repos and make sure they work for you. AreWeFastYet and some developers have already switched over just fine. If you hit any problems, please let us know.

coming shortly

We need to move the logs, repo_update.json files, and mapfiles to a permanent location. We'd like to tie this in with mapper -- hopefully that app can grow to support most mapfile needs, but I'm not sure what those needs are currently. If you use the mapfile and have special needs around it, could you let me know?
To reduce confusion, we need to retire the earlier, experimental mozilla-central-based github repos:
- https://github.com/mozilla/releases-mozilla-central, which has no CVS history and divergent SHAs from gecko.git. Same with https://github.com/mozilla/releases-mozilla-aurora, https://github.com/mozilla/releases-mozilla-beta, and https://github.com/mozilla/releases-mozilla-release. Lots of people are using these repos, so this will take plenty of communication to migrate those users over to the new supported repos.
- At some point we need to retire https://github.com/mozilla/mozilla-central, which Ehsan has been kind enough to set up and maintain for years now.

what's next

Beagle was definitely the largest piece in RelEng's vcs-sync puzzle, but it's not the final piece.

gecko.git (hg->git): I already have configs and a test repo. Once we're confident that gecko-dev and gecko-projects are solid and solve our developers' needs, we can switch our partner-oriented repo over from the legacy system to being converted by this new production system. This switchover does not require changing any SHAs, and should hopefully be an invisible, seamless cutover.
l10n (hg->git) I already have configs and have tested this locally. The workflow I went with here involves reading the b2g/locales/all-locales and languages_dev.json files on various branches, and building the list of repos-to-sync dynamically that way. Along with the ability to create new repos on git.mozilla.org, this allows us to sync new locale repos on demand, rather than requiring manual Release Engineering + IT intervention every time.
git->git sync support. We have a large number of b2g github repos that need to be populated in git.mozilla.org. If I follow the l10n model, we would dynamically create this list from b2g-manifests, rather than require manual Release Engineering + IT intervention.
git->hg sync support. This is needed for gaia currently.
hg->hg sync support. We've had some, but limited, use of the repos mirrored on bitbucket.com

As we add support for these, we can cut over legacy processes over to the new process; stay tuned for announcements for each of these switchovers.

Also, I plan to write a few shorter blog posts about some of what went into this project.