Decommissioning git.mozilla.org

[Jonathan Griffin]

git.mozilla.org was originally created to support the needs of the B2G
project. Since then, its use has expanded modestly to support other
projects, but still the data it contains is 95%+ related to B2G.

Given the change in organizational priorities, and in order to save on
support and operational costs, we would like to decommission git.mozilla.org
on June 27. I've notified repo owners via e-mail and have received no
objections thus far.

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1277297 to track
this work; exact logistics for this still need to be worked out. We'd like
to archive existing repos as tarballs, and beyond that, keep the process as
lightweight as possible.

Jonathan

[Hal Wine]

I'm going to float some ideas that may be controversial here first. If
there's agreement, we can move details to the bug.

On Wed, Jun 1, 2016 at 10:01 AM, Jonathan Griffin <jgri...@mozilla.com>
wrote:

> I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1277297 to track
> this work; exact logistics for this still need to be worked out. We'd like
> to archive existing repos as tarballs, and beyond that, keep the process as
> lightweight as possible.
>

I'll actually propose NOT doing the tarball archive (to lighten the process
even further). The tarballs we archived for BZR & CVS were to preserve
"last state in this version control system" (not "last state on this
host"). They are a safety net for information loss due to lost backups or
improper migration.

For all-but-one repo on git.mozilla.org, the repositories are moving to (or
already exist on) some other git server. At most we need some redirection,
IMO, but not a snapshot. (More on the exception below.)

The bulk of the 674 repos were for b2g, and were mirrors managed by
vcs-sync. There were two reasons for the repositories to be on
git.mozilla.org:
a) to be publicly accessible by partners (primarily the first partner, and
no longer required)
b) "inside the firewall" cache for releng build machinery (no longer
operational)

There were no developers committing directly to git.mozilla.org for b2g.
I.e. all the repos are already hosted elsewhere, either:
1) on github.com/mozilla-b2g (for repositories with "Mozilla contributions
to b2g")
2) on the authoritative server for that repo (e.g. android stuff
unmodified by us)

In practical terms, for community folks continuing to work on FxOS or b2g,
simply updating the manifests in github.com/mozilla-b2g/b2g-manifests to
ensure there are no references to git.mozilla.org will keep their builds
from being broken. (That change could be made ASAP to minimize any
surprises later.) If we wanted, we could also publish the vcs-sync mapping,
if folks want that detail.

The one exception is releases/gecko.git - that is/was the partner facing
repo of gecko converted from hg to git. That repo is no longer being
updated, and only exists on git.mozilla.org. I think there is developer
value to having that available as a git repository (for debugging, etc.). I
believe that is best served by making a read only upload to
github.com/mozilla-b2g, where the manifests can refer to it. Archiving that
repo (since it's end of life) is also reasonable. One tarball is much less
than 674 tarballs ;)

--Hal

[Lawrence Mandel]

Makes sense to me Hal. We should only do things that actually have value.
Storing lots of tarballs that we don't expect to ever need to be downloaded
(because we can provide links to other repos with the same data) doesn't
seem to provide a lot of value.

Lawrence

> _______________________________________________
> dev-version-control mailing list
> dev-versi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-version-control
>

[Eric Rescorla]

What resource are we conserving here? Disk space? Human time?
Hint: disk space is basically free.

-Ekr


On Wed, Jun 1, 2016 at 12:58 PM, Lawrence Mandel <lma...@mozilla.com>
wrote:

[Lawrence Mandel]

You're right. The real value that we're saving is the minimum time it takes
to run the script to create and upload the tarballs. However, even with
minimum time, I think Hal has made the point that there isn't a lot of
value in doing this.

Lawrence

[Eric Rescorla]

Hmm... I can think of a lot of times when I wished I had snapshots from
time X.
I'm having a hard time thinking of a time when I wished I hadn't taken one.

-Ekr

[Ed Morley]

On 1 June 2016 at 21:15, Eric Rescorla <e...@rtfm.com> wrote:

> Hmm... I can think of a lot of times when I wished I had snapshots from
> time X.
> I'm having a hard time thinking of a time when I wished I hadn't taken one.
>

Snapshots of a specific revision are already available from GitHub (and
even hgweb/gitweb), eg:
https://github.com/mozilla-b2g/gaia/archive/e3eccb42cc272ff9735a9145c741d5ddd797ed65.zip

So I'm not sure what additional value having our own tarballs would provide?

[Eric Rescorla]

Having something that didn't depend on github.

-Ekr

[Jonathan Griffin]

Can you expand on that concern?

To me, GitHub dependencies seem a separate issue. Mozilla already depends
pretty heavily on GitHub, and most of the repos canonically hosted there
have never been mirrored to git.mozilla.org.

That said, if you're concerned about specific repos, we could look at
tarballing just those.

Jonathan

[Eric Rescorla]

I don't have a concrete concern. It just doesn't seem like very good
practice to have important data only archived with some cloud service
provider. Same theory as offsite backups.

-Ekr


On Wed, Jun 1, 2016 at 1:55 PM, Jonathan Griffin <jgri...@mozilla.com>
wrote: