1431273 - Move elmo/a10n related repositories to the mozilla-services github organization

Status: RESOLVED FIXED

(Localization Infrastructure and Tools :: Automation, enhancement)

Description

[Miles Crabill [:miles]]

We've discussed moving the elmo related repositories to a mozilla github organization. mozilla-services seems like an appropriate place.

Axel, I've added you to the mozilla-services organization. From there, you should be able to transfer ownership of your repositories from the Settings page.

We can create an l10n team and set up access controls from there.

Comment 1

[Miles Crabill [:miles]]

I just realized that elmo is under the mozilla organization on github already [0]. So this mostly applies to master-ball, slave-ball, and a10n.

Github makes it easy to move a repo between organizations, and sets up all relevant redirects if we want to go the mozilla-services route. I'm biased because I have admin there.

[0] https://github.com/mozilla/elmo

Axel, which github org are you taking to the dance?

Comment 2

[Axel Hecht [:Pike]]

I think I'll go for mozilla-services for the ones I migrate away from my user account.

Does it make a difference if elmo is in mozilla or mozilla-services?

(Also, [e-mail] is my personal account on bugzilla, though I only use that email on gh)

Comment 3

[Miles Crabill [:miles]]

It doesn't make a huge difference. I'm an admin on mozilla-services, which means I can help manage integrations, permissions, and that sort of thing. We can leave elmo in the mozilla organization for now.

Comment 4

[Axel Hecht [:Pike]]

I'm entertaining another option, and that's going mono-repo. Get elmo, a10n, masterball, and the docker-compose wrapper all into the same elmo repository.

I started ponding this because I have a base image (similar how socorro has one) for a10n and masterball (and elmo eventually). So from a build/ci level, that'd be nice.

But even more so, the versions of elmo and hg and other libs drift away badly between elmo, a10n, and masterball, mostly because it's a headache to do the updates.

So the idea of just having a single code base (with no git submodules), and deploying that on three services sounds quite compelling right now.

What do you think, Miles?

Comment 5

[Miles Crabill [:miles]]

It sounds good to me given your current position. Having a monorepo will allow you to maintain a more clear sense of the state of the system, and you won't have to make the same changes in multiple places to account for updating submodules. It'll only make it easier to further blur the lines between the apps, though.

The shared base image is a nice win that comes from doing this.

Comment 6

[Axel Hecht [:Pike]]

I'll probably end up mid-way, with one repo for legacy automation, and the elmo repo.

Mostly because I don't think I want to keep the legacy automation long-time, so merging its contents don't help the elmo repo.

Comment 7

[Axel Hecht [:Pike]]

https://github.com/mozilla-services/elmo-automation, this is done.

That repo contains the docker-compose setup, the master-ball code and the a10n code (I merged those repos).

It also comes with a Makefile to create the docker images for a10n and bb to be used for non-debug.

Miles, could you grant admin access to elmo-automation for me? Thanks.

Comment 8

[Miles Crabill [:miles]]

I've created an l10n team in the mozilla-services organization and given you maintainer capabilities, which will let you add other org members to the team. I've granted you admin on elmo-automation and the l10n team write access.