setup l10n repos for mozilla-aurora, mozilla-beta

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: joduinn, Assigned: noahm)

Tracking

Details

Attachments

(1 attachment)

In each of these two directories:

http://hg.mozilla.org/releases/l10n/mozilla-aurora
http://hg.mozilla.org/releases/l10n/mozilla-beta

...please create repos for each of the 1ocalization repos that already exist in http://hg.mozilla.org/l10n-central.


(already talked this over with Noah, filing this bug as requested to track.)

Updated

7 years ago
Assignee: server-ops → nmeyerhans

Comment 1

7 years ago
At this point, l10n-central is not in the state anymore to go to aurora as is, there are l10n changes following en-US changes that are on central but not on aurora.

Comment 2

7 years ago
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=f6aa347c426c is the first en-US landing on mozilla-central post aurora drop, so the cut-off time on l10n-central would be Tue Apr 12 13:50:55 2011 -0700.

The l10n landing is http://hg.mozilla.org/l10n-central/cs/pushloghtml?changeset=65ce881dbc3d, which landed at Tue Apr 12 15:20:34 2011 -0700.

AFAICT, https://l10n-stage-sj.mozilla.org/pushes/l10n-central/?from=1302645532.824 shows the pushes and changesets that are not guaranteed to be valid for aurora, so while setting things up, make sure to not get them, and then the localizers can cross push or transplant as needed.

Comment 3

7 years ago
would it be sufficient to clone -r 0 for each repo? that will make them "Related" but result in the pushers selecting the revs they actually want when they try to push.

Comment 4

7 years ago
That would just make this problem a problem for 80 people instead of one, that doesn't sound like a good idea.
Hardware: x86 → All
Blocks: 648066, 648290
In the interest of speed:

1) we are going to just clone tip of every repo in l10n-central. This makes it faster to script the bulk create-repos-by-cloning, and let us start l10n builds on aurora sooner.

2) I agree that it is possible for something to have landed in l10n-central after m-c --> aurora migration yesterday morning that works in m-c, but breaks on aurora. However, in triage, we feel the time window is brief enough that it is worth the risk. If one of the 15 changes in comment#2 cause a breakage on mozilla-aurora, we will back that specific change out in http://hg.mozilla.org/releases/l10n/mozilla-aurora/*.

Comment 6

7 years ago
This is not a risk, this is definite. It happened and I pointed out the changeset that does that.

Who's doing the review of what breaks and what doesn't?
can we push the last revision from before m-c --> aurora to l10n/aurora ?
(Assignee)

Comment 8

7 years ago
http://hg.mozilla.org/releases/l10n/mozilla-aurora exists now.  Unfortunately, the repos there are all based on the current tip from the corresponding l10n-central repo.  With my (lack of) hg knowledge, it's quite likely that it'll be faster for you guys to reset the state to what it should be.

When you have aurora l10n repositories in an ok state, let me know and I can clone them as the initial beta repositories, so we won't have to worry about backing out incompatible changes there.

(Sorry this took so long; Figuring out how to clear the server-side caching took longer than I anticipated.)
(Assignee)

Comment 9

7 years ago
Created attachment 525847 [details] [diff] [review]
index.tmpl diff
(Assignee)

Comment 10

7 years ago
John -- In order to get these new repos to show up under Repository Layout in the hgweb interface, somebody will need to apply the attached patch to https://hg.mozilla.org/hgcustom/hg_templates/file/a56fa3e671a4/gitweb_mozilla/index.tmpl  I don't seem to have permission to do so.
1) Noah, thanks for those cloned repos in mozilla-aurora. Thats great.
2) Gandalf/axel and myself will review the 22 changes which landed after the m-c --> aurora migration, and may back out some of those changes from mozilla-aurora if needed.
3) Once we are finished reviewing, we will ping you to start clone of all repos from mozilla-aurora to mozilla-beta. (This avoids us having to review twice!).
If you know the 'good' revisions in m-c, you could just strip everything after that on the server side.
Noah: The mozilla-aurora repos are all ready now. You can start cloning them over to mozilla-beta whenever you are ready.

Updated

7 years ago
Blocks: 649782

Comment 14

7 years ago
joduinn, will this bug also cover getting the builds running or should we file another for getting builds, and make it depend on this one?
(Assignee)

Comment 15

7 years ago
https://hg.mozilla.org/releases/l10n/mozilla-beta is now fully populated.

chofmann: the build stuff is outside the scope of this bug.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

7 years ago
Blocks: 650236
(In reply to comment #15)
> https://hg.mozilla.org/releases/l10n/mozilla-beta is now fully populated.
> 
> chofmann: the build stuff is outside the scope of this bug.

(In reply to comment #15)
> https://hg.mozilla.org/releases/l10n/mozilla-beta is now fully populated.
> 
> chofmann: the build stuff is outside the scope of this bug.

See bug#648290 for RelEng work to enable build automation on these new repos.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.