We can't use mozilla-central directly for localization tools, we need a buffer between what lands in m-c and what is exposed to localizers, until cross-channel is ready. The idea is to start with a clone of m-c, then manually pull once or twice a week from m-c into this repository, and stop pulling if there are major issues. * It's going to be a temporary solution, but we need a stable host for it. * We need multiple people to be able to access such repository, so user repository is not an option. It's still unclear to me if Elmo would use this repository for compare-locales, or will keep using m-c. The latter would result in some really confusing stats for localizers.
One more thought: no clue about comm-central. I don't look at the repository, and as far as I can tell there's nobody checking it for l10n issues, so we might just use comm-central directly.
https://hg.mozilla.org/l10n/mozilla-central sounds like a good location. As for permissions, there's an l10n non-localizer ldap group that I'm in, but I don't know who else, that might be good for this. Also, forgot the name of that group, but a sibling repo might have the same permissions still.
(In reply to Axel Hecht [:Pike] from comment #2) > https://hg.mozilla.org/l10n/mozilla-central sounds like a good location. > > As for permissions, there's an l10n non-localizer ldap group that I'm in, > but I don't know who else, that might be good for this. Also, forgot the > name of that group, but a sibling repo might have the same permissions still. It makes sense to me. Who can help figuring out what the group is, and creating the actual repository as a clone of m-c? Also, thoughts on the comm-central part?
Assigning to Ludo to figure out the ldap-related questions, per irc. Questions: - which ldap group is that group that I'm in, l10n-related, but not scm_l10n? - who else is in that group?
Assignee: nobody → ludovic
HG groups axel is par of: cn=scm_l10n,ou=groups,dc=mozilla cn=scm_l10n_drivers,ou=groups,dc=mozilla cn=scm_l10n_infra,ou=groups,dc=mozilla cn=scm_level_1,ou=groups,dc=mozilla cn=scm_level_2,ou=groups,dc=mozilla cn=scm_level_3,ou=groups,dc=mozilla cn=vpn_l10n_merge,ou=groups,dc=mozilla you are the only member and it gives access to : l10n-merge1.private.scl3.mozilla.com and l10n-allizom1.webapp.scl3.mozilla.com Hope this helps.
Right. scm_l10n_infra is the one I'm thinking of. A good start would be for flod and theo to be part of that group, too. Should we do that as an extra bug, or is this one good enough?
This one is good enough. Added flod' moco account. Which theo ? the @moco the @mofo ?
He's pushing to hg with his firstname.lastname@example.org ldap identity. Also, I see that flod uses email@example.com as id for pushing to hg. Not sure if they're synced to a single ldap behind the scenes. See https://hg.mozilla.org/integration/autoland/rev/9ee68a7707dd and https://hg.mozilla.org/l10n-central/fr/rev/6e245f54a77b for two commits with direct push attribution, to give an upstream validation of those IDs.
Just to confirm: My @moco account doesn't have hg, only the @mozillaitalia.org one has.
Anything else you guys need from me ?
I don't think so, thanks, unassigning from Ludo (I think that's his intent, correct me if I'm wrong). This should be ready for Kendall now. To recap: create a clone of mozilla-central, with scm_l10n_infra as write permissions, at hgmo/l10n/mozilla-central. We don't expect to need one for c-c, so just one.
Assignee: ludovic → nobody
Component: General → Mercurial: hg.mozilla.org
Product: Localization Infrastructure and Tools → Developer Services
Summary: Clone of mozilla-central to use in localization tools → Create clone of mozilla-central to use in localization tools
(In reply to Francesco Lodolo [:flod] from comment #0) > We can't use mozilla-central directly for localization tools, we need a > buffer between what lands in m-c and what is exposed to localizers, until > cross-channel is ready. To be able to make a statement for c-c, can you expand on why this is the case?
What happens right now: * Strings lands in mozilla-central, I check and translate each of these landings, usually within 24 hours. There are other 2/3 localizers doing that. * If there are issues, I file bugs and get them fixed before these changes move to mozilla-aurora and are exposed to the majority of localization teams. * I'm not aware of anyone doing something similar for comm-central. To minimize the risk of pushing bad changesets to the whole localization community, we're going to create a mozilla-central clone, and update it once or twice a week if there are no pending issues. It's a temporary solution while we work on implementing cross-channel (one localization repository for all products/branches). The amount of strings landing in comm-central, the fact that nobody has been doing that kind of checks (as far as I know) and this is a temporary (6 weeks) solution, makes it reasonable to assume that we don't need such a repository for comm-central. If we create one, someone else needs to take care of checking strings and updating the clone too.
Thanks for the explanation flod, I agree it does not make sense to create a such separate repository for comm-central. I was not aware of the checks you are doing for mozilla-central and we are not doing such checks at the moment for comm-central. It is generally a good idea though!
(In reply to Axel Hecht [:Pike] from comment #12) > I don't think so, thanks, unassigning from Ludo (I think that's his intent, > correct me if I'm wrong). > > This should be ready for Kendall now. > > To recap: create a clone of mozilla-central, with scm_l10n_infra as write > permissions, at hgmo/l10n/mozilla-central. > > We don't expect to need one for c-c, so just one. Ok, should be all set! https://hg.mozilla.org/l10n/mozilla-central By default, there are only system-level hooks (push_printurls, pushlog, single_root); please let me know if you'd like any others.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Thanks, tested a commit and it works https://hg.mozilla.org/l10n/mozilla-central/pushloghtml
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.