info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is there a clear schedule for mobile (or "mobile and l10n")?
66 views
Skip to first unread message
flod
Jul 25, 2012, 2:30:34 AM7/25/12
to
I don't usually write on dev.planning, but I guess at this point it's the only thing to do.
A sort of background discussion started on dev.110n: https://groups.google.com/d/topic/mozilla.dev.l10n/eoG0Upr2LeQ/discussion
mozilla-aurora and mozilla-beta are supposed to be string-frozen to give localizers a clear schedule and 6 weeks to complete their work (which involves not only translating the strings but also doing QA on their own builds).
http://mozilla.github.com/process-releases/draft/development_specifics/
****
No en-US string changes will be allowed on mozilla-aurora. The mozilla-central → mozilla-aurora merge date will happen on schedule so the string freeze should not come as a surprise.
For locales that don't track mozilla-central, their work is done in l10n-aurora, which tracks mozilla-aurora. This means most locales have 6 weeks to complete their localizations.
****
From this point of view Mobile has been a total pain. Not only they keep breaking strings on mozilla-aurora, but they started doing it on mozilla-beta too.
Last example: http://hg.mozilla.org/releases/mozilla-beta/rev/d6c8b81545a8
As a localizer (and a volunteer), I'm honestly loosing my patience with Mobile: there's no clear schedule, it's the only project that keeps breaking rules that worked fine since we switched to rapid release cycle, even QA doesn't know how to deal with this mess since they open bugs for strings that "[ignore] was the right thing to do" [1].
Seriously, can we get a clear statement of what Mobile plans to do? If you're interested in keeping Firefox Mobile translated in as many languages as possible (or at least in Italian), I suggest you make up your mind at some point.
Sorry if this message sounds rough, but you must understand that localizers are volunteers with a limited amount of spare time and rules are in place to help them do their work in the easiest way. If l10n(i18n is central to the Mozilla project, we can't keep ignoring or bending these rules.
Francesco
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=775048
A sort of background discussion started on dev.110n: https://groups.google.com/d/topic/mozilla.dev.l10n/eoG0Upr2LeQ/discussion
mozilla-aurora and mozilla-beta are supposed to be string-frozen to give localizers a clear schedule and 6 weeks to complete their work (which involves not only translating the strings but also doing QA on their own builds).
http://mozilla.github.com/process-releases/draft/development_specifics/
****
No en-US string changes will be allowed on mozilla-aurora. The mozilla-central → mozilla-aurora merge date will happen on schedule so the string freeze should not come as a surprise.
For locales that don't track mozilla-central, their work is done in l10n-aurora, which tracks mozilla-aurora. This means most locales have 6 weeks to complete their localizations.
****
From this point of view Mobile has been a total pain. Not only they keep breaking strings on mozilla-aurora, but they started doing it on mozilla-beta too.
Last example: http://hg.mozilla.org/releases/mozilla-beta/rev/d6c8b81545a8
As a localizer (and a volunteer), I'm honestly loosing my patience with Mobile: there's no clear schedule, it's the only project that keeps breaking rules that worked fine since we switched to rapid release cycle, even QA doesn't know how to deal with this mess since they open bugs for strings that "[ignore] was the right thing to do" [1].
Seriously, can we get a clear statement of what Mobile plans to do? If you're interested in keeping Firefox Mobile translated in as many languages as possible (or at least in Italian), I suggest you make up your mind at some point.
Sorry if this message sounds rough, but you must understand that localizers are volunteers with a limited amount of spare time and rules are in place to help them do their work in the easiest way. If l10n(i18n is central to the Mozilla project, we can't keep ignoring or bending these rules.
Francesco
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=775048
Aki Sasaki
Jul 25, 2012, 3:45:34 AM7/25/12
to
On 7/24/12 11:30 PM, flod wrote:
> From this point of view Mobile has been a total pain. Not only they keep breaking strings on mozilla-aurora, but they started doing it on mozilla-beta too.
Mobile has been off-train since the Android Native project landed last
> From this point of view Mobile has been a total pain. Not only they keep breaking strings on mozilla-aurora, but they started doing it on mozilla-beta too.
fall, and only just got back on the train with 14.0.1. I was hoping
that things would significantly calm down afterwards, but that hasn't
(yet) proven to be true.
I very strongly agree that train-jumping should be an emergency measure,
not a regular occurrence, as it causes disruptions throughout the entire
community, not just l10n.
I think the above statement should hold true for both desktop and
mobile. Especially while we're trying to get b2g ramped up.
fi...@akerbeltz.org
Jul 25, 2012, 5:42:50 AM7/25/12
to
Hwell, my locale has been stumped at a much more basic level of "not being big enough to get shipped with the install file".
I'm keeping it up to date without (much urgency) in the hope someone will fix this at some point... but I can see how the above is rather annoying.
I'm keeping it up to date without (much urgency) in the hope someone will fix this at some point... but I can see how the above is rather annoying.
Matt Brubeck
Jul 25, 2012, 2:35:42 PM7/25/12
to flod
On 07/24/2012 11:30 PM, flod wrote:
> Seriously, can we get a clear statement of what Mobile plans to do? If you're interested in keeping Firefox Mobile translated in as many languages as possible (or at least in Italian), I suggest you make up your mind at some point.
In today's mobile meeting it was mentioned that string freeze for Fennec
> Seriously, can we get a clear statement of what Mobile plans to do? If you're interested in keeping Firefox Mobile translated in as many languages as possible (or at least in Italian), I suggest you make up your mind at some point.
15 will happen next week:
https://wiki.mozilla.org/Mobile/Notes/25-Jul-2012#Major_Topics_for_This_Week
This was news to me, and I don't know whether or where it's been
announced before.
We've been making some unusual trade-offs in Firefox 14, 15, and to a
lesser extent 16, so that we can upgrade users away from the outdated
XUL Fennec UI as soon as possible, while also providing a compelling
feature set for the new UI. Product management decided this meant
pushing new feature work into these releases long after the point when
we normally would. They know that decreased localization quality is one
of the trade-offs; for example see Alex's bug 775029 comment 8.
I can't speak for product management, but as a Fennec front-end engineer
I know we are planning to slow these unusual uplifts in Fennec 16 and
hopefuly stop them completely in Fennec 17.
I would support a decision to string-freeze Fennec 16 when it hits
Aurora, or soon after if product feels we absolutely need a window
during Aurora 16 when we can still uplift new strings. Certainly by
Aurora 17 we should return completely to normal uplift and string freeze
rules. (Breaking feature-freeze on Aurora and Beta causes pain for the
front-end team as well as for localizers.)
Axel Hecht
Jul 25, 2012, 6:25:37 PM7/25/12
to
Hi.
First of all, thanks to flod for pushing this to .planning. I see value
in getting more people involved than just me talking to folks on either
side.
To flod's question, fennec is in a inconvenient state, in that 14 was
mostly a 1.0 in many aspects, but in particular for l10n, it was also
not. We didn't want to loose localizations, but we've also been shipping
from scratch. It doesn't help that we're still not able to ship all our
l10n contributions on Android, at least not with the Firefox brand on it.
We're still recovering from that 1.0-ish situation, and we're trying to
strike a balance between "being on the trains" and "we should ship some
updates". We didn't have the people to develop a compelling 14 and 15 in
parallel, so even though fennec now moves from branch to branch on
migration date, we're not following the code and string freeze policies
of the rapid release model yet. That's obviously true for 15, and as
Matt said, for 16 as well.
The dev team is on the hook to enable our localization teams to create a
great localized product. That does include feature landings for 15,
beyond what we're used to on aurora, and sadly even beta. With the
string freeze for build 3, I think that our localization teams can still
make it. Maybe not all of the 15 that we're shipping, but most. It's an
additional risk to the quality of the product, though, and thus it's
only OK for a limited amount of time. QA is also aware that pestering
localization teams on missing strings in this situation isn't the best
use of everyone's time and patience. I did invite them to file bugs on
localized cropped strings and such, though. We've also communicated
among the development and product teams that uplifting features may
result in that feature shipping with English strings. That's part of the
consideration of uplifting that feature to aurora, or beta.
To wrap this email up with some straight answers to obvious questions:
Did we have a plan for 15? Nope. Turned out that I called into the
regular Wednesday mobile development meeting, Brad said that feature
uplift would be done, and I asked whether that meant "string freeze". He
said "well, one more might come". There have been ideas in some heads,
but I don't think we can claim to have had a plan.
Do we have a plan for 16? Not yet. We intend to have one though, and
some constructive input on that.
Do we have a plan on when we'll stop having to have plans? OK, I wanted
to word it that way, in honest: When are we just going to be riding the
trains? I haven't heard a sincere commitment to anything there yet.
Axel
First of all, thanks to flod for pushing this to .planning. I see value
in getting more people involved than just me talking to folks on either
side.
To flod's question, fennec is in a inconvenient state, in that 14 was
mostly a 1.0 in many aspects, but in particular for l10n, it was also
not. We didn't want to loose localizations, but we've also been shipping
from scratch. It doesn't help that we're still not able to ship all our
l10n contributions on Android, at least not with the Firefox brand on it.
We're still recovering from that 1.0-ish situation, and we're trying to
strike a balance between "being on the trains" and "we should ship some
updates". We didn't have the people to develop a compelling 14 and 15 in
parallel, so even though fennec now moves from branch to branch on
migration date, we're not following the code and string freeze policies
of the rapid release model yet. That's obviously true for 15, and as
Matt said, for 16 as well.
The dev team is on the hook to enable our localization teams to create a
great localized product. That does include feature landings for 15,
beyond what we're used to on aurora, and sadly even beta. With the
string freeze for build 3, I think that our localization teams can still
make it. Maybe not all of the 15 that we're shipping, but most. It's an
additional risk to the quality of the product, though, and thus it's
only OK for a limited amount of time. QA is also aware that pestering
localization teams on missing strings in this situation isn't the best
use of everyone's time and patience. I did invite them to file bugs on
localized cropped strings and such, though. We've also communicated
among the development and product teams that uplifting features may
result in that feature shipping with English strings. That's part of the
consideration of uplifting that feature to aurora, or beta.
To wrap this email up with some straight answers to obvious questions:
Did we have a plan for 15? Nope. Turned out that I called into the
regular Wednesday mobile development meeting, Brad said that feature
uplift would be done, and I asked whether that meant "string freeze". He
said "well, one more might come". There have been ideas in some heads,
but I don't think we can claim to have had a plan.
Do we have a plan for 16? Not yet. We intend to have one though, and
some constructive input on that.
Do we have a plan on when we'll stop having to have plans? OK, I wanted
to word it that way, in honest: When are we just going to be riding the
trains? I haven't heard a sincere commitment to anything there yet.
Axel
Matt Brubeck
Jul 25, 2012, 7:35:26 PM7/25/12
to
On 07/25/2012 11:35 AM, Matt Brubeck wrote:
> I would support a decision to string-freeze Fennec 16 when it hits
> Aurora, or soon after if product feels we absolutely need a window
> during Aurora 16 when we can still uplift new strings.
Oops, I'm not sure what I was thinking when I wrote this. Fennec 16 is
> I would support a decision to string-freeze Fennec 16 when it hits
> Aurora, or soon after if product feels we absolutely need a window
> during Aurora 16 when we can still uplift new strings.
already on Aurora, so it's already too late to freeze it at the start of
its Aurora cycle. I'd support a string freeze that starts soon, while
16 is still on Aurora.
Brad Lassey
Jul 27, 2012, 9:07:59 AM7/27/12
to
On Wednesday, July 25, 2012 7:35:26 PM UTC-4, Matt Brubeck wrote:
First, apologies for joining this thread late, I haven't been reading dev.platform as often as I probably should.
String freeze for Firefox 15 for Android is today. This was decided on Wednesday and announced at the dev team meeting that day. There is one remaining potential string change that will need to get sorted before EOB today, which is in bug 725286. The sorting that needs to be done is whether to take that string change to mitigate the poor user experience of blocking flash on tegra2 devices or bug 777746 to remove the blocking of tegra2 devices all together.
We don't have an official string freeze date for Firefox 16 for Android yet. I'm hoping it can be quite soon, but I won't make that decision without first consulting mfinkle, who is currently on vacation.
The eventual goal is to get back on the regular train schedule. Perhaps we can do that in Firefox 17, but I can't commit to that yet.
First, apologies for joining this thread late, I haven't been reading dev.platform as often as I probably should.
String freeze for Firefox 15 for Android is today. This was decided on Wednesday and announced at the dev team meeting that day. There is one remaining potential string change that will need to get sorted before EOB today, which is in bug 725286. The sorting that needs to be done is whether to take that string change to mitigate the poor user experience of blocking flash on tegra2 devices or bug 777746 to remove the blocking of tegra2 devices all together.
We don't have an official string freeze date for Firefox 16 for Android yet. I'm hoping it can be quite soon, but I won't make that decision without first consulting mfinkle, who is currently on vacation.
The eventual goal is to get back on the regular train schedule. Perhaps we can do that in Firefox 17, but I can't commit to that yet.
0 new messages