Re: e10s status update (not going to GA in 45)

[Chris Peterson]

On 12/30/15 12:30 PM, Brad Lassey wrote:

*Population.* Our plan has been to release e10s first to users who have no
add-ons and no a11y features enabled due to known issues with those two
areas of code. Our crash data from the 44 experiment indicates that we have
both sets of users in the experiment population.


What percentage of users are eligible, i.e. have no add-ons and no a11y?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

[Johnny Stenback]

Indeed, well done all around, thank you to all the sheriffs and
everyone who worked with the sheriffs, directly or indirectly, in
2015! Looking forward to a great 2016!

- jst


On Wed, Dec 30, 2015 at 8:32 AM, Lawrence Mandel  wrote:
> hear, hear! Thank you.
>
> Lawrence
>
> On Wed, Dec 30, 2015 at 9:27 AM, Kartikaya Gupta  wrote:
>
>> Yes, thank you to all the sheriffs for all their hard work!
>>
>> On Wed, Dec 30, 2015 at 9:19 AM, Carsten Book  wrote:
>> > Hi,
>> >
>> > Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
>> > lot of teamwork with different Groups and our Community like Developers,
>> IT
>> > Teams and Release Engineering and a lot more to keep the trees up and
>> > running. And without this great teamwork our job would be nearly
>> impossible!
>> >
>> > So far in 2015 we had around:
>> >
>> > 56471 changesets with 336218 changes to 70807 files in mozilla-central
>> > and 4391 Bugs filed for intermittent failures (and a lot of them fixed).
>> >
>> > So thanks a lot for the great teamwork with YOU in 2015 - especially
>> also a
>> > great thanks to our Community Sheriffs like philor, nigelb and Aryx who
>> > done great work!
>> >
>> > I hope we can continue this great teamwork in 2016 and also the monthly
>> > sheriff report with interesting news from the sheriffs and how you can
>> > contribute will continue then :)
>> >
>> > Have a great start into 2016!
>> >
>> > Tomcat
>> > on behalf of the Sheriffs-Team
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>>
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Maintaining the en-US dictionary that ships with Mozilla products

[Jörg Knobloch]

On 30/12/2015 10:20, Jörg Knobloch wrote:

I can't understand how the current system could manage SCOWL removals
yet not remove words Mozilla specifically added. How does it know that a
word came from SCOWL and can be removed or it didn't come from SCOWL and
should be maintained?


Oops, I was wrong again. It knows by comparing the previous SCOWL 
version with the new one. I hope I'm excused, since I even managed to 
confuse Ehsan ;-)


> I'm not using the defective en-US spelling anyway.

I'm not using it and it is defective, but I'm happy to help fixing it, 
and I already made a start with this discussion ;-)


Let's continue the discussion in bug 1235506.

I see the following problems which we need to solve:
1) Guarantee a "rich" dictionary for the users where no "useful"
   words get removed without review. IMHO too many "good" words
   were removed by the April/May 2015 merge with SCOWL data.
2) Clean-up Mozilla additions with contain many errors.
3) Feed useful Mozilla additions back to SCOWL.

Jorg K.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Maintaining the en-US dictionary that ships with Mozilla products

[Jim Mathies]

On Tuesday, December 29, 2015 at 2:38:43 PM UTC-6, Ehsan Akhgari wrote:
> On 2015-12-28 5:11 PM, Jim Mathies wrote:
> > We could research using native spell checking apis if the platform supports 
> > them. For example Windows added spell checking apis in Windows 8.
> 
> It's not obvious to me why that would be an improvement.  The 
> cross-platform nature of our spell checking engine is definitely a plus.

- no dictionary maintenance overhead for Mozilla
- I'm guessing a better, more robust dictionary in general
- a database that is standardized across multiple applications (including 
custom dictionary settings) for the same system
- less data in our install.. it might only amount to kilobytes, but when you 
multiply that by millions of downloads it adds up.

It's not obvious to me what an open source database engine provides for us. Can 
our current engine support 3rd party data providers? That's really what we want 
to do here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

e10s status update (not going to GA in 45)

[Brad Lassey]

tl;dr: we no longer plan to ship e10s to our release population in Firefox
45


Several of us just met to go over the data we've collected on the our Beta
44 e10s experiment and how it relates to our release criteria. There are
three main areas of concern.

*Population.* Our plan has been to release e10s first to users who have no
add-ons and no a11y features enabled due to known issues with those two
areas of code. Our crash data from the 44 experiment indicates that we have
both sets of users in the experiment population.

*Stability. *Beta 44 with e10s seems to be crashing or hanging roughly 20%
more frequently than Beta 44 without e10s. One of our release criteria is
to not regress the crash and hang rate.

*Responsiveness.* Our measure of responsiveness, BHR, shows that users with
e10s enabled are seeing more event loop jank than users without e10s
enabled.

For the population issue, we have already landed code in 45 to address
those issues and bugs are filed to shore that up some more. For stability
and responsiveness, we have gathered useful information that we will use to
address those issues. In order to gather even more useful information we
plan to expand our e10s experiment in 45 Beta to 50% of users, meaning that
50% of users will get e10s turned on if they have no a11y features enabled
and no add-ons installed. The goal now is to target 46 release.

-Brad
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

[David Burns]

Well done Sheriffs! Really proud of all the work you did this year!

David

On 30 December 2015 at 14:19, Carsten Book  wrote:

> Hi,
>
> Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
> lot of teamwork with different Groups and our Community like Developers, IT
> Teams and Release Engineering and a lot more to keep the trees up and
> running. And without this great teamwork our job would be nearly impossible!
>
> So far in 2015 we had around:
>
> 56471 changesets with 336218 changes to 70807 files in mozilla-central
> and 4391 Bugs filed for intermittent failures (and a lot of them fixed).
>
> So thanks a lot for the great teamwork with YOU in 2015 - especially also
> a great thanks to our Community Sheriffs like philor, nigelb and Aryx who
> done great work!
>
> I hope we can continue this great teamwork in 2016 and also the monthly
> sheriff report with interesting news from the sheriffs and how you can
> contribute will continue then :)
>
> Have a great start into 2016!
>
> Tomcat
> on behalf of the Sheriffs-Team
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

[Ehsan Akhgari]

On 2015-12-29 6:24 PM, Steve Fink wrote:

That makes me think that we're not disagreeing very much. Still some, I
think, but sure -- if assigning a handful of people to work on
intermittent oranges makes the problem go away, then that seems like a
reasonable thing to do. Though if you're taking existing developers, and
I think you'd have to in order to get anywhere, then you'd want to be
sure that stalling off what they're currently working on is not going to
strike them as a ridiculously bad idea.

And even then, I'm not sure of the "tiger team" approach here. We have
that now, and his name is Ehsan. He has good evidence to show that it
doesn't work.


FWIW, the reason that it doesn't work is that my time is limited and 
can't be devoted to this problem enough, and in many cases when I ask 
someone else to help, the answer is that they don't have time.


If more people did this more systematically, I think we can get to a 
good place in the number of oranges, and stay there.



But this sort of problem seems like it's something we have an
institutional disregard for. And any attempt to spot-fix it without
addressing that systemic issue seems less likely to succeed. *That* is
what I understood the true motivation for things like enforced tree
closures was -- not to directly solve the issue, but to force everyone
to care more about it, so that we don't have to do crappy things like
that. But I still don't like it, because it feels like a "you must write
at least 100 lines of code a day" type of thing: it doesn't necessarily
put the pressure at the right place, and it causes a lot of collateral
damage.


I really doubt that the idea of closing trees indefinitely is realistic 
enough to even merit a discussion.  :-)



I didn't really want to get into this (hey, I just wanted to throw out a
suggestion to get people thinking), but to me the problem is that we're
at all ok with allowing the current situation to develop. The sheriffs
have been warning about impending orangopocalypse for as long as I can
remember, and we've all (myself included) largely ignored them. Ehsan
has also brought this up several times, with real data as to how
addressable this is with focused effort, and from what I can tell the
response has basically been a collective "boy, that Ehsan guy is smart
and nice to have around" followed by a continuation of the current way
of doing things.


Yes, exactly.  Our current situation is that people can successfully get 
by pretending that the orange situation is "someone else's problem". 
Look at it this way.  If you decide to ignore an orange bug in your area 
at all costs, you'll have no problem doing that.  Just ignore the bug 
long enough until a) someone else actually fixes it, or b) the test gets 
disabled by a sheriff.


A "tiger team" approach can bring us into a good spot now, but while the 
situation above doesn't change, we'll end up back where we are.  And 
we'll end up having this conversation once again.



To be fair, we *are* doing some important work in the right direction. I
don't know what all of it is, but the treeherder improvements for
identifying and categorizing oranges is really important, as are rr,
chaos mode, web replay, and related work. To me at least, that still
feels like more of the "let's throw a few smart people at the systemic
problem" approach, though. I could be wrong. Maybe we're close enough to
being able to recognize failures and direct them to the appropriate
people, who will then jump up and fix them, that this whole problem will
go away soon.

/me holds breath

/me turns blue


It's true that some of these new initiatives will help debugging 
intermittent failures, they're not strictly needed.  What we need is 
accepting shared responsibility about this issue, and address it like 
any other ongoing technical issue.


Part of this shared responsibility is acknowledging that this is part of 
what MoCo employed engineers need to spend time on, which requires 
support for engineering managers.  As the recent response to bkelly's 
triaging effort shows, there is a lot of goodwill on this issue both 
from engineers and managers, so I hope this time we'll keep being on top 
of this issue.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

[Lawrence Mandel]

hear, hear! Thank you.

Lawrence

On Wed, Dec 30, 2015 at 9:27 AM, Kartikaya Gupta  wrote:

> Yes, thank you to all the sheriffs for all their hard work!
>
> On Wed, Dec 30, 2015 at 9:19 AM, Carsten Book  wrote:
> > Hi,
> >
> > Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
> > lot of teamwork with different Groups and our Community like Developers,
> IT
> > Teams and Release Engineering and a lot more to keep the trees up and
> > running. And without this great teamwork our job would be nearly
> impossible!
> >
> > So far in 2015 we had around:
> >
> > 56471 changesets with 336218 changes to 70807 files in mozilla-central
> > and 4391 Bugs filed for intermittent failures (and a lot of them fixed).
> >
> > So thanks a lot for the great teamwork with YOU in 2015 - especially
> also a
> > great thanks to our Community Sheriffs like philor, nigelb and Aryx who
> > done great work!
> >
> > I hope we can continue this great teamwork in 2016 and also the monthly
> > sheriff report with interesting news from the sheriffs and how you can
> > contribute will continue then :)
> >
> > Have a great start into 2016!
> >
> > Tomcat
> > on behalf of the Sheriffs-Team
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Maintaining the en-US dictionary that ships with Mozilla products

[Ehsan Akhgari]

On 2015-12-30 2:10 PM, Jim Mathies wrote:

On Tuesday, December 29, 2015 at 2:38:43 PM UTC-6, Ehsan Akhgari wrote:

On 2015-12-28 5:11 PM, Jim Mathies wrote:

We could research using native spell checking apis if the platform supports 
them. For example Windows added spell checking apis in Windows 8.


It's not obvious to me why that would be an improvement.  The
cross-platform nature of our spell checking engine is definitely a plus.


- no dictionary maintenance overhead for Mozilla


We would still need to do that since not all of the platforms we target 
have spell checking support.



- I'm guessing a better, more robust dictionary in general


I would like to see some data backing that claim.  I won't be surprised 
if our hunspell based spell checker does better than for example the 
Win8+ spell checker, at least for some of the languages we support.



- a database that is standardized across multiple applications (including 
custom dictionary settings) for the same system


That is a good point.


- less data in our install.. it might only amount to kilobytes, but when you 
multiply that by millions of downloads it adds up.


This will require us to be able to exclude parts of the default 
installed package based on the OS version (since we need to support 
hunspell for Win7 and below on Windows, for example) which we don't 
have, AFAIK.



It's not obvious to me what an open source database engine provides for us. Can 
our current engine support 3rd party data providers? That's really what we want 
to do here.


Our spell checking backend doesn't support non-hunspell based checkers 
currently.


What I was referring to in terms of advantages of a cross platform spell 
checking backend was having the same experience on all platforms, which 
eases things such as dealing with bug reports, and also the ability to 
address bug reports, etc.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Daniel Holbert]

Summary:
  A good chunk of the web today (and particularly the mobile web)
effectively relies on -webkit prefixed CSS properties & features. We
wish we lived in a world where web content always included
standards-based fallback (or at least multiple-vendor-prefixed
fallback), but alas, we do not live in that world.  To be successful at
rendering the web as it exists, we need to add support for a list of
frequently-used -webkit prefixed CSS properties & features.
  Every other major modern browser engine implements support for these
aliases -- Blink & WebKit obviously have them, & Edge includes them for
compatibility.  (I'm not sure about IE's support, but it's not a
particularly important data point, given that Microsoft is focused on
Edge going forward.)

Bug tracking implementation:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1170789

Bug to enable pref:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1143147
 (Will likely land in the next few days.)

Link to standard:
  Mike Taylor is working on a WHATWG spec describing the -webkit
prefixed features that we believe are needed for web compatibility.
That spec lives here: http://compat.spec.whatwg.org/
  There's also been some discussion on the CSSWG mailing list about
updating official CSS specs to mention legacy -webkit aliases (and
discourage authors from using them), as discussed in this thread:
https://lists.w3.org/Archives/Public/www-style/2015Dec/0132.html

Platform coverage:
  All platforms.

Estimated or target release:
  Firefox 46 (current Nightly), or 47 if we need to hold it back a
release to fix things.

Preference behind which this will be implemented:
  layout.css.prefixes.webkit

Side note on earlier work:
  Earlier this year, in bug 1107378, we shipped an experimental JS-based
version of this feature, which was only active for a whitelist of sites
(all of which strongly depend on webkit prefixes for usability). This
experiment proved successful at making the whitelisted sites usable in
Firefox.  The new implementation (behind "layout.css.prefixes.webkit")
will supersede the older experimental JS-based implementation and will
not be whitelisted.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Maintaining the en-US dictionary that ships with Mozilla products

[Jörg Knobloch]

On 30/12/2015 01:46, Ehsan Akhgari wrote:

First things first, let's correct something here.  We do _not_ maintain
three word lists.  We maintain one list: the list of words that the
Firefox spellchecker accepts.
I know I sound like a broken record: I suggested to change the process 
and maintain three lists.



I'm afraid you're misunderstanding what's happened here.  We only
maintain one word list, and our process of merging upstream changes is
purely additive.  As a result, it doesn't handle the case where a word
disappears from SCOWL.

This is clearly a bug, and should be fixed.
I came to realise that my argument has a hole. On one had I'm 
complaining that at the beginning of May 2015 words got removed, see:

https://hg.mozilla.org/mozilla-central/diff/bcb133a3cdca/extensions/spellcheck/locales/en-US/hunspell/dictionary-sources/orig/en_US.dic
(don't open in Firefox, it will hang, bug 1235321):
-relict
-residuary
-enforceability
(all still included in the "large" dataset).

On the other hand I'm complaining that wrong entries, like "remind's" 
are maintained in the Mozilla data. "remind's" is not a valid word in 
SCOWL (http://app.aspell.net/lookup?dict=en_US=remind%27s), but it 
is in Mozilla. So there is a bug in the removal process.


Frankly, I can't understand how the current system could manage SCOWL 
removals yet not remove words Mozilla specifically added. How does it 
know that a word came from SCOWL and can be removed or it didn't come 
from SCOWL and should be maintained? Broken record: Maintaining Mozilla 
words differently (three lists) would fix this.



We may still decide to keep
individual words that SCOWL drops if we decide that we want the Firefox
spell checker to accept them, but as a general rule we should probably
follow upstream.
It is pretty much unmanageable to do this. On every refresh you would 
have to add removed words manually. Broken record: Mozilla should not 
manage the general English words (apart from some exceptions, see below).



We should leave it to SCOWL
to manage the plain English dictionary and only manage the Mozilla
additions (for which I see three classes, see above).

I disagree.  I think we should accept the words that we want, and then
try to upstream them to SCOWL, without holding Firefox back until that
happens.  I experimented with this once
 but unfortunately I
haven't had the time to go through all of the list.  (As a non-native
speaker this task requires me to spend weeks looking things up in
dictionaries!)
I sound like a broken record but you ignored my proposal: To facilitate 
the process of having more words than SCOWL, I proposed to split these 
"more words" into three files. The third file would contain "general" 
words we request upstream.



Wonderful!  If you have a list of words using these types of characters
that we need to add, please file a bug, and let's do that!
No I won't do that. I filed a a bug to use the "large" dictionary, but 
you even changed the summary and hijacked it for something else. It 
makes no sense to request a heap of words to be added to the Mozilla 
dictionary, like "résumé", "née" and so on, which already exist in the 
"large" dataset. Broken record: Mozilla doesn't want to be in the 
business of managing this. Mozilla should be in the business of managing 
Mozilla specific additions, and perhaps a small amount of general words 
that get added (third list), which will then be requested upstream.


The current system can't do this, you resist changing it, so I just give 
up, since I'm not using the defective en-US spelling anyway.


Jorg K.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Thanks for all the great teamwork with the Sheriffs in 2015!

[Carsten Book]

Hi,

Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
lot of teamwork with different Groups and our Community like Developers, IT
Teams and Release Engineering and a lot more to keep the trees up and
running. And without this great teamwork our job would be nearly impossible!

So far in 2015 we had around:

56471 changesets with 336218 changes to 70807 files in mozilla-central
and 4391 Bugs filed for intermittent failures (and a lot of them fixed).

So thanks a lot for the great teamwork with YOU in 2015 - especially also a
great thanks to our Community Sheriffs like philor, nigelb and Aryx who
done great work!

I hope we can continue this great teamwork in 2016 and also the monthly
sheriff report with interesting news from the sheriffs and how you can
contribute will continue then :)

Have a great start into 2016!

Tomcat
on behalf of the Sheriffs-Team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

[Kartikaya Gupta]

Yes, thank you to all the sheriffs for all their hard work!

On Wed, Dec 30, 2015 at 9:19 AM, Carsten Book  wrote:
> Hi,
>
> Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
> lot of teamwork with different Groups and our Community like Developers, IT
> Teams and Release Engineering and a lot more to keep the trees up and
> running. And without this great teamwork our job would be nearly impossible!
>
> So far in 2015 we had around:
>
> 56471 changesets with 336218 changes to 70807 files in mozilla-central
> and 4391 Bugs filed for intermittent failures (and a lot of them fixed).
>
> So thanks a lot for the great teamwork with YOU in 2015 - especially also a
> great thanks to our Community Sheriffs like philor, nigelb and Aryx who
> done great work!
>
> I hope we can continue this great teamwork in 2016 and also the monthly
> sheriff report with interesting news from the sheriffs and how you can
> contribute will continue then :)
>
> Have a great start into 2016!
>
> Tomcat
> on behalf of the Sheriffs-Team
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform