[Go Faster] Hello-as-addon challenges
chofmann at mozilla.com
Wed Sep 9 04:31:35 UTC 2015
On Tue, Sep 8, 2015 at 6:37 PM, Mike Connor <mconnor at mozilla.com> wrote:
> So, let's unpack this:
> * We're not really giving clients a "decision logic" in this case. We're
> providing the data to apply the decision we make, i.e. by marking an add-on
> as only compatible with a subset of locales or regions.
not sure if I follow what you mean here.
> * I don't think "known good only" and "unstable/beta add-ons" are mutually
from my understanding we will definitely have these states when system
addons become the delivery mechanism for several new features. when we get
to several system addons as features we will probably have a few that are
stable and unchanging, and another that are just entering the new and
experimental stage. The later are likely to be half baked ideas and
experiments that we want to try out on a few years, and the former are the
only ways to get new features to all of our users under this new
> In the general case, a core system add-on should not have any dependency
> or conflict with another core system add-on. The model has to be flexible,
> and we have to manage dependencies cleanly.
right. but but we probably will run into dependencies and conflicts and
will need to have systems in place to manage both if we have a parallel
delivery system. I mentioned this on IRC but its worth repeating. the
pdf.js security chemspill for 39.0.3 is mentioned as a place where system
addons might have made life better, but from examination of the bug it
actually makes life more complex. The fix required both core gecko and
pdf.js fix and would require both to address the security bug. we would
have needed ways to synchronize and manage update of core gecko and pdf.js
addon bits to handle this case properly. See
https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/ and linked
> * Virtually all new features we ship via this mechanism will be
> locale-constrained (in that we won't have stable strings) for some period
> of time. We're not going to wait on all 80 locales to roll something out
> to a wider audience.
Maybe, but its not clear to me that this statement is true. It all depends
on how much attention and scrutiny these system addons are going to get for
testing, security reviews, alpha and beta testing user feedback and
response, and all the things that need to go into making great software.
Its the elephant in the room but I think many developers are hoping this
delivery mechanism is just a way to bypass many of those things. if these
system addons are just another train jumping mechanism there is good chance
they will lead to lower quality. If we really take the time for all these
things to happen localization for all of our locales will fit into the
system addon release cycle nicely.
> Just like I don't expect we'll roll a feature to 100% of users off the
> bat. We'll have to manage those tradeoffs smoothly, but the goal here is
> to go faster and avoid the delays of all-or-nothing thinking.
I'm not sure all or nothing thinking is a good way to think about, or
reflects what we have now. Pockets a good case for what we end up with.
Lots of short cuts taken, and in the end its what very few of were
comfortable or proud to ship. No real time for designing a good
impimentation, or time for beta testing or time to address any significant
user feedback. We can choose not to have system addon development managed
that way, its sounding like not.
* I expect that our data processes will continue to be the same. To my
> knowledge, we have yet to have a data practice that was not globally
> acceptable from the beginning, so this shouldn't change anything. I don't
> think anything I'm suggesting would run counter to that practice.
I'm not sure what this means either. Are there examples of what you mean
> On 2 September 2015 at 13:26, Axel Hecht <axel at mozilla.com> wrote:
>> I think that we should make decisions once, and then distribute the data
>> to support them, rather than giving all the data and the decision logic to
>> all clients, and then have them figure stuff out.
>> The real question here is still which decisions we're making, based on
>> what data.
>> Which decisions are done by humans, and which decisions are done by bots.
>> And if we're opening up the dimension of per-locale decisions, what does
>> that mean for our data processes?
>> I would think that we're not willing to open up per-locale-per-feature,
>> as that'd contradict our scheme of only having known good
>> feature-combinations shipping.
>> On 9/1/15 6:33 PM, Mike Connor wrote:
>> We've done locale-limited features in the recent past ("Flare" search UI
>> rolled by locale through 34/35/36), via a locale-driven pref. There's also
>> absearch, which could be trivially extended/duplicated to roll out other
>> settings by language/region/etc.
>> In an ideal world, system add-ons will be able to embed some sort of flag
>> to indicate locale/region compatibility, and Firefox will determine whether
>> to load the add-on at all based on that flag. If the add-on strings get
>> updated, we push a new update, Firefox sees that the locale is now
>> supported, and we can then load for those users. We could supplement with
>> an absearch-like microservice if we want to do a phased rollout. (And I
>> think we'll want to be able to do a non-binary rollout of potential new
>> -- Mike
>> On 1 September 2015 at 09:40, Armen Zambrano Gasparnian <
>> <armenzg at mozilla.com>armenzg at mozilla.com> wrote:
>>> Can we deliver features to locales only if they have been localized and
>>> signed off?
>>> In other words, make a feature available only if we have marked that the
>>> localization for it is ready for it.
>>> It would be great if the browser would be able to determine at what
>>> point a a feature has been localezied and signed off, fetch the strings for
>>> that feature and enable it.
>>> I believe this would give us all the ability to move forward and
>>> localizers to catch up.
>>> On 31 August 2015 at 17:50, Axel Hecht < <axel at mozilla.com>
>>> axel at mozilla.com> wrote:
>>>> On 8/31/15 11:36 PM, Toby Elliott wrote:
>>>>> On Aug 26, 2015, at 12:13 PM, Chris Hofmann <chofmann at mozilla.com>
>>>>>> Yes, that's theortically possible, but leads to trying to manage 80+
>>>>>> releases for each of the locales that we serve, and a very complex
>>>>>> release management process in terms of commuication and execution.
>>>>>> Ben, locales 4, 8, 10, and 22 are ready to go... please build and
>>>>>> push those.
>>>>>> Ben, locales 25, 41, and 15 are ready to go... please push those.
>>>>> Couldn't this be "Ben, enough locales are in to ship this, please
>>>>> push" followed by out-of-band string updates for those other localizations
>>>>> as they come in?
>>>> So, 'enough' is undefined, see below ...
>>>>> Do we simply refuse to ship a feature to a locale if the translation
>>>>> hasn't come in? Or is it acceptable to have fallback strings in parts of
>>>>> the browser when a more obscure language hasn't been localized yet?
>>>> This is the real question: Is it OK to ship a string in English in ...
>>>> The answer is gated on the question, really.
>>>> If the question is "are we gonna learn something useful out of shipping
>>>> this?", then the answer is only going to be yes if the translations of that
>>>> test are awesome. Otherwise you'll just measure "oh my god, this isn't in
>>>> my language", followed by "oh my gosh, this is horrible grammar". The
>>>> latter is actually real feedback I just read the other day. You're not
>>>> going to see any signal in our data that's related to the patch in question.
>>>> If the question is "is this feature good to ship in English?", that's a
>>>> VERY complicated question. Depends on culture, and beyond that, user
>>>> population within that culture. Can you say "hey, buddy", literally, to me?
>>>> Sure. Can you say that to my mom? Hell no. Which brings us back to the
>>>> question of what's there to gain, and what's there to loose.
>>>> And lastly, there's some concrete lessons we've learned in the past few
>>>> years. If UI sucks and survives, it'll suck. If it dies, it dies. The
>>>> expectation that we'll "ship things as they come in" doesn't match our
>>>> real-life experience. And the lack thereof makes total sense to me, at
>>>> least in my cynical way of thinking about human beings.
>>>> Gofaster mailing list
>>>> Gofaster at mozilla.org
>>> Zambrano Gasparnian, Armen
>>> Automation & Tools Engineer
>>> Gofaster mailing list
>>> Gofaster at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gofaster