Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Is there a clear schedule for mobile (or "mobile and l10n")?
8 views
Skip to first unread message
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
On 25.07.12 20:35, Matt Brubeck wrote:
> 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
> 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.)
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
On 25.07.12 20:35, Matt Brubeck wrote:
> 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
> 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.)
0 new messages