Status

defect
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: hwine, Assigned: aki)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 unaffected)

Details

(Whiteboard: [cr 634437], NPOTB)

Attachments

(2 attachments)

The gaia-l10n repos would typically been created during the March 17 2014 merge day. That has been deferred at the request of l10n team (bug 982921 comment 3).

The original list of relevant locales is in bug 982921 comment 0 -- that may need to be updated by the time the branching is done.
bad product choice
Component: General → Gaia
Product: Firefox → Firefox OS
Version: 30 Branch → unspecified
Blocks: 984663
Whiteboard: [cr 634437]
blocking-b2g: 1.4? → 1.4+
Hal, are you the right owner for this bug?
Flags: needinfo?(hwine)
I'm not sure if this bug has the right status.

At this point, we should not fix this, but it is part of the 1.4 game at some point, probably in 4 weeks time or so. Depends a bit on what we learn about 1.5, too.
(In reply to Gregor Wagner [:gwagner] from comment #2)
> Hal, are you the right owner for this bug?

The product and l10n teams own the decision, imo. My interest is ensuring the topic is on the "to do" list for 1.4 :)

From my point of view, we need to "fix this" at least in the sense of:
 a) what are we doing for gaia-l10n w.r.t. 1.4? We need a plan.
 b) is 1.4 an exception? Or the new way of doing gaia-l10n?

All answers require some amount of implementation work from releng, and likely changes to prior release practices.

(In reply to Axel Hecht [:Pike] from comment #3)
> At this point, we should not fix this, 

Agreed, we will take no action until there is a decision. Please feel free to re-word the summary.
Flags: needinfo?(hwine)
Assignee: nobody → server-ops-webops
Component: Gaia → WebOps: Source Control
Product: Firefox OS → Infrastructure & Operations
QA Contact: nmaul
Version: unspecified → other
Assignee: server-ops-webops → nobody
Component: WebOps: Source Control → General Automation
Product: Infrastructure & Operations → Release Engineering
QA Contact: nmaul → catlee
(In reply to Hal Wine [:hwine] (use needinfo) from comment #4)
> (In reply to Gregor Wagner [:gwagner] from comment #2)
> > Hal, are you the right owner for this bug?
> 
> The product and l10n teams own the decision, imo. My interest is ensuring
> the topic is on the "to do" list for 1.4 :)
> 
> From my point of view, we need to "fix this" at least in the sense of:
>  a) what are we doing for gaia-l10n w.r.t. 1.4? We need a plan.
>  b) is 1.4 an exception? Or the new way of doing gaia-l10n?
> 
> All answers require some amount of implementation work from releng, and
> likely changes to prior release practices.
Catlee, sorry to bother you. I am not sure who should be the best person we should reach to. Are you on top of this? Thanks.
Flags: needinfo?(catlee)
(Assignee)

Comment 6

5 years ago
Axel has explicitly asked us not to branch these repos.
Assigning to him so everyone is clear that RelEng is not on the hook here.
Once he or someone else decides it's time to branch these repos, RelEng can take the appropriate action.
Assignee: nobody → l10n
Flags: needinfo?(catlee)
(Assignee)

Updated

5 years ago
Whiteboard: [cr 634437] → [cr 634437][blocked on l10n]
(In reply to Aki Sasaki [:aki] from comment #6)
> Axel has explicitly asked us not to branch these repos.
> Assigning to him so everyone is clear that RelEng is not on the hook here.
> Once he or someone else decides it's time to branch these repos, RelEng can
> take the appropriate action.

Thank you, Aki. In this case, it looks like we can remove the blocking-b2g blocking flag. Preeti, what do you think?
blocking-b2g: 1.4+ → 1.4?
Flags: needinfo?(praghunath)
We would prefer that this issue remains a blocker for 1.4. Some decision is needed, and even "no action" will be a decision impacting the 1.4 shipping manifest.

Axel: can you suggest a final date for making this decision?
Flags: needinfo?(l10n)
(In reply to Hal Wine [:hwine] (use needinfo) from comment #8)
> We would prefer that this issue remains a blocker for 1.4. Some decision is
> needed, and even "no action" will be a decision impacting the 1.4 shipping
> manifest.
> 
> Axel: can you suggest a final date for making this decision?

+ 1 to Hal(In reply to Kevin Hu [:khu] from comment #7)
> (In reply to Aki Sasaki [:aki] from comment #6)
> > Axel has explicitly asked us not to branch these repos.
> > Assigning to him so everyone is clear that RelEng is not on the hook here.
> > Once he or someone else decides it's time to branch these repos, RelEng can
> > take the appropriate action.
> 
> Thank you, Aki. In this case, it looks like we can remove the blocking-b2g
> blocking flag. Preeti, what do you think?

Kevin

Lets wait till the repos are made.
Flags: needinfo?(praghunath)
I've talked this over with Chris.

Sadly, we're not confident that we'll be able to just use a stable setup yet, and we should do a version-specific one again.

The language list needs to be extended, though. Preferably the full monty, actually.

If we really need to cut back, we should use languages_dev.json, from https://github.com/mozilla-b2g/gaia/blob/master/locales/languages_dev.json (we want bug 993378 to be uplifted to 1.4 to get more language testing going, ping Preeti)

We should make those branches live on merge day, or a day or two after, if we don't want to cram everything into that day. But not earlier, I'd say.
Flags: needinfo?(l10n)
(In reply to Axel Hecht [:Pike] from comment #10)
> The language list needs to be extended, though. Preferably the full monty,
> actually.

By "full monty" do you mean every locale for which there is a repository at http://hg.mozilla.org/gaia-l10n/ ?

> We should make those branches live on merge day, or a day or two after, if
> we don't want to cram everything into that day. But not earlier, I'd say.

We're already past the l10n merge day for 1.4 - that was back on March 17th. When do you want the releases/gaia-l10n/v1_4/<locale> repositories created?

Are we waiting for:
> (we want bug 993378 to be uplifted to 1.4 to get more language testing
> going, ping Preeti)
Flags: needinfo?(praghunath)
Flags: needinfo?(l10n)
Full monty means, yes, all locales.

The "official start of engineering" for 2.0 is next merge day. The git branches are just names for stuff.

I don't mind when we create the 1.4 repos, but we shouldn't use them for anything, and sync them to anything on the git side until the next 6week cycle.

We don't need to wait for the uplift of the locale choice, IMHO.
Flags: needinfo?(l10n)
Since git branches are just names for stuff we should create the v1.4 gaia l10n branches immediately.
(In reply to Michael Vines [:m1] [:evilmachines] from comment #13)
> Since git branches are just names for stuff we should create the v1.4 gaia
> l10n branches immediately.

They aren't "just names". Our l10n repositories of record are separate hg repositories, which are mapped onto the "just names" branches in the releases/l10n/<locale>/gaia.git repositories. :)

(In reply to Axel Hecht [:Pike] from comment #12)
> The "official start of engineering" for 2.0 is next merge day. The git
> branches are just names for stuff.
> 
> I don't mind when we create the 1.4 repos, but we shouldn't use them for
> anything, and sync them to anything on the git side until the next 6week
> cycle.

Since this is a change from recent practice, I'd like to double check. gaia l10n repo creation typically happens when the gaia.git branch is created. That was on March 17, and why :m1 is anxious for us to get back on track.

Axel, are you requesting:
 a) releng to go ahead and create the hg repos at releases/gaia-l10n/v1_4/<locale> now, and l10n will handle any needed uplift to those branches, or
 b) releng to add the postponed l10n work to the next merge day coming on April 28.

I'll be available early Thursday -- I'll ping you then to resolve this while we have some overlap time.
I'm on PTO until mid-next-week.

Re git, I wonder if we could map /gaia-l10n/ to both master and v1.4 in git, but that might be brittle.

Here's my ask:

- use /gaia-l10n/* for 2.0 and 1.4 'til April 28
- on/after April 28, use /releases/gaia-l10n/v1_4/ for 1.4, and /gaia-l10n/ for 2.0

If creating the hg repos early helps, that's fine with me, as long as we're not breaking the branch mapping until "on/after April 28". If we pre-create them, I'm happy to cross-push late landings from /gaia-l10n/ to /v1_4/ "on/after".

Given how much stuff happens on merge day, I'm fine with moving the branch out a day or two, if that helps, but I'd be just as happy to do that on the 28th.

We're not facing issues of stuff landing unexpectedly on en-US, because that's only getting changes by me anyway, thus we have a bit of flexibility.
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(praghunath)
Blocking as we need this bug resolved for locales to ship in 1.4
Whiteboard: [cr 634437][blocked on l10n] → [cr 634437][blocked on l10n], NPOTB
(In reply to Axel Hecht [:Pike] from comment #15)
> I'm on PTO until mid-next-week.

Enjoy - we have enough info now. Thanks

Basically, we're going with option (b) from:

(In reply to Hal Wine [:hwine] (use needinfo) from comment #14)
>  b) releng to add the postponed l10n work to the next merge day coming on
> April 28.

Michael - that means you won't see v1.4 branches in releases/l10n/<locale>/gaia.git repositories until after that work has completed.
linking to merge day work
Blocks: 984214
> that means you won't see v1.4 branches in releases/l10n/<locale>/gaia.git repositories until after that work has completed.

April 28th works over here, thanks.
(Assignee)

Updated

5 years ago
Assignee: l10n → aki
Whiteboard: [cr 634437][blocked on l10n], NPOTB → [cr 634437], NPOTB
(Assignee)

Comment 20

5 years ago
Axel: For 1.4, do we want the list of locales from

a) https://github.com/mozilla-b2g/gaia/blob/master/locales/languages_dev.json ,
b) https://github.com/mozilla-b2g/gaia/blob/master/locales/languages_all.json ,
c) everything in https://hg.mozilla.org/gaia-l10n , or
d) some other list (please specify)?
Flags: needinfo?(l10n)
I suggest to go for c).
Flags: needinfo?(l10n)
(Assignee)

Comment 23

5 years ago
Attachment #8412311 - Flags: review?(hwine)
(Assignee)

Comment 24

5 years ago
Posted patch gaia-1.4Splinter Review
This patch makes all the gaia l10n configs and hgrc's largely the same, except for locale name and branch lists.

We're currently missing en-GB and xh.

If the script is still better, let's do that.
Attachment #8412351 - Flags: review?(hwine)
Comment on attachment 8412351 [details] [diff] [review]
gaia-1.4

Review of attachment 8412351 [details] [diff] [review]:
-----------------------------------------------------------------

Question on the "logallrefupdates = true" addition -- that's a new setting for legacy -- any disk space impact or log rotation I need to do?

Thanks for making the files more consistent, and catching several errors where 'default' wasn't being sync'd anymore after branches added.

Two specific issues - r+ with those changes

::: releases-l10n-as-gaia/hgrc
@@ +6,5 @@
> +default = https://hg.mozilla.org/gaia-l10n/as
> +v1_4 = https://hg.mozilla.org/releases/gaia-l10n/v1_4/as
> +[mozilla.vcs-sync]
> +config-version = 1
> +remotes_to_pull = default v1_0_1 v1_2 v1_1 v1_3 v1_4

the remotes v1_0_1, v1_2, v1_3 are not defined here, and should be removed.

::: releases-l10n-be-gaia/config
@@ +6,3 @@
>  [remote "git.m.o"]
>  	url = git+ssh://git.m.o/releases/l10n/be/gaia.git
> +	fetch = +refs/*:refs/*

Why this change? It is inconsistent with other configs.
Attachment #8412351 - Flags: review?(hwine) → review+
Comment on attachment 8412311 [details] [diff] [review]
mozharness l10n (not live)

Review of attachment 8412311 [details] [diff] [review]:
-----------------------------------------------------------------

Sweet -- nice to reference languages_all on the fly like that! Saves, oh, maybe 136 config file edits.
Attachment #8412311 - Flags: review?(hwine) → review+
(Assignee)

Comment 27

5 years ago
(In reply to Hal Wine [:hwine] (use needinfo) from comment #25)
> Comment on attachment 8412351 [details] [diff] [review]
> gaia-1.4
> 
> Review of attachment 8412351 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Question on the "logallrefupdates = true" addition -- that's a new setting
> for legacy -- any disk space impact or log rotation I need to do?

For posterity: It was unclear if we wanted mirror=true or fetch = +refs/*:refs/*, and logallrefupdates=true or not, since the config files had mixed versions of those.  I figured adding logallrefupdates to the config files where it was missing was better than removing it from the ones that had it, but can easily reverse that decision.

> Thanks for making the files more consistent, and catching several errors
> where 'default' wasn't being sync'd anymore after branches added.
> 
> Two specific issues - r+ with those changes
> 
> ::: releases-l10n-as-gaia/hgrc
> @@ +6,5 @@
> > +default = https://hg.mozilla.org/gaia-l10n/as
> > +v1_4 = https://hg.mozilla.org/releases/gaia-l10n/v1_4/as
> > +[mozilla.vcs-sync]
> > +config-version = 1
> > +remotes_to_pull = default v1_0_1 v1_2 v1_1 v1_3 v1_4
> 
> the remotes v1_0_1, v1_2, v1_3 are not defined here, and should be removed.

Good catch.

> ::: releases-l10n-be-gaia/config
> @@ +6,3 @@
> >  [remote "git.m.o"]
> >  	url = git+ssh://git.m.o/releases/l10n/be/gaia.git
> > +	fetch = +refs/*:refs/*
> 
> Why this change? It is inconsistent with other configs.

Ah, I wavered on which way this line should go (mirror vs fetch), and looks like I missed this file.  Will fix.
(Assignee)

Comment 28

5 years ago
Comment on attachment 8412351 [details] [diff] [review]
gaia-1.4

Pete: this is an example of a patch we will not have to write once we switch to non-legacy l10n vcs-sync.
Attachment #8412351 - Flags: feedback?(pmoore)
Comment on attachment 8412351 [details] [diff] [review]
gaia-1.4

Review of attachment 8412351 [details] [diff] [review]:
-----------------------------------------------------------------

Ouch that looks horrific. I will make sure to get the projects ported over as quickly/smoothly as possible to the new vcs-sync. I can see writing these kind of patches are high risk, and no fun for anyone.

Thanks for highlighting this example for me.
Attachment #8412351 - Flags: feedback?(pmoore) → feedback+
(Assignee)

Updated

5 years ago
Summary: branch gaia l10n repos → branch gaia l10n repos for 1.4
(Assignee)

Comment 33

5 years ago
Pushed gaia l10n trunk to gaia l10n 1.4 in hg.
We appear to have the v1.4 branch on all gaia l10n git repos except en-GB and xh.
(Assignee)

Comment 34

5 years ago
Hal tells me en-GB and xh will get the v1.4 git branch the next cycle through.
Resolving.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.