New: QA Test Plan Sign-off Requirement

[Lawrence Mandel]

(cross posting to a few lists for visibility)


tl;dr Starting with the Firefox 57 release, test plans will require
sign-off from Engineering, Product and QA before testing begins.

Engineering, Product, and QA each have unique insights into risks
associated with feature development. We have the best chance of success
when we have a diverse set of feedback on our plans. For QA, we need that
feedback early while there is time to adjust our test plans. The intention
is to avoid last-minute surprises and misunderstandings about test scope
that has at times been problematic when reporting test results.

In order to ensure QA receives the feedback they need, we are adding a
sign-off requirement. What we’re really asking is that you take an active
role in the quality assurance of your work by taking time to read the test
plan and provide feedback.

Three points related to sign-offs:

1. Granting a sign-off means:

   -

   High level testing objectives and testing scope are understood
   -

   Contents of ‘Risk Assessment and Coverage’ and ‘Test Areas’ meet your
   expectations


2. Sign-off is expected 1 week after it is requested. (Should typically be
near the beginning of the Nightly cycle.)

3. Sign-offs will be captured in each QA test plan as shown in the QA Test
Plan Template .

Thanks for your commitment to the quality of Firefox.

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

Re: [RelEng] Switching to TaskCluster Windows builds on Wednesday July 26th

[Lawrence Mandel]

What Dustin said. Thrilled to see some big jobs moving to TC. Keep pushing!

Lawrence

On Fri, Jul 21, 2017 at 3:02 PM, Dustin Mitchell  wrote:

> Nice work -- what a milestone!
>
> Dustin
> ___
> release-engineering mailing list
> release-engineer...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/release-engineering
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: switch to macosx cross-compiled builds on taskcluster on trunk

[Lawrence Mandel]

\o/ Congratulations to everyone involved in making this happen! (Take a
breath.) On to release!

On Thu, Jun 22, 2017 at 3:09 PM, Kim Moir  wrote:

> After successful testing this morning, we have now enabled macosx nightly
> updates again.
>
> The migration is complete, enjoy your cross compiled builds and more
> scalable CI infrastructure.
>
> Kim
>
> On Wed, Jun 21, 2017 at 10:04 PM, Kim Moir  wrote:
>
> > Status update:
> >
> > We have successful cross compiled macosx opt builds running on trunk.  We
> > also have run a successful nightly cross compiled nightly on m-c.  We are
> > going to leave the rule in place that blocks updates for macosx nightlies
> > so we can test and update from tonight's nightly to tomorrow's nightly on
> > the test channel, before enabling updates for all nightly users.
> >
> > Kim
> >
> > On Wed, Jun 21, 2017 at 12:35 PM, Kim Moir  wrote:
> >
> >> At 11:00PT today, we will be landing patches to run mac opt builds on
> >> trunk as cross compiled builds on Linux machines on taskcluster.  As
> this
> >> change is uplifted to m-c, nightly builds for mac will also switch to
> run
> >> on taskcluster on Linux.  We will be testing to ensure that updates
> work as
> >> expected.  We don’t expect any impact to developers as this has been
> tested
> >> extensively on a project branch as well as by manual testing by PI.
> >>
> >>
> >>
> >> If you have questions, please contact us in #releng
> >>
> >>
> >>
> >> Enable OSX cross-compile builds as tier1 on mozilla-central
> >>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1374422
> >>
> >>
> >>
> >> Land completed OSX cross compile Nightly code to mozilla-central
> >>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1357867
> >>
> >>
> >>
> >> Land more Nightly OSX support to central
> >>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1373326
> >> 
> >>
> >>
> >>
> >> Kim Moir
> >>
> >> Mozilla Release Engineering
> >>
> >>
> >>
> >
> >
> ___
> 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: unowned module: Firefox::New Tab Page, help me find an owner

[Lawrence Mandel]

On Wed, Mar 22, 2017 at 10:33 AM, Ben Kelly  wrote:

> On Wed, Mar 22, 2017 at 10:00 AM, David Burns  wrote:
>
> > On 22 March 2017 at 13:49, Ben Kelly  wrote:
> >
> >> Finding someone to own the feature and investigate intermittents is
> >> important too, but that doesn't mean the tests have zero value.
> >>
> >
> > This just strikes me that we are going to disable until they are all gone
> > then we have dead code in the tree and still no one to own it. Its a
> longer
> > process that could end up at the same end point.
> >
>
> Are *all* the tests intermittent?  My quick read of the bug was that its a
> single test.  I just don't understand the logic of *removing green tests*
> from the tree.  The idea they might one day become intermittent is not
> compelling to me.
>

Leaving aside this part, I think Joel's request is help to find an owner
for these tests who can be responsible for maintaining them. I think this
is the right approach and will help get the test suite into a better state
over time. Finding an owner makes the rest of this thread moot at this
point (although we can certainly talk about policy separately). Is there an
obvious owner for the new tab page tests and Bugzilla component? To which
engineering team does this work now fall?

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

Re: Sheriff Highlights and Summary in February 2017

[Lawrence Mandel]

I don't know that it's useful to modify your report if you're confident in
your estimates below. Thanks for the additional information.

Lawrence

On Tue, Mar 7, 2017 at 4:03 AM, Carsten Book <cb...@mozilla.com> wrote:

> Hi Lawrence,
>
> most (i would say 95 %) of the backouts are for Code issues - this include
> bustages and test failures.
>
> From this Code Issues i would guess its about 2/3 for breaking tests and
> 1/3 Build Bustages.
>
> The other backout reasons are merge conflicts / backout requests for
> changes causes new regressions out of our test suites / backout requests
> from developers etc -
>
> In February the backout rate was (excluding the servo merge with 8315
> changesets from the 13242) = 297 in 4927 changesets = ~ 6 %
> In January the backout rate = 302 backouts in 4121 changesets = 7 %
>
> We had a much higher backout rate in the past i think - so it stabilized
> now with this 6-7 % backout rate in the last months,
>
> If you think its useful, i can provide for the next monthly report a more
> detailed analysis like x % =  backouts because builds bustages, y %=
> backouts for test failures etc .
>
> Cheers,
>  -Tomcat
>
>
> On Mon, Mar 6, 2017 at 11:13 PM, Lawrence Mandel <lman...@mozilla.com>
> wrote:
>
>> Hi Tomcat,
>>
>> Do you have any more details about the reasons why the 297 changesets
>> needed to be backed out?
>>
>> Thanks,
>>
>> Lawrence
>>
>> On Wed, Mar 1, 2017 at 6:05 AM, Carsten Book <cb...@mozilla.com> wrote:
>>
>>> Hi,
>>>
>>> We will be more active in 2017 and inform more about whats happening in
>>> Sheriffing and since its already March :)
>>>
>>> In February we had about 13242 changesets landed on mozilla-central
>>> monitored by Sheriffs.
>>>
>>> (The high number of changes is because of the merge from servo to
>>> mozilla-central with about 8315 changesets).
>>>
>>> 297 changesets were backed out in February.
>>>
>>> Beside this Sheriffs took park in doing uplifts and checkin-needed bugs.
>>>
>>> The Current Orangefactor is 10.43 (7250 test failures failures in 695
>>> pushes in the last 7 days).
>>> You can find the list of top Intermittent failure bugs here
>>> https://brasstacks.mozilla.com/orangefactor/
>>>
>>> You can find more statistics here: https://futurama.theautomatedt
>>> ester.co.uk/
>>>
>>> A big thanks to the Team especially our Community Sheriffs for handling
>>> the new Tier 2 Stylo Build on integration trees  and mozilla-central  and
>>> the teamwork with the Developers!
>>>
>>> If you want also to be a Community Sheriffs, as part of more blogging
>>> about Sheriffing i published a blog post about it :
>>> https://blog.mozilla.org/tomcat/2017/02/27/community-sheriffs/
>>>
>>> Let us know when you have any Question or Feedback about Sheriffing.
>>>
>>> Cheers,
>>>  -Tomcat
>>>
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Sheriff Highlights and Summary in February 2017

[Lawrence Mandel]

Hi Tomcat,

Do you have any more details about the reasons why the 297 changesets
needed to be backed out?

Thanks,

Lawrence

On Wed, Mar 1, 2017 at 6:05 AM, Carsten Book  wrote:

> Hi,
>
> We will be more active in 2017 and inform more about whats happening in
> Sheriffing and since its already March :)
>
> In February we had about 13242 changesets landed on mozilla-central
> monitored by Sheriffs.
>
> (The high number of changes is because of the merge from servo to
> mozilla-central with about 8315 changesets).
>
> 297 changesets were backed out in February.
>
> Beside this Sheriffs took park in doing uplifts and checkin-needed bugs.
>
> The Current Orangefactor is 10.43 (7250 test failures failures in 695
> pushes in the last 7 days).
> You can find the list of top Intermittent failure bugs here
> https://brasstacks.mozilla.com/orangefactor/
>
> You can find more statistics here: https://futurama.
> theautomatedtester.co.uk/
>
> A big thanks to the Team especially our Community Sheriffs for handling
> the new Tier 2 Stylo Build on integration trees  and mozilla-central  and
> the teamwork with the Developers!
>
> If you want also to be a Community Sheriffs, as part of more blogging
> about Sheriffing i published a blog post about it :
> https://blog.mozilla.org/tomcat/2017/02/27/community-sheriffs/
>
> Let us know when you have any Question or Feedback about Sheriffing.
>
> Cheers,
>  -Tomcat
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable service workers and push in 52 ESR

[Lawrence Mandel]

We disabled some features (iirc Hello and Pocket) in ESR45. The preference
is to keep ESR inline with what's in the mainline release but we're also
supporting ESR on a best effort basis. I think the rationale in this thread
for disabling service workers and push in ESR52 makes sense if we're not
going to be able to maintain these features and they don't yet have broad
adoption that is going to see a significant risk of web compat issues.

Lawrence

On Mon, Jan 23, 2017 at 3:07 PM, Eric Shepherd 
wrote:

> Any time something is disabled or removed from ESR, please be sure the
> developer docs team knows about it, because that’s something that has to be
> reflected in our documentation. I’m not aware of many (if any)
> documentation that says something exists in version X but not in ESR
> version X; that’s an inaccuracy we need to avoid and to fix where already
> present.
>
> > On Jan 18, 2017, at 10:49 AM, Ben Kelly  wrote:
> >
> > Hi all,
> >
> > I'd like to disable service workers in 52 ESR.  This would also require
> > disabling push notifications.
> >
> > A year ago we decided to disable service workers in 45 ESR because it was
> > very new and unstable:
> >
> > https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/
> VWXOa8N9AgAJ
> >
> > While things have stabilized since then we are in process of making a
> major
> > architectural change in order to support multiple content processes
> > (multi-e10s).  This will make it very difficult to uplift fixes.  Once
> the
> > new architecture has stabilized we should be able to enable SW in the
> next
> > ESR.
> >
> > Thoughts?
> >
> > Thanks.
> >
> > Ben
> > ___
> > 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: Reduction of intermittent failures for Marionette tests

[Lawrence Mandel]

Thank you for your focus on intermittent Marionette tests Henrik. Great
results!

Lawrence

On Wed, Nov 9, 2016 at 4:16 AM, Henrik Skupin  wrote:

> Hi all,
>
> Over the past months I tried to always have a look on newly filed
> intermittent failures for Marionette tests on Bugzilla. I tried to
> triage them early and to bring those up to interested parties. This was
> working great for a couple of scenarios like the massive amount of hangs
> and crashes for e10s tests. But I also did a lot of work myself to
> stabilize the tests by making sure we correctly handle:
>
> * The external process controlled by Marionette (tracking bug 1283906)
> * Chrome windows and tabs (bug 1259055)
>
> With the latest landing of the patch on bug 1299216 to improve the crash
> handling of Marionette, which also adds support for content crashes, I
> will mark this work as done.
>
> The results of all this work you can already see on integration
> branches. Marionette tests have a very low intermittent failure rate and
> fail only a handful of times over a day.
>
> I hope that we can keep that rate for a while now to make the sheriffs
> happy.
>
> --
> Henrik Skupin
> Senior Software Engineer
> Mozilla Corporation
> ___
> tools mailing list
> to...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/tools
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fwd: New Correlations on crash-stats

[Lawrence Mandel]

This is an amazing improvement to our ability to diagnose the cause of a
crash. Excellent work Marco!

Lawrence

On Fri, Nov 4, 2016 at 4:58 AM, Sylvestre Ledru  wrote:

> As we say in French, rendering to Caesar that which isCaesar's:
>
> Marco = Marco Castelluccio
>
> Sylvestre
>
>
>
> Le 04/11/2016 à 05:18, Nicholas Nethercote a écrit :
>
>> [Forwarding this to a wider audience because this is a big deal. Please
>> try out these correlations! They can be critical in diagnosing the cause of
>> a crash.]
>>
>>
>> -- Forwarded message --
>> From: Adrian Gaudebert >
>> Date: Fri, Nov 4, 2016 at 1:11 PM
>> Subject: New Correlations on crash-stats
>> To: stability owner 
>> >
>>
>> Dear crash-stats users,
>>
>> It is my pleasure to announce that we have just released Marco's new
>> correlations in Socorro! Head to a Signature report page <
>> https://crash-stats.mozilla.com/signature/?product=Firefox;
>> version=52.0a1=nsTArray_Impl%3CT%3E%3A%
>> 3AAppendElement%3CT%3E%20%7C%20mozilla%3A%3APreferences%3A%
>> 3AAddFloatVarCache=%3E%3D2016-10-28T02%3A07%3A12.000Z&
>> date=%3C2016-11-04T02%3A07%3A12.000Z&_columns=date&_colum
>> ns=product&_columns=version&_columns=build_id&_columns=
>> platform&_columns=reason&_columns=address&_sort=-date=1#correlations>
>> or a report index > om/report/index/fc657f26-f641-4c72-b7c9-72ec82161103#tab-correlation>
>> page to see them under the Correlations tab.
>>
>> Congratulations to Marco for his excellent work there!
>>
>> As usual, comments, feedback and bug reports are very welcome. :)
>>
>> Cheers,
>> Adrian
>>
>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
> ___
> 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: [Firefox Desktop] Issues found: October 3rd to October 7

[Lawrence Mandel]

Hi Amos,

Thank you for sharing the issue that you're having with Firefox. We'll need
a bug on file to flush out more details get traction on this. Have you
filed a bug already? If not, can you please do so?

https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=General

Lawrence

On Thu, Oct 13, 2016 at 3:32 PM, a e  wrote:

> Also, please add that hotmail is no longer posible to open (at least on my
> laptop) after an OS restore.  Work around, use IE to open Hotmail but
> should be fixed.
> Regards,
> Amos Eaton
> 
> From: firefox-dev [firefox-dev-boun...@mozilla.org] on behalf of Cornel
> Ionce [cornel.io...@softvisioninc.eu]
> Sent: Wednesday, October 12, 2016 3:16 AM
> To: firefox-qe-owner firefox-qe-owner; dev-platform@lists.mozilla.org;
> firefox-...@mozilla.org; fx-m...@mozilla.com; user-advoc...@mozilla.com
> Subject: Re: [Firefox Desktop] Issues found: October 3rd to October 7
>
> Oups, sent the wrong link/bug number for the cloudsovercuba issue. Updated
> the list with the correct one.
>
> On 10/10/2016 4:18 PM, Cornel Ionce wrote:
>
> Hi everyone,
>
> Here's the list of new issues found and filed by the Desktop Release QA
> Team last week, October 3 - October 7 (week 40).
>
> Additional details on the team's priorities last week, as well as the
> plans for the current week are available at:
>
> https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus
>
> RELEASE CHANNEL
> none
>
> BETA CHANNEL
> ID  Summary Product Component   Is a regression Assigned to
> 1308189
> No badge is displayed over the Downloads button if this is placed
> in the Menu Panel
> Firefox Downloads Panel YES<
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=
> 68a682ef9e59eabb5d0f1fda05e84a773ca8340b=
> 7f2f44eaea09c02079d8f1a0be777cd39776712e>   NOBODY
> 1308232
> When the Downloads button is in the Bookmarks Toolbar, the badges
> located over it are cut off
> Firefox Downloads Panel TBD NOBODY
> 1308237
> When the Downloads button is in the Menu Bar or Menu Panel, the
> badges located over it are cut off
> Firefox Downloads Panel TBD NOBODY
> 1308418
> Videos are not working on 32bit MacOS mode
> CoreAudio/Video: Playback   YES mozilla-central/pushloghtml?fromchange=2ea3d51ba1bb9f5c3b6921c43ea63f
> 70b4fdf5d2=e5859dfe0bcbd40f4e33f4a633f73ea3473a7849>   NOBODY
> 1308471
> Crash in CopyRow_AVX
> CoreWebRTC  NO  NOBODY
>
>
> AURORA CHANNEL
> ID  Summary Product Component   Is a regression Assigned to
> 1308462  Firefox is unable to load
> http://cloudsovercuba.com/Core
> JavaScript Engine
> YES 0a3b6e2df6567d845f31c000c68dd67816c6153d=
> c567db06882e3a2e3396b6a16449522d149c7146>   NOBODY
>
>
> NIGHTLY CHANNEL
> none
>
> ESR CHANNEL
> none
>
> Regards,
> Cornel Ionce
> Team Lead
> SOFTVISION
>
> The content of this communication is classified as SOFTVISION Confidential
> and Proprietary Information.
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed change to Commit Access Policy Level 3

[Lawrence Mandel]

+1  Good change.

Lawrence

On Wednesday, 3 August 2016, Mitchell Baker  wrote:

> Over time we've made a series of exceptions to the level 3 requirements
> for Sheriffs and this proposal addresses that.
>
>
> The current Policy for level 3 is:
>
> Level 3 - Core Product Access
>
> Requirements: two vouchers - module owners or peers of code stored
> at this level
>
>
> The issue is that Sheriffs typically need level 3 access to fulfill their
> roles.  But they aren't chosen based on number and quality of patches, so
> often don't meet the current requirements.  Today we go through an
> exception process.  The thinking is that this process is unneeded for a set
> of people to whom we've delegated Sheriff authority.
>
>
> The proposal is to change the text as follows:
>
> from:"module owners or peers of code stored at this level"
> to:  "module owners or peers of code stored at this level or owners or
> peers of the 'Tree Sheriffs' module."
>
>
>
> Mitchell
> ___
> 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: Checkin-needed requests - Please include complete information in the commit message :)

[Lawrence Mandel]

Autoland is not yet optimal but the team continues to work on it. Long term
I think we want as much of our load to go through autoland as possible so
that we can apply a consistent approach to how code is integrated into the
tree. I would encourage you to use autoland. Tryserver wait times should be
significantly lower now. If try wait times increase (and we're watching),
we will deal with it.

Lawrence

On Mon, Jul 11, 2016 at 2:09 PM, Jared Wein  wrote:

> Do we need autoland to land each patch independently? If I have three
> disparate patches that I can land right now, should I use mozreview to land
> them and use 3x the infra or use checkin-needed and their checkin will
> likely be coalesced?
>
> This is the position that I face often and is why I choose to use
> checkin-needed. Along with jesup, I've waited hours for tryserver results
> in the past and I want to be a "good citizen" and not increase infra
> demands.
>
> Am I in the wrong here? Ideally autoland would have some heuristic for
> coalescing requests so we can be polite to the build system and the people
> waiting on it.
>
> On Mon, Jul 11, 2016 at 1:57 PM, Andrew McCreight 
> wrote:
>
> > On Sun, Jul 10, 2016 at 7:29 PM, Martin Thomson  wrote:
> >
> > > Is now the right time to start talking about retiring checkin-needed,
> > > or is it still heavily used?
> > >
> >
> > It is useful for anybody who doesn't use MozReview. FWIW I see 14 bugs
> with
> > it set right now.
> >
> >
> >
> >
> >
> >
> > >
> > > On Sat, Jul 9, 2016 at 4:58 AM, Gregory Szorc  wrote:
> > > > On Fri, Jul 8, 2016 at 11:39 AM, Felipe G  wrote:
> > > >
> > > >> Is there a way to make the checkin-needed flag generate a template
> > > comment
> > > >> (like the approval-* ones do) with something like this? (Or
> encourage
> > > >> people to use the per-patch checkin? flag)
> > > >>
> > > >> """
> > > >> Has this patch been through try? [ Yes / No, I believe it's not
> > > necessary ]
> > > >> Does this patch contain the correct author / commit message? [ Yes
> > > >> (preferred) / No, but I'm providing it here: ]
> > > >> Are there any other dependencies that should be landed together? [
> > Yes,
> > > ...
> > > >> / No ]
> > > >> """
> > > >>
> > > >> Probably just asking if the information is present will reduce the
> > > number
> > > >> of requests made without it
> > > >>
> > > >
> > > > My knee jerk reaction is we shouldn't bother: MozReview handles most
> of
> > > > this "validation" and usage of MozReview has been steadily
> increasing.
> > > > We're trending towards a world where the only patches on Splinter are
> > for
> > > > security-sensitive bugs (MozReview can't handle those yet) and the
> > people
> > > > submitting patches to security bugs tend to know what they're doing
> so
> > I
> > > > don't think these added checks will help.
> > > >
> > > >
> > > >>
> > > >> On Fri, Jul 8, 2016 at 10:47 AM, Ryan VanderMeulen <
> rya...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > FWIW, there's also an MDN page that documents a lot of this as
> well:
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
> > > >> >
> > > >> > -Ryan
> > > >> >
> > > >> >
> > > >> > On 7/8/2016 2:32 AM, Carsten Book wrote:
> > > >> >
> > > >> >> Hi,
> > > >> >>
> > > >> >> someone might not know that doing checkins for checkin-needed
> > > request is
> > > >> >> not automated yet and completely a fully human task :) (no we
> > > Sheriffs
> > > >> are
> > > >> >> not bots ;)
> > > >> >>
> > > >> >> It would help us a lot if a checkin needed request would contain
> > > >> complete
> > > >> >> Author/Patch information like:
> > > >> >>
> > > >> >>
> > > >> >>- Author (use the information from their Bugzilla account if
> > > needed)
> > > >> >>with Name *and *Emailadress.
> > > >> >>- Bug number
> > > >> >>- Commit message (keeping in mind that the commit message
> should
> > > be a
> > > >> >>brief description of what the patch is *doing*)
> > > >> >>   - Format should be something like "Bug 123456 - Add a null
> > > check
> > > >> to
> > > >> >>   XYZ to avoid a crash. r=somebody"
> > > >> >>
> > > >> >>
> > > >> >> And also if there is a specific sequence/dependency you want to
> > > checkin
> > > >> >> the
> > > >> >> patches it would help also a lot  if you could make a short
> comment
> > > in
> > > >> the
> > > >> >> Bug like please checkin part x then patch y or like first bug 123
> > > then
> > > >> >> this
> > > >> >> bug and then bug 8910.
> > > >> >>
> > > >> >> This would help us a lot :)
> > > >> >>
> > > >> >> Thanks!
> > > >> >>
> > > >> >> - Tomcat
> > > >> >>
> > > >> >>
> > > >> > ___
> > > >> > dev-platform mailing list
> > > >> > dev-platform@lists.mozilla.org
> > > >> > 

Re: MXR permanently offline, please transition to DXR

[Lawrence Mandel]

I filed bug 1285657 to rewrite MXR links in Bugzilla to DXR. Are there
other sites (MDN) that have a lot of links that we should look to rewrite?

Lawrence

On Fri, Jul 8, 2016 at 3:49 PM, Gijs Kruitbosch <gijskruitbo...@gmail.com>
wrote:

> The problem is that if you're on a bmo page with these "perma"links,
> really the ideal case is that they are indeed permalinks and continue to
> work, especially where they point to specific lines in specific revisions.
> The interstitial just makes it harder for people to get to that info. A 404
> on a working DXR, if the file has really disappeared or something, is still
> better than the 'hard hat' page from which the path to the data you want is
> much longer.
>
> In case this is useful for folks: I wrote a webextension that rewrites
> these links and that obeys the "rev" and "mark" query params from MXR links
> and rewrites them to the equivalent DXR URL syntax:
> https://addons.mozilla.org/en-US/firefox/addon/mxr-to-dxr-webextension/ .
>
> ~ Gijs
>
>
> On 08/07/2016 20:27, Lawrence Mandel wrote:
>
> We do in the case of 3rd party software referencing files from MXR (and
> I'm told there is a lot of this). We also can't guarantee that MXR URLs
> will direct to the right place in DXR. There is likely a balance to be
> struck here with highly referenced files from 3rd party software getting an
> interstitial page and other files not getting the page. Let's start with
> getting the page with the redirect in place and then iterate from there as
> required.
>
> Lawrence
>
> On Fri, Jul 8, 2016 at 3:24 PM, Bobby Holley < <bobbyhol...@gmail.com>
> bobbyhol...@gmail.com> wrote:
>
>> Can we skip the interstitial page and make the notice (if any) more
>> unobtrusive somehow? There are tons of mxr links all over the place, and
>> many of them are immutable. We don't gain anything by informing the viewer
>> about their obsolescence instead of showing them the content they want.
>>
>> On Fri, Jul 8, 2016 at 12:20 PM, Lawrence Mandel < <lman...@mozilla.com>
>> lman...@mozilla.com> wrote:
>>
>>> dev-platform was not included on my response below. Looping back in to
>>> this
>>> fork of the thread.
>>>
>>> On Fri, Jul 8, 2016 at 10:55 AM, Lawrence Mandel <lman...@mozilla.com>
>>> wrote:
>>>
>>> > Sorry Dao. I have seen some responses. Maybe they were off list. We're
>>> > working on details now. I'm going to get someone to put the redirects
>>> in
>>> > place, likely with an interstitial page advising that MXR has been
>>> > decommissioned, by next week.
>>> >
>>> > Lawrence
>>> >
>>> >
>>> > On Friday, 8 July 2016, Dão Gottwald <dgottw...@mozilla.com> wrote:
>>> >
>>> >> Why has nobody responded to the requests for a short-term fix for MXR
>>> >> URLs for more than a week? Are the people responsible for MXR not in
>>> this
>>> >> list?
>>> >>
>>> >> 2016-07-07 18:23 GMT+02:00 Eric Shepherd <esheph...@mozilla.com>:
>>> >>
>>> >>> We have tons of mxr links all through MDN, fwiw. I am updating the
>>> >>> macros that generate them, but odds are very good these links will be
>>> >>> around for a good while.
>>> >>>
>>> >>>
>>> >>> That would be perfectly fine for my purposes, I expect, as long as it
>>> >>> dealt with the relevant mxr features.  What I want is for links to
>>> possibly
>>> >>> specific lines of possibly specific revisions of specific files to
>>> work.
>>> >>> Ideally with the highlighting bits too.
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> Eric Shepherd
>>> >>> Senior Technical Writer
>>> >>> Mozilla Developer Network < <https://developer.mozilla.org/>
>>> https://developer.mozilla.org/>
>>> >>> Blog: <https://www.bitstampede.com/>https://www.bitstampede.com/
>>> >>> Twitter: <http://twitter.com/sheppy>http://twitter.com/sheppy
>>> >>> Doodle: <http://doodle.com/the.sheppy>http://doodle.com/the.sheppy
>>> >>>
>>> >>>
>>> >>> ___
>>> >>> firefox-dev mailing list
>>> >>> firefox-...@mozilla.org
>>> >>> https://mail.mozilla.org/listinfo/firefox-dev
>>> >>>
>>> >>>
>>> >>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
>
> ___
> firefox-dev mailing 
> listfirefox-dev@mozilla.orghttps://mail.mozilla.org/listinfo/firefox-dev
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Lawrence Mandel]

We do in the case of 3rd party software referencing files from MXR (and I'm
told there is a lot of this). We also can't guarantee that MXR URLs will
direct to the right place in DXR. There is likely a balance to be struck
here with highly referenced files from 3rd party software getting an
interstitial page and other files not getting the page. Let's start with
getting the page with the redirect in place and then iterate from there as
required.

Lawrence

On Fri, Jul 8, 2016 at 3:24 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:

> Can we skip the interstitial page and make the notice (if any) more
> unobtrusive somehow? There are tons of mxr links all over the place, and
> many of them are immutable. We don't gain anything by informing the viewer
> about their obsolescence instead of showing them the content they want.
>
> On Fri, Jul 8, 2016 at 12:20 PM, Lawrence Mandel <lman...@mozilla.com>
> wrote:
>
>> dev-platform was not included on my response below. Looping back in to
>> this
>> fork of the thread.
>>
>> On Fri, Jul 8, 2016 at 10:55 AM, Lawrence Mandel <lman...@mozilla.com>
>> wrote:
>>
>> > Sorry Dao. I have seen some responses. Maybe they were off list. We're
>> > working on details now. I'm going to get someone to put the redirects in
>> > place, likely with an interstitial page advising that MXR has been
>> > decommissioned, by next week.
>> >
>> > Lawrence
>> >
>> >
>> > On Friday, 8 July 2016, Dão Gottwald <dgottw...@mozilla.com> wrote:
>> >
>> >> Why has nobody responded to the requests for a short-term fix for MXR
>> >> URLs for more than a week? Are the people responsible for MXR not in
>> this
>> >> list?
>> >>
>> >> 2016-07-07 18:23 GMT+02:00 Eric Shepherd <esheph...@mozilla.com>:
>> >>
>> >>> We have tons of mxr links all through MDN, fwiw. I am updating the
>> >>> macros that generate them, but odds are very good these links will be
>> >>> around for a good while.
>> >>>
>> >>>
>> >>> That would be perfectly fine for my purposes, I expect, as long as it
>> >>> dealt with the relevant mxr features.  What I want is for links to
>> possibly
>> >>> specific lines of possibly specific revisions of specific files to
>> work.
>> >>> Ideally with the highlighting bits too.
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Eric Shepherd
>> >>> Senior Technical Writer
>> >>> Mozilla Developer Network <https://developer.mozilla.org/>
>> >>> Blog: https://www.bitstampede.com/
>> >>> Twitter: http://twitter.com/sheppy
>> >>> Doodle: http://doodle.com/the.sheppy
>> >>>
>> >>>
>> >>> ___
>> >>> firefox-dev mailing list
>> >>> firefox-...@mozilla.org
>> >>> https://mail.mozilla.org/listinfo/firefox-dev
>> >>>
>> >>>
>> >>
>> ___
>> 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: MXR permanently offline, please transition to DXR

[Lawrence Mandel]

dev-platform was not included on my response below. Looping back in to this
fork of the thread.

On Fri, Jul 8, 2016 at 10:55 AM, Lawrence Mandel <lman...@mozilla.com>
wrote:

> Sorry Dao. I have seen some responses. Maybe they were off list. We're
> working on details now. I'm going to get someone to put the redirects in
> place, likely with an interstitial page advising that MXR has been
> decommissioned, by next week.
>
> Lawrence
>
>
> On Friday, 8 July 2016, Dão Gottwald <dgottw...@mozilla.com> wrote:
>
>> Why has nobody responded to the requests for a short-term fix for MXR
>> URLs for more than a week? Are the people responsible for MXR not in this
>> list?
>>
>> 2016-07-07 18:23 GMT+02:00 Eric Shepherd <esheph...@mozilla.com>:
>>
>>> We have tons of mxr links all through MDN, fwiw. I am updating the
>>> macros that generate them, but odds are very good these links will be
>>> around for a good while.
>>>
>>>
>>> That would be perfectly fine for my purposes, I expect, as long as it
>>> dealt with the relevant mxr features.  What I want is for links to possibly
>>> specific lines of possibly specific revisions of specific files to work.
>>> Ideally with the highlighting bits too.
>>>
>>>
>>> --
>>>
>>> Eric Shepherd
>>> Senior Technical Writer
>>> Mozilla Developer Network <https://developer.mozilla.org/>
>>> Blog: https://www.bitstampede.com/
>>> Twitter: http://twitter.com/sheppy
>>> Doodle: http://doodle.com/the.sheppy
>>>
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Lawrence Mandel]

On Tue, Jul 5, 2016 at 6:58 PM, Ralph Giles  wrote:

> On Tue, Jul 5, 2016 at 3:36 PM, Gregory Szorc  wrote:
>
> > * `mach build binaries` (touch network/dns/DNS.cpp): 14.1s
>
> 24s here. So faster link times and significantly faster clobber times. I'm
> sold!
>
> Any motherboard recommendations? If we want developers to use machines
> like this, maintaining a current config in ServiceNow would probably
> help.
>

Completely agree. You should not have to figure this out for yourself. We
should provide good recommendations in ServiceNow. I'm looking into
updating the ServiceNow listings with gps.

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

MXR permanently offline, please transition to DXR

[Lawrence Mandel]

Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was
taken offline on June 13, 2016, to investigate a potential security issue.
After careful review of the codebase, we have decided to accelerate the
planned transition from MXR to its more modern equivalent, DXR (
https://dxr.mozilla.org), instead of bringing MXR back online. As far as we
know there was never a security compromise, but the unsupported legacy
codebase (forked from an old version of LXR) would require significant time
and effort to rewrite and bring up to spec.

Our transition plan is as follows:


   -

   Add an interstitial web page at https://mxr.mozilla.org that displays a
   best-guess URL for the equivalent https://dxr.mozilla.org file data.
   This will help interactive users retrieve data from historical links in
   applications like Bugzilla.
   -

   Redirect certdata.txt and effective_tld_names.dat to their canonical
   source code repositories instead of DXR. All other search queries and
   automatic pulling of raw files by third parties will no longer be supported
   at the https://mxr.mozilla.org URL.
   -

   Index the remaining repos listed in MXR in DXR for data parity, using
   bug 1281443 to track progress. Repos will be indexed in the order listed
   unless otherwise specified. If you need to prioritize the indexing of
   specific repos, please open a bug and block against bug 1281443.


Our expectation is that the interstitial page will be in place and the
following remaining high-priority repos will be indexed by June 24th, 2016:

   -

   add-ons
   -

   servo
   -

   l10n


If you have concerns, questions, or requests, please open a new bug and
mark it as blocking bug 1281443 or add a comment to one of its existing
dependent bugs. Additional status updates will also be posted to bug
1281443 and its dependent bugs.

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

Re: Top crash list is odd right now

[Lawrence Mandel]

Is the plan to prompt on release as well?

On Fri, Jun 3, 2016 at 11:33 AM, Andrew McCreight 
wrote:

> blassey landed a patch to suggest that users submit unsubmitted crash
> reports. This is going to make various kinds of crashes, like shutdown
> crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
> You probably want to use "By build date" instead of the default "By report
> date" for the next week or so until that settles out.
>
> Presumably the same thing will happen the first week or two of Aurora, on
> that channel, and likewise with beta.
> ___
> 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: 32-bit developer edition?

[Lawrence Mandel]

+ Javaun who should be able to fill in details about timing and what we
want to do with Win64 and why

On Fri, Jun 3, 2016 at 8:51 AM, Ben Kelly  wrote:

> On Jun 3, 2016 2:15 AM, "Jet Villegas"  wrote:
> >
> > We should offer both.
>
> If we get a net reduction in OOMs with 64-bit it seems to me we should make
> that the default download link.
>
> In any case, we're not showing a 64-bit link anywhere now.  Who should I
> pester or where should I file a bug to get that fixed?
>
> Thanks.
>
> Ben
> ___
> 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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Lawrence Mandel]

We do have contacts. The more information we pass along about this crash
including how to avoid crashing if we know the better our chances of
success. What would you recommend that we tell IBM Rapport?

Sylvestre - Can you please pass along information about the crash?

Thanks,

Lawrence

On Tue, May 31, 2016 at 9:27 AM, Gijs Kruitbosch 
wrote:

> On 31/05/2016 07:22, Nicholas Nethercote wrote:
>
>> 10 MOZ_CRASH(Using observer service off the main thread!)  223 0.02 %
>>
>
> This looked interesting to me, but it seems almost all of them are caused
> by IBM Rapport which hooks into the process and calls the observer service
> off-main-thread. If someone has contacts there, I guess we could tell them
> not to do that? :-\
>
>
> ~ Gijs
> ___
> 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: All about crashes

[Lawrence Mandel]

> > "Improve reproducibility of these crashes.
> >
> > Use rr to record crashes so they can be played back reliably."
> >
> > We're going to spin up a project to work on debugging in automation.
> We've
> > talked about having the ability to run a test until it fails and pause at
> > that point. I think that would be very helpful for this case.
>
> Is this something that would happen for normal test jobs? Would there
> be a way to attach a debugger to the paused job? Is it aimed at
> reducing intermittent test failures?
>
> It sounds interesting but how it works it a bit unclear to me from
> your short description :)
>

The aim is to make it much easier to handle intermittent test failures.
Crashes may be possible as well.

The project is not yet well defined. Jonathan Griffin is working on this
with his team with the intention of getting started in Q3.

One option that we've discussed is to select a test or suite to run in
debug mode (with a debugger attached). We can then rerun the test in
automation until it fails, pause with the debugger attached at that point,
and notify a dev that there is a machine waiting for him in this state.

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

Re: All about crashes

[Lawrence Mandel]

Hi Nick,

Wasn't sure how you wanted feedback. Here's some in email form.

"Crashes are caused by defects"

Reading this I think it implies defects in Firefox. This is not always the
case. Crashes are also the result of interactions with third party
software. Both that that we designed for (like NPAPI plug-ins) and that we
didn't (AV, malware), which you mention lower down in the doc.



"Improve ranking of crash clusters."

I think this is weighting or estimating impact of a crash instead of volume
of submissions, which is how we have historically processed the clusters.
Severity is one component with startup crashes being worse than content
crashes being worse than shutdown crashes. (Need to figure out weighting of
gfx and other buckets of crashes.) Potential impacted population is another
and we have data on the differences in population size on Beta vs Release
for dimensions like OS version, gfx hardware, and gfx driver to make use of
for the weighting.



"Improve reproducibility of these crashes.

   - Use rr to record crashes so they can be played back reliably."

We're going to spin up a project to work on debugging in automation. We've
talked about having the ability to run a test until it fails and pause at
that point. I think that would be very helpful for this case.



I didn't see a lot on mitigation strategies but I think those this is key
piece as well. We will get some mitigation when e10s ships and content
crashes no longer take down the whole browser. We've discussed mitigations
for startup crashes (and implemented one for gfx). What other mitigations
should we put in place to recover gracefully?

Thanks for putting this together!

Lawrence



On Tue, May 24, 2016 at 12:56 AM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:

> Greetings,
>
> I've written a document called "All about crashes" which I've put on
> the Project Uptime wiki:
>
> https://wiki.mozilla.org/Platform/Uptime#All_about_crashes
>
> It's about all the different ways we can discover, diagnose, and
> address crashes. It's intended to be a comprehensive, because I want
> to use it to help identify and prioritise all the ways we could do
> better.
>
> I would appreciate any feedback people might have. I'm sure I have
> gotten some things wrong, and omitted some things. Thanks in advance.
>
> Nick
> ___
> 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

Two Factor Authentication and Github

[Lawrence Mandel]

You can ignore this email if you are not a member of the GitHub Mozilla
organization.

Starting on June 20th, the GitHub Mozilla organization will require Two
Factor Authentication (2FA). We’re implementing 2FA for security reasons --
 if you lose or have your password stolen, 2FA provides an extra layer of
defense to prevent your account from being compromised. This change has
already been rolled out for Admins, and is now being extended for all
members.

You can learn more about GitHub and 2FA at
https://help.github.com/articles/about-two-factor-authentication/

Please see https://wiki.mozilla.org/Github for more information about using
GitHub at Mozilla, or find us on #github on irc.mozilla.org.

Thanks,

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Lawrence Mandel]

On Fri, May 20, 2016 at 11:27 AM, Nathan Froyd  wrote:

> On Fri, May 20, 2016 at 11:18 AM, Armen Zambrano G. 
> wrote:
> > On 2016-05-19 08:29 PM, Mike Hommey wrote:
> >> It's also not possible to *trigger* new TC jobs on treeherder ; like,
> >> pushing with no try syntax and filling what you want with "Add new
> >> jobs". Or using "Add new job" after realizing you forgot a job in your
> >> try syntax.
> >
> > martianwars is working on it:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1254325
> >
> > I believe we should have it by the end of June.
>
> Why are we moving to a new system when it's lacking user-facing
> functionality that the old system had (T pushes on try comes to mind
> also, but I believe that's been fixed...perhaps there are others,
> too)?  I can believe taskcluster-based jobs bring a whole host of
> benefits (having things in-tree seems fantastic, for one), but it's
> hard to understand the enthusiasm for pushing forward when we have
> useful features disappearing.
>
>
There will be some pain with this port and we're going to break some things
unintentionally and possibly some thing intentionally. I apologize for the
inconvenience, promise that we'll do our best to keep the irritations to a
minimum, and ask for your help in flagging issues that come up so that we
can get the system into a good state.

Thank you to everyone who has already provided feedback in this thread.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

Yes. The intention was 48.0. Given that that doesn't actually buy us
anything at this point, dropping support in 49.0 is fine.

Lawrence

On Fri, May 13, 2016 at 3:24 PM, Ben Hearsum <bhear...@mozilla.com> wrote:

> Thanks for clarifying. It seems like the confusion came from the fact that
> we had *intended* to drop support in 48.0, but it hadn't happened yet. And
> now we don't *intend* to drop support until 49.0?
>
> On 2016-05-13 02:55 PM, Benjamin Smedberg wrote:
>
>> Right now the code to disable 10.6 has landed only on nightly/49, and
>> other
>> bits are still blocked (see bug 1270217) because our MacOS builders (not
>> the testers) are still running MacOS 10.7. As of this point, I expect that
>> Firefox 48 will still run on 10.6-10.8 and the first release to drop
>> support will be Fx49.
>>
>> If anyone wants to follow along, the tracking bug for the various pieces
>> of
>> client, updater, website, and SUMO changes are being tracked in bug
>> 1255589.
>>
>> --BDS
>>
>>
>> On Fri, May 13, 2016 at 2:15 PM, Nils Ohlmeier <nohlme...@mozilla.com>
>> wrote:
>>
>>
>>> On May 10, 2016, at 19:58, Lawrence Mandel <lman...@mozilla.com> wrote:
>>>>
>>>> The post states "Mozilla will end support for Firefox on OS X 10.6,
>>>> 10.7,
>>>> and 10.8 in August, 2016." This means that we will end support with the
>>>> Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.
>>>>
>>>
>>> Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates
>>> to
>>> DevEd 48?
>>>
>>> I just tested it on a 10.6 machine and updates have stopped for Nightly.
>>> Which is good, because the Nightly 49 build which I manually downloaded
>>> crashes and brings up the Mac OS X crash reporter.
>>> But the DevEdition installed on the same system updated itself to 48. And
>>> 48 started and appeared to be still working.
>>>
>>> Best
>>>Nils Ohlmeier
>>>
>>> ___
>>> 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: Updating 32-bit Windows users to 64-bit Windows builds?

[Lawrence Mandel]

Do we need this criteria?

RAM - Does it hurt to move an instance that has <4GB?
NPAPI - We've announced that we'll remove support this year [1]. Should we
just wait until we do? Do we have a solution for Flash on Win64 that makes
this viable?

Lawrence

[1]
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

On Thu, May 12, 2016 at 3:12 PM, Ben Hearsum  wrote:

> This is a slight change from the current model where we purposely make the
> client very dumb, and make the decision on the server (to minimize the
> possibility of client-side bug making updates impossible). However, this
> doesn't seem like a case where we could get somebody stuck very easily, and
> I don't see a practical way of making the decision on the server if it
> requires this much information.
>
> On 2016-05-12 01:07 PM, Ted Mielczarek wrote:
>
>> I suspect we'd want to add some extra token like "it's ok to update this
>> 32-bit build to a 64-bit build", and have all the gating logic live on
>> the client-side. Odds are if we want to change the criteria we'd have to
>> change the client anyway.
>>
>> -Ted
>>
>> On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wrote:
>>
>>> Do you have thoughts on how we'll be able to serve the users the correct
>>> build if we have to base the decision on plugins they may have or other
>>> information that's not in the update ping? We can already detect 32-bit
>>> builds on 64-bit Windows through the build target, but information about
>>> plugins or RAM is not something we know about when serving updates.
>>>
>>> On 2016-05-12 11:45 AM, Ted Mielczarek wrote:
>>>
 Hello,

 Given all the discussion around SSE[2] lately, I was curious as to
 whether we had made any plans to update Windows users that are running
 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows
 builds. The 64-bit Windows builds do use SSE2, since that's a baseline
 requirement for x86-64 processors, and the overall performance should
 generally be better (modulo memory usage, I'm not sure if we have an
 exact comparison). Additionally 64-bit builds are much less likely to
 encounter OOM crashes due to address space fragmentation since they have
 a very large address space compared to the maximum 4GB available to the
 32-bit builds.

 It does seem like we'd need some minimal checking here, obviously first
 for whether the user is running 64-bit Windows, but also possibly
 whether they use 32-bit plugins (until such time as we unsupport NPAPI).
 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
 the equivalent of Universal binaries like we do on OS X).

 -Ted


>>> ___
>>> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Fri, May 6, 2016 at 6:43 AM, Xidorn Quan  wrote:

> On Fri, May 6, 2016 at 8:24 PM, Mike Hommey  wrote:
>
> > On Fri, May 06, 2016 at 06:01:12PM +1000, Xidorn Quan wrote:
> > >
> > > It's Firefox 48, three versions after ESR 45, which is roughly halfway
> > > before the next ESR.
> >
> > 48 is the first version that will *not* have 10.6-10.8 support.
>
>
> On Mon, May 2, 2016 at 2:28 PM, Ralph Giles  wrote:
> > The blog post just says "August 2016". Firefox 48 is scheduled for
> > release August 2. Can you confirm that means we can start removing
> > 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
>
> This post reads to me that we start dropping 10.6~10.8 since Firefox 49, so
> Firefox 48 should be the last one with that support. Am I missing something
> here?
>

The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7,
and 10.8 in August, 2016." This means that we will end support with the
Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.

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

Re: Reverting to VS2013 on central and aurora

[Lawrence Mandel]

On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg 
wrote:

> I agree that we should drop support for non-SSE2. It mattered 7 years ago
> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
> doesn't matter now.
>
> We do need to avoid updating these users to a build that will crash, and do
> the same "unsupported" messaging we're doing for old versions of MacOS.
> Gregory, will you own that? You will probably need to add CPU feature
> detection to the update URL/params for 47, or use some kind of system addon
> to shunt these users off the main update path.
>

Benjamin - We're likely going to want to do this again in the future. Not
that Greg isn't capable but is there someone more familiar with the update
system who can step in to get this done?

Lawrence


>
> --BDS
>
>
> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye  wrote:
>
> > On 2016-05-06 12:26 AM, Gregory Szorc wrote:
> >
> >> FWIW, the crashes we've seen so far are from incorrectly emitted movss
> >> instructions. This instruction is part of the original SSE instruction
> >> set,
> >> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
> >> by
> >> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
> >> need
> >> Firefox to run on processors manufactured in the 90s.
> >>
> > Per an IRC conversation with chutten, Firefox users on CPUs that do not
> > support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2).
> A
> > third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> > etc), this work provides continuity of support to 0.01% of our users.
> >
> > - mhoye
> >
> >
> > 09:59  So, to put it clearly and precisely, of the Firefox
> > Population in release and beta who are reporting at least base telemetry
> > collection on machines running supported configurations, only 0.01%
> cannot
> > definitively say they have SSE.
> > 10:00  (according to a 1% random sample as stored in the
> > longitudinal dataset)
> >
> > ___
> > 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: Reverting to VS2013 on central and aurora

[Lawrence Mandel]

On Tue, May 10, 2016 at 7:29 PM, Xidorn Quan  wrote:

> On Wed, May 11, 2016 at 6:45 AM, Gregory Szorc  wrote:
>
> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc  wrote:
> >
> > > There is a compiler bug in VS2015 that results in SSE instructions
> being
> > > emitted when they shouldn't be. Since Firefox still needs to remain
> > > compatible with ancient hardware that doesn't support SSE, this is
> > causing
> > > crashes on Firefox built with VS2015 (see bug 1265615).
> > >
> > > The good news is glandium found a pretty minimal reproduce case and
> > > reported the bug to Microsoft.
> > >
> > > The bad news is the issue still reproduces in the latest pre-release
> > > version of the Visual C++ toolchain.
> > >
> > > The worse news is we'll have to revert to building Firefox 48 (current
> > > Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> > > track. Aurora will likely land soon. Central might take a few days, as
> I
> > > believe VS2013 is a bit broken on central at the moment.
> > >
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
> >
> > But we need to teach the updater to advertise CPU features in the Firefox
> > version before we drop SSE so we don't update users to a binary that
> won't
> > work. Since Firefox 48/Aurora is currently using VS2015, that would mean
> > teaching Firefox 47/Beta new tricks. Since we're already in the middle of
> > the Beta cycle and there is no major user benefit to shipping VS2015
> builds
> > at this time, we're going to revert to VS2013 on Firefox 48/Aurora and
> > build the updater support into Firefox 48/Aurora. Firefox 49/Nightly will
> > continue to build with VS2015 and will be the first Firefox version to
> > require SSE.
> >
> > Bug 1271755 is our tracker for requiring SSE to run Firefox.
> >
>
> As we are dropping another set of users in Firefox 48 in addition to OS X
> 10.6~10.8, could we reconsider making Firefox 48 a half-ESR as I proposed
> in [1]?
>
> [1]
>
> https://groups.google.com/d/msg/mozilla.dev.platform/gXZj0rQWEfI/RIeuLYTvAAAJ


What you're suggesting is to continue providing support for these platforms
for a longer period of time. The intention is to stop supporting these
platforms. We have already made the decision (and in the case of OSX
announced it). I don't think we have good cause to change this decision at
this point.

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

Re: Reverting to VS2013 on central and aurora

[Lawrence Mandel]

On Tue, May 10, 2016 at 7:05 PM, Ehsan Akhgari 
wrote:

> On 2016-05-10 4:45 PM, Gregory Szorc wrote:
> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc  wrote:
> >
> >> There is a compiler bug in VS2015 that results in SSE instructions being
> >> emitted when they shouldn't be. Since Firefox still needs to remain
> >> compatible with ancient hardware that doesn't support SSE, this is
> causing
> >> crashes on Firefox built with VS2015 (see bug 1265615).
> >>
> >> The good news is glandium found a pretty minimal reproduce case and
> >> reported the bug to Microsoft.
> >>
> >> The bad news is the issue still reproduces in the latest pre-release
> >> version of the Visual C++ toolchain.
> >>
> >> The worse news is we'll have to revert to building Firefox 48 (current
> >> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> >> track. Aurora will likely land soon. Central might take a few days, as I
> >> believe VS2013 is a bit broken on central at the moment.
> >>
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
>
> Firstly, great to hear this!
>
> But since the topic of when to drop support for legacy platforms seems
> to be coming up a few times per week these days, it would be helpful to
> document somewhere how the decision to drop support for processors not
> supporting SSE was reached.  Do we have data covering what number of
> users will be affected by this change?  Do we have guidelines on what's
> the threshold for supporting other similar legacy configs?
>
> It would be helpful to see some information about this shared here.
>
> I don't know how this specific decision was reached but I did speak with
Chris Cooper and Peter Dolanjski about developing criteria/guidelines for
support today. I don't expect us to have something this month but we will
flesh this out as part of the ongoing conversation about platform support.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Tue, May 3, 2016 at 11:11 PM, Xidorn Quan <quanxunz...@gmail.com> wrote:

> On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel <lman...@mozilla.com>
> wrote:
>
>> On Tue, May 3, 2016 at 6:56 PM, Mike Hommey <m...@glandium.org> wrote:
>>
>> > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote:
>> > > On 5/3/16 4:59 PM, Justin Dolske wrote:
>> > > > On 5/3/16 12:21 PM, Gregory Szorc wrote:
>> > > >
>> > > > > * The update server has been reconfigured to not serve Nightly
>> > > > > updates to
>> > > > > 10.6-10.8 (bug 1269811)
>> > > >
>> > > > Are we going to be showing some kind of notice to affected users
>> upon
>> > > > Release? That is, if I'm a 10.6 user and I update to Firefox 48, at
>> > some
>> > > > point should I see a message saying I'll no longer receive future
>> > > > updates?
>> > >
>> > > Even better, is there any way to get the update system to
>> automatically
>> > move
>> > > such users over to 45ESR?
>> >
>> > Did we introduce changes to profile data between 45 and 48? Because
>> > that usually breaks downgrade paths.
>> >
>>
>> We discussed this earlier and decided that we were not going to
>> automatically move users from Firefox to ESR. For one thing, the user has
>> not opted to be on this channel. A channel change also involves both
>> engineering and test work. It does seem prudent to test the scenario to
>> know whether users can move from 47 to ESR 45.2.0 without issue.
>
>
> Is it feasible to make 48 an ESR as well so that we don't need to ask
> users to downgrade it to ESR 45?
>

I don't think so. I also don't know that we're going to recommend that
users migrate to ESR (need to verify that there are no incompatible profile
changes) although that is certainly an option.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Tue, May 3, 2016 at 6:56 PM, Mike Hommey  wrote:

> On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote:
> > On 5/3/16 4:59 PM, Justin Dolske wrote:
> > > On 5/3/16 12:21 PM, Gregory Szorc wrote:
> > >
> > > > * The update server has been reconfigured to not serve Nightly
> > > > updates to
> > > > 10.6-10.8 (bug 1269811)
> > >
> > > Are we going to be showing some kind of notice to affected users upon
> > > Release? That is, if I'm a 10.6 user and I update to Firefox 48, at
> some
> > > point should I see a message saying I'll no longer receive future
> > > updates?
> >
> > Even better, is there any way to get the update system to automatically
> move
> > such users over to 45ESR?
>
> Did we introduce changes to profile data between 45 and 48? Because
> that usually breaks downgrade paths.
>

We discussed this earlier and decided that we were not going to
automatically move users from Firefox to ESR. For one thing, the user has
not opted to be on this channel. A channel change also involves both
engineering and test work. It does seem prudent to test the scenario to
know whether users can move from 47 to ESR 45.2.0 without issue.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Mon, May 2, 2016 at 2:28 PM, Ralph Giles <gi...@mozilla.com> wrote:

> On Fri, Apr 29, 2016 at 9:52 PM, Lawrence Mandel <lman...@mozilla.com>
> wrote:
>
> > I had planned to update the thread after the post went live so that I had
> > the link. Thank you for posting it.
>
> The blog post just says "August 2016". Firefox 48 is scheduled for
> release August 2. Can you confirm that means we can start removing
> 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
>

Yes. Confirmed.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Sat, Apr 30, 2016 at 1:37 AM, Mike Hommey  wrote:

> On Sat, Apr 30, 2016 at 12:38:37AM -0400, Kohei Yoshino wrote:
> > Today's announcement from Mozilla:
> >
> https://blog.mozilla.org/futurereleases/2016/04/29/update-on-firefox-support-for-os-x/
> >
> > The decision is fine but why don't they update this thread? (I know,
> Mozilla is very bad at communication.)
>
> So we're telling users that they can ... downgrade Firefox (since they
> just received an upgrade)? How is that fine?
>
> I assume you mean that ESR is still supported. If so, that message is
there to head off any questions about whether Mozilla has changed support
for ESR mid cycle. It is certainly plausible that OSX 10.6-10.8 users will
want to move to ESR to continue receiving sec updates for the next ~year.
Should we have made this decision and announced it before the 46 release? I
would have liked that. The timing certainly seems better. Should we
continue supporting OSX 10.6-10.8 in Firefox until mid 2017 because we
didn't make this decision a few months ago? I don't think so.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

Hi Kohei,

I had planned to update the thread after the post went live so that I had
the link. Thank you for posting it.

Lawrence

On Sat, Apr 30, 2016 at 12:38 AM, Kohei Yoshino 
wrote:

> Today's announcement from Mozilla:
>
> https://blog.mozilla.org/futurereleases/2016/04/29/update-on-firefox-support-for-os-x/
>
> The decision is fine but why don't they update this thread? (I know,
> Mozilla is very bad at communication.)
>
> -Kohei
>
> ___
> 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: Moving XP to ESR?

[Lawrence Mandel]

On Mon, Apr 18, 2016 at 9:04 AM, Henri Sivonen  wrote:

> XP has now gone for two years without security patches from Microsoft.
> Additionally, as of its latest release, Chrome no longer supports XP.
>
> When 46 ships, it would be a great time to make AUS advertise 45 ESR
> builds to XP (even on non-ESR) channel. This would keep XP supported
> through the ESR cycle but would put an end to the XP tax on trunk.
>
> Are we already on track to doing this? If not, why not?
>

We are not on track to do this.

The Firefox Product team is investigating Firefox use on XP in order to
make a decision about the criteria that need to be met to continue to
support this OS. No decision has been made about a change in support for
Windows XP.

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

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Lawrence Mandel]

On Monday, 11 April 2016, Mike Taylor  wrote:

> On 4/11/16 5:04 PM, Mats Palmgren wrote:
>
>> He touched 283 bugs in the last 48 hours, most of which are FIXED.
>>
>
> If anyone in the QA org reads this list, maybe they could reach out and
> teach him how to more effectively contribute?
>
> (I see "[bugday-20160323]" from <
> https://quality.mozilla.org/event/bug-verification-day-109/>.)
>
>
Good thinking.

Florin - Does anyone on your team know this contributor?

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

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Lawrence Mandel]

Good intentions or not, we need to stop this activity.

Mark - What's our usual approach to address bug spam?

Lawrence

On Monday, 11 April 2016, Mats Palmgren  wrote:

> On 2016-04-11 23:32, Emma Humphries wrote:
>
>> Here's the open bugs they have touched http://mzl.la/1Q3w24o
>>
>
> He touched 283 bugs in the last 48 hours, most of which are FIXED.
>
> Many comments are identical, for example:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240762
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240778
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240670
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240682
>
> All four have identical comments, added in a time span of 15 seconds.
>
> /Mats
>
> ___
> 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: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Fri, Apr 1, 2016 at 11:48 AM,  wrote:

> On Thursday, March 10, 2016 at 12:04:03 PM UTC-6, Benjamin Smedberg wrote:
> > This is notice of an intent to deprecate support within Firefox for the
> > following old versions of MacOS: 10.6, 10.7, and 10.8
> >
> > The motivation for this change is that we have continued failures that
> > are specific to these old operating systems and don't have the resources
> > on engineering teams to prioritize these bugs. Especially with the
> > deployment of e10s we're seeing intermittent and permanently failures on
> > MacOS 10.6 that we are not seeing elsewhere. We get very little testing
> > of old MacOS versions from our prerelease testers and cannot dedicate
> > much paid staff testing support to these platforms. We also have an
> > increasingly fragile set of old hardware that supports automated tests
> > on 10.6 and do not intend to replace this.
> >
> > This will affect approximately 1.2% of our current release population.
> > Here are the specific breakdowns by OS version:
> >
> > 10.6
> >   0.66%
> > 10.7
> >   0.38%
> > 10.8
> >   0.18%
> >
> > The final timeframe for this deprecation has not been finalized, but the
> > current proposal is to remove support in Firefox 46. We will try and
> > update existing users on old MacOS versions to the Firefox 45 ESR
> > release stream, so that they stay with security update support through
> > the end of 2016.
> >
> > Because of the ESR update window, I would like to finalize this decision
> > by Monday. If you have questions or concerns about this plan, please
> > reply to the firefox-dev mailing list immediately. Jeff Griffiths will
> > be working with our communications team to coordinate more public
> > communications such as post to the Future of Firefox blog.
> >
> > --BDS
>
> I am on 10.6.8 with no plan to upgrade soon. Every beta version beyond v
> 44.0b9 causes screen freezes and very slow operation for me.  Where do I
> find the ESR update?
>

Before you update, can I introduce you to Milan, who leads our graphics
team, so that he might be able to work with you to get some diagnostic
information that can help us identify the cuase of the freezes and slowness?

When you're ready,

https://www.mozilla.org/en-US/firefox/organizations/

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

Re: Triage Plan for Firefox Components

[Lawrence Mandel]

Softvision also makes use of the feature keyword as one way to identify new
feature work to test in upcoming releases.

Lawrence

On Thu, Mar 31, 2016 at 10:49 AM, Milan Sreckovic 
wrote:

> We do have a feature keyword today.  While it may be most used for the
> documentation purposes, the feedback graphics team got when we started
> using it to tag feature requests was positive.  As in, it’s OK to use for
> that.
> —
> - Milan
>
>
>
> > On Mar 29, 2016, at 22:32 , Emma Humphries  wrote:
> >
> > On Tue, Mar 29, 2016 at 5:09 PM, Eric Rescorla  wrote:
> >
> >> On a more substantive, less procedural note, this seems to be designed
> for
> >> a particular workflow in which there is an assumption that bugs are for
> >> immediate processing. However, in may cases we use bugs as placeholders
> or
> >> assemble big dependency trees of all the bugs that are needed to do a
> large
> >> complex feature. From this perspective, a three-tier system of "urgent",
> >> "non-urgent", and "wishlist" is either a regression from more
> fine-grained
> >> systems such as dependency trees/priorities or is redundant with them.
> This
> >> is especially true for long-running efforts. In other words, this may
> be a
> >> useful change for some components while not being useful for others. For
> >> the specific case of NSS (where I currently do a lot of my work) this
> >> doesn't seem like it would be a helpful change.
> >
> >
> > ​This is where it would be nice to have a way of saying, feature vs. bug
> as
> > part of the triage process, even it that's not a clean separation to
> make,
> > because that could get long running feature work out of the triage
> process,
> > but I don't have an immediate answer for this. It may be that we change
> the
> > scope of components this applies to.
> >
> > I'll follow up with Doug Turner to see if changing the scope of this for
> > platform related bugs is warranted.
> >
> > ​
> > --
> > ​ Emma​
> > ___
> > 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: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Sat, Mar 12, 2016 at 4:46 PM, Kyle Huey  wrote:

> On Fri, Mar 11, 2016 at 4:28 PM, Terrence Cole  wrote:
>
> > We need to drop support for OSX 10.8 and Windows Vista yesterday, not
> next
> > year. We need to cut our losses and ship E10S while we're still relevant.
> > We need to be the browser that works best on Android and Windows 10, not
> > the browser that happens to already be installed.
> >
>
> You do realize that you're talking about throwing away nearly 20% of our
> user base, right?
>
>
If the concern for user base is marketshare (as I've read and heard some
people claim, although maybe not Kyle), I'm not sure this argument holds
water for two reasons:

1. If we stop supporting an OS version today, all of the users on that
version will not immediately switch to an alternative.
2. In the case of older OSes, if there are no other browsers shipping
updates, there is really no alternative that is more attractive than the
browser that you've already picked.

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

Re: Intent to ship: Support for color-adjust CSS property

[Lawrence Mandel]

Whether or not we ship with the feature enabled, the ability to disable a
feature with a pref gives us an easy out if a critical issue is discovered.
(For ex, a code path that results in a top crash.) I suggest that we create
the pref in either case and plan to remove it after a couple of releases if
no critical bugs have come in.

Lawrence

On Thu, Mar 3, 2016 at 11:39 PM, Tobias Schneider 
wrote:

> As of Firefox 47 I intend to ship support for color-adjust on all
> platforms. Chrome is already shipping this as -webkit-print-color-adjust.
>
> The color-adjust CSS property allow pages to opt in to printing background
> colors and images. Chrome is already shipping this and Google Docs is using
> it in production (e.g. they highlight text using backgrounds). This is one
> of the missing features that prevents Google Docs from printing natively in
> Firefox.
>
> Open question:
>
> Should this be implemented behind a preference first or can we ship this
> directly? Given the fact that this feature is already used in Google Docs,
> we might rather ship this without a prefer off phase.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1209273
> Link to standard: https://drafts.csswg.org/css-color-4/#color-adjust.
> ___
> 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: 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: Decommissioning "dumbmake"

[Lawrence Mandel]

On Sun, Oct 18, 2015 at 7:14 PM, Nicholas Nethercote  wrote:

> On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla  wrote:
> >
> > What's needed here is a dependency management system that
> > simply builds what's needed regardless of what's changed,
>
> Otherwise known as "a proper build system". glandium and co. have been
> working towards that for a long time. It's a big, difficult job. |mach
> build binaries| and |mach build faster| are temporary waypoints along
> the way that approximate "a proper build system" for a couple of
> common workflows. Eventually |mach build| should just do the right
> thing, no matter what files you've touched...
>
> > not more ways for the user to tell the build system "only rebuild some
> stuff".
>
> ... except that bholley and ehsan are asking for a way to override the
> dependency tracking and just rebuild particular directories. Which is
> reasonable, up to a point. I argue that support for this kind of thing
> should be very limited and simple, to avoid getting in glandium's way
> as he works towards "a proper build system". IMO, if you're elite
> enough that you're regularly telling the build system "I know better
> than you" then you're elite enough to remember which directories need
> to be built in which order, or to encode those ordering into some
> aliases.
>

A proper build system is something that we needed yesterday. jgriffin and
co are working on a plan to create a proper build system (no doubt with
glandium) starting in Q1. (Actually, ground work has already started.) We
can hack on things until then but we really just need to do the right
things that have been discussed in this and other threads.

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

Re: Sheriffing Newsletter September!

[Lawrence Mandel]

> 1. Ryan's last week as Sheriff!
>
> As you might have heard that RyanVM is leaving the Sheriff Team to he will
> be leading a new quality team as part of the Firefox org. So its his last
> week as Sheriff this week.
> Thanks for all what do you did for keeping the Trees open and making the
> Sheriff-Role and Sheriffing what it is today and all the best for your new
> Role Ryan!
>
> Also of course there will be other Sheriffs around if you have questions
> let us know anytime (see the contact section below).
>
>
Ryan - You were really excellent in the sheriff role. A great partner for
release management and a strong defender or the tree. I'm thrilled that
you've found a new way to help the Mozilla project. Congratulations on your
new role!

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

Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

[Lawrence Mandel]

+1 to Milan's suggestion. These fields are used somewhat consistently on
stability and graphics bugs, which release management pays attention to. If
we are going to continue with the fields, I like the idea of Not
specified as that makes it clear that no value was set whereas All is
currently used if the bug affects all platforms or if we don't know.

Lawrence

On Tue, Apr 14, 2015 at 12:36 PM, Milan Sreckovic msrecko...@mozilla.com
wrote:

 Having that field be wrong is worse than not having it, no doubt about
 that, but if we had a way of making sure that field actually contains
 correct information, it would be extremely useful to the graphics team.

 I don’t have the numbers, but it certainly feels like a large majority of
 the bugs we get are in fact platform specific.  Even with the current
 limitation of “if it’s more than one, it’s all”, that’s still better than
 no information at all.

 If I was going with the “what can we do that’s fairly simple and improves
 things”, I’d create a new value for that field, “Not specified” (or
 something like that) and make that the default.  That way, we differentiate
 between the values that were explicitly set, in which case, I have to hope
 they will be more correct than they are today, and values that were just
 left at the default value.
 —
 - Milan



 On Apr 14, 2015, at 12:18 , Benjamin Smedberg benja...@smedbergs.us
 wrote:

 
 
  On 4/14/2015 11:40 AM, Dave Townsend wrote:
  Are the platform fields actually useful? Most bugs apply to all
 platforms
  and in the cases that don't it is normally clear from the bug
 conversation
  that it is platform specific. It seems like we rarely go an update the
  platform fields to match the actual state of the bug. And then there is
 the
  problem that OS doesn't allow for multi-selections where say a bug
 affects
  a few versions of Windows or Windows and OSX. I've gotten used to just
  ignoring these fields and reading the bugs instead. I wouldn't feel any
  loss if they were just removed from display entirely.
 
  I've suggested this before (and still think that's the right user
 experience). In fact this turns out to be really difficult to do within
 bugzilla because those fields are baked into bugzilla guts and removing
 them would require not just hiding them on the edit-bug page but also from
 the query pages and various other locations.
 
  I do think we should try to stop using these fields for anything
 important.
 
  --BDS
  ___
  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: Updating the policy for Talos performance regression in 2015

[Lawrence Mandel]

Old thread but now that we're 3 months into 2015, has this new policy been
effective at getting perf regressions fixed or at least deliberately
accepted?

Lawrence

On Fri, Dec 19, 2014 at 1:33 PM, jma...@mozilla.com wrote:

 Great questions folks.

 :bsmedberg has answered the questions quite well, let me elaborate:
 Before a bug can be marked as resolved:fixed we need to verify the
 regression is actually fixed.  In many cases we will fix a large portion of
 the regression and accept the small remainder.

 We do keep track of all the bugs filed per version (firefox 36 example:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1084461)

 these get looked at more specifically during each uplift.

 I will update the verbage next week to call out how these will be followed
 up and posted to:
 https://www.mozilla.org/hacking/regression-policy.html

 Do speak up if this should be posted elsewhere or linked from a specific
 location.
 ___
 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

Firefox 34 release date moving to Dec 1/2

[Lawrence Mandel]

The Firefox 34 release date will move out one week from Nov 25 to Dec 1/2. This 
change impacts Firefox Desktop, Firefox for Android, Firefox ESR, and 
Thunderbird. The purpose of this change is to allow for an additional week of 
stabilization during the 34 cycle.

Details of the change:
- Release date change from Nov 25 to Dec 1/2 (need to determine the date that 
works best given the work week)
- Merge date change from Tue, Nov 24 to Fri, Nov 28
- Two additional desktop betas (10 and 11) will be added to the calendar this 
week on our usual beta build schedule (build Mon and Thu, release Tue and Fri)
- One additional mobile beta (beta 11) will be added to the schedule. Note that 
mobile beta 10 will gtb on schedule on Mon. Mobile beta 11 will gtb on Thu with 
desktop in order to be ready early the following week.
- RC builds will happen on Mon, Nov 24

Note that we are effectively moving an extra week that we had previously added 
to the 35 Beta cycle in the 34 Beta cycle. 35 will have a 7 week Aurora cycle 
instead of a 7 week Beta cycle.

Follow-up questions to dev-planning please.

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

CHANGE: Next merge date is Tue, Sep 2, 2014

[Lawrence Mandel]

(Cross posting for visibility. Followups to dev-planning please.)

The next merge was scheduled for Mon, Sep 1, 2014, which is labour day in 
Canada and the US. In order to accommodate holiday schedules, the merge will 
instead occur on Tue, Sep 2, 2014. This change will have no impact on the 
Firefox Desktop and Firefox for Android 32 releases, which will proceed with 
release activities as originally scheduled.

Lawrence

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

Re: Intent to deploy: plugin timeout A/B test experiment, bug 1018200

[Lawrence Mandel]

I missed this earlier. Lacking any major concerns (Jet did express one), I 
approve the deployment of this experiment on Beta 32 on behalf of release 
management.

Lawrence

- Original Message -
 This is an official notice of intent to deploy the experiment in bug
 1018200 to the beta channel.
 
 The experiment is an A/B test to determine the optimal value of the
 dom.ipc.plugins.unloadTimeoutSecs on the FF32 beta. This setting
 determines primarily how long we wait to unload Flash and other plugins
 after a user isn't using it any more while browsing. Users in the
 experiment will be grouped into 8 equal groups whose timeouts will be
 set to various values: 0, 5, 15, 30, 60, 90, 120, and 300 seconds.
 
 The experiment parameters are:
 MinVersion: 32.0
 MaxVersion: 34.*
 Start Date: 01-Jul-2014
 End Date: 02-Sep-2014
 Maximum runtime: 42.0 days
 Update Channels: beta
 Sample Rate: 5%
 Low-priority experiment: this experiment is lower-priority than the
 translation experiment already scheduled for beta, so any users eligible
 for that experiment will participate in that one first. A reminder that
 the experiment system only runs one experiment at a time, so there is no
 chance of multiple experiments conflicting.
 
 To analyze the results I intend after 2-3 weeks to correlate the
 experiment groups against the telemetry measurement for plugin launch
 time (bug 1011136). This will tell us both how often users are launching
 plugins, but also how long those plugin launches take. My intent is to
 pick a final value for this preference based on the data before we ship
 FF32 to release.
 
 Chad, I'm looking for your approval to use 5% of the beta population for
 this experiment.
 Release-drivers, I am looking for your approval to enable this
 experiment as soon as Kamil completes QA verification on staging.
 gps, I would like you to take care of getting this experiment deployed
 to production when everything is ready and monitoring the deployment,
 since I will be on vacation.
 
 I want to thank Qeole, a contributor who implemented the correct timeout
 setting, the telemetry probe, and this experiment all himself. He/she
 has done this thoughtfully and well.
 
 --BDS
 
 ___
 release-drivers mailing list
 release-driv...@mozilla.org
 https://mail.mozilla.org/listinfo/release-drivers
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: On closing old bugs

[Lawrence Mandel]

- Original Message -
 Opened that long ago, and haven't been touched for a long time?  Or just
 opened that long ago?

My simple query was based on bug creation date. The handful of bugs that I 
looked at I think hadn't been meaningfully touched in at least 5 years.

Lawrence

 --
 - Milan
 
 On 2013-12-04, at 14:15 , Lawrence Mandel lman...@mozilla.com wrote:
 
  - Original Message -
  Lawrence Mandel writes:
  
  - Original Message -
  On 27/11/13 07:36, Gabriele Svelto wrote:
  I'm always tempted to close the former as duplicates of the
  actual fix and the latter as WONTFIX so that they won't show
  up on the following searches but I'm also afraid that closing
  a bug several years old is akin to thread necromancy [1].
  
  Validly closing a bug is not thread necromancy. With Henri's
  concerns in mind, feel free to clean up Bugzilla on bug at a
  time :-)
  
  I agree. I don't think that keeping a large backlog of bugs in
  limbo - where no one is looking at the bugs or has any intention
  to fix any of them - helps anyone. I don't mean to suggest that
  we should close out all old bugs but that it is appropriate to
  close out old bugs that we don't think warrant any attention.
  
  Someone else may like to fix the bugs, so please don't close the
  bugs if it is reasonably likely that they may still be present.
  
  To try to be clear, I'm agreeing with Henri and Gerv, but I'm not
  sure that Lawrence understands.
  
  I'm taking a stronger stance and suggesting that we should be able to
  wontfix bugs that likely aren't worth anyone's time or attention. As a
  concrete example, what is the value in keeping the following bugs open?
  bug 2875 - Core::Networking:HTTP P5 enhancement opened 15 years ago
  bug 3246 - Core::Layout:Block and Inline P3 opened 14 years 9 months ago
  bug 6115 - Core::Networking P3 enhancement opened 14 years 7 months ago
  bug 6796 - Core::Editor P3 bug opened 14 years 6 months ago
  bug 39230 - Core::XUL P3 bug opened 13 years 6 months ago
  
  In fact, there at 6925 bugs across all Bugzilla products currently in the
  new or unconfirmed state that were opened more than 10 years ago. I would
  assert that if a bug hasn't been fixed in 10 years it probably isn't
  important enough to spend time on now. We can always reopen or refile if
  the issue becomes more pressing (by anyone's judgement).
  
  https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWchfield=[Bug%20creation]chfieldfrom=1995-01-01chfieldto=2003-01-01list_id=8772268query_format=advancedresolution=---resolution=DUPLICATEorder=bug_idlimit=0
  
  Lawrence
  ___
  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: On closing old bugs

[Lawrence Mandel]

- Original Message -
 On Tuesday 2013-12-03 21:15 -0800, Lawrence Mandel wrote:
  I'm taking a stronger stance and suggesting that we should be able to
  wontfix bugs that likely aren't worth anyone's time or attention. As a
  concrete example, what is the value in keeping the following bugs open?
 
  bug 3246 - Core::Layout:Block and Inline P3 opened 14 years 9 months ago
 
 I don't think this should be wontfixed; it's a valid bug, and I
 think worth fixing, although as part of other architectural changes.

The last meaningful comment in this bug was posted almost 13 years ago. It may 
be that this is worth fixing, in which case we're perhaps not doing a good job 
of finding this type of worthwhile bug in bugzilla. If this has simply been a 
lower priority than other work for ~15 years, perhaps it's time to admit that 
we're not going to fix this.

 I'd like to be able to use Bugzilla to track the known issues in our
 code rather than being forced to copy all the data into code
 comments.  (At least, I sometimes would.  Other times I'd rather use
 a version control system for tracking bugs.)

I think that's a valid point. wontfix bugs should represent known issues in our 
code. The difference between wontfix and new simply being that we have 
acknowledged that we are not going to fix a particular issue.

  In fact, there at 6925 bugs across all Bugzilla products currently
  in the new or unconfirmed state that were opened more than 10
  years ago. I would assert that if a bug hasn't been fixed in 10
  years it probably isn't important enough to spend time on now. We
  can always reopen or refile if the issue becomes more pressing (by
  anyone's judgement).
 
 I don't think that's true; both priorities and costs really do
 change over time.  A good example of priorities changing over time
 is https://bugzilla.mozilla.org/show_bug.cgi?id=63895 .  When filed,
 we may have been the only Web layout engine advanced enough for it
 to make sense to report the bug; today all the others have caught up
 and we're the only one with the bug.

Very true. However, at least in this case, if the bug had been closed at some 
point, the issue still would have surfaced when it became relevant due to the 
filing of duplicate bug 924048. In fact, there are 42 duplicates of this bug 
that have been filed over the years.

 I also think the idea that you should wontfix bugs as a function of
 age just leads to messing with the bugs of components that have been
 around for a long time.  See also
 http://dbaron.org/log/20080515-age-of-bugs .  And it sends a bad
 message to the people who are interested in seeing those components
 improve, reporting and commenting in bugs, etc.  Many of these old
 bugs are actually bugs that people care about, and that Web
 developers stumble into frequently.  Some of them also contain
 useful information about how to fix the problem described --
 information that wouldn't necessarily be there if they were
 wontfixed and new bugs filed.  I tend to think we should be putting
 more effort into some of them than we currently are.

I agree with this. Rereading my previous post I see that it looks like I meant 
that we should blanket close all old bugs. That was not my intention. I do 
think that we should consider wontfixing a very old bug that we don't think 
will be fixed at some point in the near future. Bugs that contain useful 
workarounds should perhaps remain open.

 (If there's a valid aging threshold, I think it's bugs that have
 been around long enough that they've shipped in a release.  I think
 it's a meaningful threshold because it proves they weren't bad
 enough that we had to fix them in order to ship.  But I think it's
 far from saying they should be wontfixed.)

I think it is reasonable to at least question whether we should wontfix bugs 
that shipped in, say, Firefox 3.

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

Re: On closing old bugs

[Lawrence Mandel]

- Original Message -
 On Tue, Dec 3, 2013 at 9:15 PM, Lawrence Mandel lman...@mozilla.com wrote:
 
  I would assert that if a bug hasn't been fixed in 10 years it probably
  isn't important enough to spend time on now.
 
 I strongly disagree with this statement, and any follow-on implication
 that blanket-closing bugs based on age is acceptable.

I included this in my response to David. I'm sorry for the poorly written 
sentence above. I did not mean to suggest that we blanket close old bugs only 
that we should be able to consider whether a bug that hasn't been fixed in 10 
years really has any likelihood of being fixed.

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

Re: On closing old bugs

[Lawrence Mandel]

- Original Message -
 On 12/3/2013 11:15 PM, Lawrence Mandel wrote:
  In fact, there at 6925 bugs  across all Bugzilla products currently in
   the new or unconfirmed state that were opened more than 10 years ago.
   I would assert that if a bug hasn't been fixed in 10 years it
   probably isn't important enough to spend time on now. We can always
   reopen or refile if the issue becomes more pressing (by anyone's
   judgement).
 
 I started trying to count how many open bugs were still important enough
 that I would consider fixing or offering to mentor a fix of. I lost
 track in my head of the count well before bug 100K, even after I removed
 all RFEs from the list. Some of these bugs (I'm focusing on mailnews
 bugs) are unfixed only because they depend on extremely complicated core
 layout bugs--the most notable ones being bug 31052 (which requires
 iframe seamless) and bug 213945 (which requires invasive changes to
 nsITreeView).
 
 Bug age correlates more closely to difficulty of fix than importance of
 fix, particularly for non-RFEs.

I think David, Nick, Henri, and you are right - there are lots of old bugs that 
we each think are important enough to fix. (Yes, I have some as well.) In my 
mind the real question is, given all of the work that we all have to do, are we 
going to spend the time to fix these bugs? If not, as a reporter would you 
prefer to see your bug go untouched for an indeterminate amount of time or 
would you prefer to see an acknowledgement that your bug will not be fixed at 
which point you can either shrug your shoulders or make a stronger case for why 
the bug should be fixed? 

All that said, I feel like I have inadvertently hijacked this thread. I respect 
the opinions of those on this thread and my comments simply reflect my thoughts.

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

Re: On closing old bugs

[Lawrence Mandel]

- Original Message -
 On 12/4/2013 2:30 PM, Lawrence Mandel wrote:
  I think David, Nick, Henri, and you are right - there are lots of old bugs
  that we each think are important enough to fix. (Yes, I have some as
  well.) In my mind the real question is, given all of the work that we all
  have to do, are we going to spend the time to fix these bugs? If not, as a
  reporter would you prefer to see your bug go untouched for an
  indeterminate amount of time or would you prefer to see an acknowledgement
  that your bug will not be fixed at which point you can either shrug your
  shoulders or make a stronger case for why the bug should be fixed?
 
 WONTFIX resolutions presently mean something extremely strong: if
 someone were to propose a patch to fix the bug, it would be rejected,
 even if it otherwise satisfied code quality constraints. There are
 notable instances of this condition where the resolution was made, even
 over vocal opposition (the Restore MNG bug is the most infamous example;
 the Hashcash spam bug is a more recent example). Changing this to mean
 we don't have realistic time to fix this dilutes the message that
 WONTFIX sends when it's really needed.

Thank you for this clarification. Many of the arguments that I've read/heard 
make a lot of sense in this context. 

 Quite frankly, closing valid, actionable old bugs (I make this
 distinction, because there are old reports where the information
 provided is useless for attempting to understand what's wrong) sends a
 wrong message to contributors. It also makes it harder for eager
 contributors to find bugs to work on--many of the first bugs I worked on
 *were* the 10 year-old bugs that no one was fixing.

Several people have made a similar comment. As long as people are finding value 
in the current system, there is good there. 

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

Re: Exposing (mobile) device info via the user agent or HTTP headers

[Lawrence Mandel]

- Original Message -
 On Friday, April 1, 2011 11:38:27 AM UTC-4, Benjamin Smedberg wrote:
  Discussion followup to bug 625238
  https://bugzilla.mozilla.org/show_bug.cgi?id=625238.
 
 Hi,
 
 After reading through this discussion thread as well as the comments on the
 bug report page, I think that there is one reason to expose the running
 Android version in the userAgent string that has not been discussed yet.
 Consider trying to make a website that closely replicates the look-and-feel
 of a native Android app.  Correct me if I am wrong, but in order to do this
 reasonably well you need to know the running Android version in order to use
 an appropriate visual theme, and this cannot be accomplished with media
 queries or other standard APIs.
 
 Suppose further that you were going to develop the website using Google Web
 Toolkit (to take advantage of one of the mobile GWT app development
 frameworks).  In GWT, the deferred binding mechanism is based on browser
 sniffing (usually using information extracted from the navigator.userAgent
 string, but other snippets of JavaScript can be used as well).  You could
 define a custom compilation property for the Android version and then bind
 an appropriate CssResource, one for each theme, according to the detected
 Android version.
 
 I realize that selecting a theme based on the Android version alone is not
 perfect (after all, Android currently provides two system themes, Holo Light
 and Holo Dark), but at least it would be a start, and it should be possible
 to guess correctly for a majority of the users.  Better yet, if the theme
 name were somehow included after the Android version, such as Android 4.3
 Holo Dark, then the website would not need to ask the user for the theme
 that he or she is using.  In general, I feel that having to ask users for
 these pieces of information detracts greatly from the user experience.
 
 I for one would love to be able to do this, adapt the look-and-feel of a
 webpage to the native theme.  However, if the user is using Firefox for
 Android, then I would have to guess a theme, and I would probably just pick
 the latest one.  This would be problematic if Google decides to make a major
 redesign in the future.
 
 Would Mozilla consider adding information to the userAgent string to enable
 this automatic theme selection technique?

Thank you for sharing your use case. We have been discussing UA use cases on 
the compatibility@ mailing list. The goal is to better understand the 
requirements from UA detection that cannot be achieved via other mechanisms. I 
won't say that changes will be made to the UA, but it is good to list out the 
requirements for UA detection so that we can work to address deficiencies in 
our current solution.

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

Re: FYI: Nightly 28 uplift in 7 days

[Lawrence Mandel]

- Original Message -
 This is a friendly reminder that the next channel merge date [1] is only
 7 days away! So don't forget to land those last minute bug fixes this
 week. :) Also, you may want to hold destablizing or less important
 changes until next week for Nightly 29.

As Gavin mentioned in today's Engineering meeting, the uplift will be taken 
from the holly branch this cycle in order to keep Australis limited to Nightly. 
So, better to avoid last minute landings in this cycle if possible.

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

Re: On closing old bugs

[Lawrence Mandel]

- Original Message -
 Lawrence Mandel writes:
 
  - Original Message -
  On 27/11/13 07:36, Gabriele Svelto wrote:
   I'm always tempted to close the former as duplicates of the
   actual fix and the latter as WONTFIX so that they won't show
   up on the following searches but I'm also afraid that closing
   a bug several years old is akin to thread necromancy [1].
  
  Validly closing a bug is not thread necromancy. With Henri's
  concerns in mind, feel free to clean up Bugzilla on bug at a
  time :-)
 
  I agree. I don't think that keeping a large backlog of bugs in
  limbo - where no one is looking at the bugs or has any intention
  to fix any of them - helps anyone. I don't mean to suggest that
  we should close out all old bugs but that it is appropriate to
  close out old bugs that we don't think warrant any attention.
 
 Someone else may like to fix the bugs, so please don't close the
 bugs if it is reasonably likely that they may still be present.
 
 To try to be clear, I'm agreeing with Henri and Gerv, but I'm not
 sure that Lawrence understands.

I'm taking a stronger stance and suggesting that we should be able to wontfix 
bugs that likely aren't worth anyone's time or attention. As a concrete 
example, what is the value in keeping the following bugs open?
bug 2875 - Core::Networking:HTTP P5 enhancement opened 15 years ago
bug 3246 - Core::Layout:Block and Inline P3 opened 14 years 9 months ago
bug 6115 - Core::Networking P3 enhancement opened 14 years 7 months ago
bug 6796 - Core::Editor P3 bug opened 14 years 6 months ago
bug 39230 - Core::XUL P3 bug opened 13 years 6 months ago

In fact, there at 6925 bugs across all Bugzilla products currently in the new 
or unconfirmed state that were opened more than 10 years ago. I would assert 
that if a bug hasn't been fixed in 10 years it probably isn't important enough 
to spend time on now. We can always reopen or refile if the issue becomes more 
pressing (by anyone's judgement).

https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWchfield=[Bug%20creation]chfieldfrom=1995-01-01chfieldto=2003-01-01list_id=8772268query_format=advancedresolution=---resolution=DUPLICATEorder=bug_idlimit=0

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

Re: A/B testing with telemetry

[Lawrence Mandel]

- Original Message -
 Do we have a formalized way to do A/B testing with telemetry? That is,
 assuming that there is a telemetry probe that measures problem
 symptoms and a boolean pref for  turning on a potential solution, is
 there a way the declare the pref as something that telemetry queries
 can be constrained by so that it would be possible to compare the
 symptom probe with and without the potential solution?

No, but I think this is desirable. 
 
 If not, is there a better way to do this than duplicating probes and
 checking the pref to see which probe should be fed?

A probe is not restricted to boolean values. You can define a histogram that 
maps values to conditions. As such, you can have a single probe that captures 
all of the required data. Depending on your use case, this structure may be 
more difficult to read after the data is aggregated on the server.

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

Re: Feature tracking via bug keyword

[Lawrence Mandel]

- Original Message -
 On 16/10/2013 22.02, Lukas Blakk wrote:
  This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now
  picks up on the keyword 'feature' in your meta/tracking bugs.
 
 I've set the keyword and milestone on bug 907082 but don't see it in:
 
 https://wiki.mozilla.org/Features/Release_Tracking#Platform_2
 
 I've marked it as FIXED because it seems that the queries require that,
 but I'm not familiar with the JSON query language enough to understand
 why the bug does not appear in the results after doing that.

The issue is that the platform queries were only set to match product=Core. I 
have updated the platform queries to include the Toolkit product and your bug 
is now listed in the table.

 By the way, can the queries be less restrictive and just select by
 product, milestone and feature keyword? We generally defer setting
 the FIXED status on meta-bugs until all the major dependencies are
 handled, that may happen during the Aurora cycle as well, and having
 the feature show up in release tracking before everything is fixed can
 be useful.

Lukas - Can you comment on why the queries require the FIXED status?

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

Re: Feature tracking via bug keyword

[Lawrence Mandel]

- Original Message -
 Lukas Blakk wrote:
  This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
  now picks up on the keyword 'feature' in your meta/tracking bugs.
 
  Please add this to your feature work to make sure it gets early QA,
  Stability, PR, User Advocacy, and Release Management awareness in
  preparation (and in support) of their initial launch.
 
 What counts as a feature?
 
At this point I would consider any major change to the browser as a 'feature'. 
This is definitely a judgement call. As Juan pointed out with QA, I would 
consider flagging any work that requires cross team collaboration (QA, releng, 
IT, etc.), that makes a significant, user or dev visible change (i.e. changes 
to the UI and changes to DOM/JS APIs), or that you think should be relnoted or 
announced on the Mozilla blog (alerting comms). I'm sure there are other 
suitable criteria and just because one or more of these criteria are met 
doesn't mean you necessarily have to flag a bug as a feature.

We should learn as we go. I think over flagging is welcome at this point.

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

Re: Summit Innovation Fair: Improving developer productivity at Mozilla?

[Lawrence Mandel]

- Original Message -
 At the summit's Innovation Fairs, Mozilla's program management team will
 be hosting Developer Productivity booths to gather suggestions for
 streamlining our development processes and reducing developer frustration.
 
 What speed bumps are getting you down? Hardware, software, tools, trees,
 hg, git, builds, Bugzilla, bugmail, code reviews, office noise, Vidyo,
 or something else?
 
 Bring your ideas to the Innovation Fairs on Saturday between 11:30 AM to
 1:30 PM. After the summit, we'll review the suggestions and try to
 address the most pressing issues. Our plan is for this to be just the
 beginning of an ongoing improvement program. :)

Thank you to those of you who contributed your ideas at the Summit. We have 
dumped the information that we collected at 

https://etherpad.mozilla.org/kHpv9jvGMj

If you missed us at the Summit and have additional ideas, feel free to add them 
at the bottom of the etherpad. Chris will provide the rundown and next steps 
during next week's Engineering meeting and on dev-platform.

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

Engineering Meeting: Tue, Aug 13, 11am PT

[Lawrence Mandel]

The Engineering meeting is a weekly time to discuss the work of engineering 
teams and share information relevant to the day-to-day work of engineers.

Meeting Details:
* Agenda:  https://wiki.mozilla.org/Platform/2013-08-13
* Engineering Vidyo Room and Air Mozilla
* https://v.mozilla.com/flex.html?roomdirect.htmlkey=T2v8Pi8WuTRc
* Vidyo Phone# 650-903-0800 x92 Conf#98411 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 98411 (US)
* join irc.mozilla.org #planning for back channel

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

Engineering meeting to be broadcast on Air Mozilla starting Aug 6, 2013

[Lawrence Mandel]

The weekly Engineering meeting will be broadcast on Air Mozilla starting this 
coming week (Aug 6, 2013). The reasons for broadcasting this meeting on Air 
Mozilla are to:

1. provide a recording of the meeting for those who unable to attend at the 
scheduled time
2. make it easier for people to attend (no need for Vidyo)

Recordings will be archived on Air Mozilla for 3 months.

As a reminder, Air Mozilla broadcasts and recordings are for a global audience. 
While no public engineering related topic is off limits, please be mindful of 
your language and tone.

Thanks,

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

Engineering/Platform meeting reboot summary

[Lawrence Mandel]

As I previously posted, this week we rebooted the Engineering/Platform meeting. 
I blogged about the changes.

http://lawrencemandel.com/2013/06/06/mozilla-engineeringplatform-meeting-reboot/

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

Re: Platform meeting changes effective June 2013

[Lawrence Mandel]

- Original Message -
 On 30/05/13 04:55, Mike Hommey wrote:
  As someone that will soon be in UTC+9, and taking on the occasion
  to
  represent all the people in that timezone and surroundings, a
  couple
  hours before 3am is not very a great time to decide whether I'd
  attend
  or not. That being said, I haven't attended much so far. OTOH, if
  the
  meeting value is increasing which it looks like it will, i might
  want
  to. I don't know if 3am is attractive enough, though.
 
 What is the attendance like from the Asia-Pacific region?

I think the answer is low to none. This is specifically why I will do #2 below.

 2. Work on summarizing discussions or vague items in the agenda so that the 
 notes can be understood by people who don't attend the meeting

Please let me know how the notes shape up.

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

Platform meeting changes effective June 2013

[Lawrence Mandel]

tl;dr The platform meeting will revert to focus on engineering teams as of next 
week.

We discussed the platform meeting's use during today's platform meeting. The 
consensus of the people who attended the meeting is that the platform meeting 
is useful and should be continued. Here is my summary of the key points from 
the discussion.
 
- releng and relman both find this a useful venue to disseminate information
- People like the team status updates - suggestion to hear from more of the 
technical teams
- Useful venue for flagging topics on mailing lists - summaries of any 
discussion should be posted back to the list
- Good opportunity to discuss issues with the technical teams
- Useful for raising awareness and finding owners for stability, orange factor 
bugs
- This meeting is a forcing function for the activities listed above

Specific suggestions:
- a concise summary of this meeting or decisions should be posted to 
dev-planning or a blog post
- revert the meeting agenda back to focus on technical teams (the meeting 
changed in Oct 2012) not products - we have the product meeting for product 
discussions
- provide a section in the agenda for others to ask questions of individual 
teams

Based on this feedback...

I will take a stab at defining the purpose of the meeting as:
A weekly time for engineering teams to share information with and ask questions 
of one another.

I will make the following changes, effective next week:
1. Modify the agenda to focus on engineering teams and activities.
2. Work on summarizing discussions or vague items in the agenda so that the 
notes can be understood by people who don't attend the meeting

In support of these changes, I will speak with as many engineering team 
managers as possible before next week in an attempt to bring the content inline 
with what is desired.

Of course, this is a work in progress. This being your meeting, do these 
changes make sense to you? Please share your suggestions either by replying to 
the list or to me individually.

Thanks for reading.

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

Re: Platform meeting changes effective June 2013

[Lawrence Mandel]

- Original Message -
 I'd really like to see the agenda for this meeting to be finalized a
 day
 or so in advance so that I can decide whether what's going to be
 discussed in the meeting interests me or not.  Do you think doing
 that
 would make sense?

I would also prefer an agenda that is set before the meeting and need to 
discuss this with those who will be contributing to the agenda. I think a day 
in advance might be pushing it given when I see most Mozilla meeting agendas 
take shape. I would be happy with a fairly solid agenda a couple of hours in 
advance of the meeting. Would that be enough time to let you decide if you want 
to attend?

Lawrence

 
 Cheers,
 Ehsan
 
 On 2013-05-28 5:10 PM, Lawrence Mandel wrote:
  tl;dr The platform meeting will revert to focus on engineering
  teams as of next week.
 
  We discussed the platform meeting's use during today's platform
  meeting. The consensus of the people who attended the meeting is
  that the platform meeting is useful and should be continued. Here
  is my summary of the key points from the discussion.
 
  - releng and relman both find this a useful venue to disseminate
  information
  - People like the team status updates - suggestion to hear from
  more of the technical teams
  - Useful venue for flagging topics on mailing lists - summaries of
  any discussion should be posted back to the list
  - Good opportunity to discuss issues with the technical teams
  - Useful for raising awareness and finding owners for stability,
  orange factor bugs
  - This meeting is a forcing function for the activities listed
  above
 
  Specific suggestions:
  - a concise summary of this meeting or decisions should be posted
  to dev-planning or a blog post
  - revert the meeting agenda back to focus on technical teams (the
  meeting changed in Oct 2012) not products - we have the product
  meeting for product discussions
  - provide a section in the agenda for others to ask questions of
  individual teams
 
  Based on this feedback...
 
  I will take a stab at defining the purpose of the meeting as:
  A weekly time for engineering teams to share information with and
  ask questions of one another.
 
  I will make the following changes, effective next week:
  1. Modify the agenda to focus on engineering teams and activities.
  2. Work on summarizing discussions or vague items in the agenda so
  that the notes can be understood by people who don't attend the
  meeting
 
  In support of these changes, I will speak with as many engineering
  team managers as possible before next week in an attempt to bring
  the content inline with what is desired.
 
  Of course, this is a work in progress. This being your meeting, do
  these changes make sense to you? Please share your suggestions
  either by replying to the list or to me individually.
 
  Thanks for reading.
 
  Lawrence
  ___
  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: [Advance warning] Session Restore is changing, will break add-ons

[Lawrence Mandel]

cc Jorge Villalobos.

- Original Message -
 As part of project Async, we have been working on refactoring
 Firefox’
 Session Restore to ensure that it does not block the main thread.
 Part
 of the work has been cleaning up the code and the data structures
 involved in Session Restore both to give us some maneuverability and
 to
 improve the chances of catching refactoring errors.
 
 Unfortunately, a large number of add-ons seem to rely upon these
 undocumented data structures. Some of their features might therefore
 stop working. If you are the author of one such add-on, you should
 monitor carefully bug 874381 and its blockers. If you realize that we
 are about to break your add-on, please inform us asap, so that we can
 work out a solution.
 
 Cheers,
  David
 --
 David Rajchenbach-Teller, PhD
  Performance Team, Mozilla
 ___
 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: Storage in Gecko

[Lawrence Mandel]

- Original Message -
 Great post, Taras!
 
 Per IRC conversations, we'd like to move subsequent discussion of
 actions into a meeting so we can more quickly arrive at a resolution.
 
 Please meet in Gregory Szorc's Vidyo Room at 1400 PDT Tuesday, April
 30.
 That's 2200 UTC. Apologies to the European and east coast crowds. If
 you'll miss it because it's too late, let me know and I'll consider
 moving it.
 
 https://v.mozilla.com/flex.html?roomdirect.htmlkey=yJWrGKmbSi6S

Did someone post a summary of this meeting? Is there a link to share?

Lawrence

 
 On 4/29/13 10:51 AM, Taras Glek wrote:
  * How to robustly write/update small datasets?
 
  #3 above is it for small datasets. The correct way to do this is to
  write blobs of JSON to disk. End of discussion.
 
  Writes of data = ~64K should just be implemented as atomic
  whole-file
  read/write operations. Those are almost always single blocks on
  disk.
 
  Writing a whole file at once eliminates risk of data corruption.
  Incremental updates are what makes sqlite do the WAL/fsync/etc
  dance
  that causes much of the slowness.
 
  We invested a year worth of engineering effort into a pure-js IO
  library
  to facilitate efficient application-level IO. See OS.File docs, eg
  https://developer.mozilla.org/en-US/docs/JavaScript_OS.File/OS.File_for_the_main_thread
 
 
  As you can see from above examples, manual IO is not scary
 
  If one is into convenience APIs, one can create arbitrary
  json-storage
  abstractions in ~10lines of code.
 
  * What about writes  64K?
  Compression gives you 5-10x reduction of json.
  https://bugzilla.mozilla.org/show_bug.cgi?id=846410
  Compression also means that your read-throughput is up to 5x better
  too.
 
 
  * What about fsync-less writes?
  Many log-type performance-sensitive data-storage operations are ok
  with
  lossy appends. By lossy I mean data will be lost if there is a
  power
  outage within a few seconds/minutes of write, consistency is still
  important. For this one should create a directory and write out log
  entries as checksummed individual files...but one should really use
  compression(and get checksums for free).
  https://bugzilla.mozilla.org/show_bug.cgi?id=846410 is about
  facilitating such an API.
 
  Use-cases here: telemetry saved-sessions, FHR session-statistics.
 
  * What about large datasets?
  These should be decided on a case-by-case basis. Universal
  solutions
  will always perform poorly in some dimension.
 
  * What about indexeddb?
  IDB is overkill for simple storage needs. It is a restrictive
  wrapper
  over an SQLite schema. Perhaps some large dataset (eg an
  addressbook) is
  a good fit for it. IDB supports filehandles to do raw IO, but that
  still
  requires sqlite to bootstrap, doesn't support compression, etc.
  IDB also makes sense as a transitional API for web due to the need
  to
  move away from DOM Local Storage...
 
  * Why isn't there a convenience API for all of the above
  recommendations?
  Because speculatively landing APIs that anticipate future consumers
  is
  risky, results in over-engineering and unpleasant surprises...So
  give us
  use-cases and we(ie Yoric) will make them efficient.
 
  Taras
 
 ___
 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

Firefox/Gecko Development Meeting: Tue, Apr 30, 11am PT

[Lawrence Mandel]

The Firefox/Gecko development meeting is held weekly to discuss development 
team progress and issues related to the development of Firefox branded products 
and the Gecko platform.

Actions from last week are here:
https://wiki.mozilla.org/Platform/2013-04-30#Actions

Meeting Details:
* Agenda:  https://wiki.mozilla.org/Platform/2013-04-30
* Engineering Vidyo Room
* https://v.mozilla.com/flex.html?roomdirect.htmlkey=T2v8Pi8WuTRc
* Vidyo Phone# 650-903-0800 x92 Conf#98411 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 98411 (US)
* join irc.mozilla.org #planning for back channel

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

Re: Increasing the platform meeting's relevance for engineers

[Lawrence Mandel]

- Original Message -
 I think if we need to find reasons to keep a meeting relevant, we
 need
 to kill the meeting.  Lawrence, you should just discontinue the
 meeting
 for a few weeks and see if we really need it.  I bet we wont.

My understanding from speaking with a few people is that the platform meeting 
was once useful to engineers. My goal with this thread is to discuss whether 
there's value in having a meeting for engineers and what that would look like. 
If there is value, we can reboot this meeting. If not, we'll have to consider 
whether, as you stated, we should discontinue it. We definitely should not meet 
for meeting sake. However, I have had people tell me that they do get some 
value from this meeting.

Lawrence

 I would much rather see us spend the time to curate what's important
 --
 what platform people should/must read.  Someone started a Reddit
 subgroup r/MozillaTech.  This subgroup is much more relevant to the
 work
 that my team is doing than the public Platform Meeting.
 
 So, let's focus on getting technical information to the platform team
 using something like r/MozillaTech.  We can ask the smaller, more
 focused, staff meetings to report on r/MozillaTech (or similar) any
 interesting news.
 
 (btw, mbrubeck... thank you so much for making the MoCo meeting
 accessible to the dozens of people that read it instead of
 watch/listen
 to it.  I am pretty sure you've saved hundreds of engineering hours.)
 
 
 Justin Lebar wrote:
  One thing I love about the MoCo meetings is that if I don't go, I
  don't miss anything except the chance to ask questions: mbrubeckco
  create detailed minutes (really, transcripts) of every meeting,
  which
  I can read on my schedule.  He then e-mails the transcript out to
  everyone, so I don't even have to remember to go looking for it.
 
  Since in-person attendance at the MoCo meetings is non-zero, it
  seems
  clear that some people prefer being in live attendance.  That's
  totally fine.  But at the very least, I think it's useful to
  recognize
  that not everyone is willing or able to attend the meetings live,
  and
  if we think what's going on there is important, we should make an
  effort to broadcast it to a larger audience.
 
  Last time I checked the wiki isn't a canonical record of the
  engineering meeting's contents, and last time I checked there's no
  way
  to get notified when a meeting's notes are up (via RSS or e-mail or
  whatever).
 
  On a related note, I think the engineering meeting is a bad place
  for
  having discussions or debating decisions.  Inevitably, many of the
  people in attendance won't care about this particular issue, so
  we're
  just wasting their time.  And similarly, at our current numeric and
  geographic scale it's inevitable that people who do care about the
  issue won't be in attendance at the meeting and thus won't be able
  to
  participate.  I think therefore that discussions / debates are
  better-suited for our newsgroups or for smaller meetings.
 
  -Justin
 
  On Wed, Apr 24, 2013 at 2:26 PM, Lawrence
  Mandellman...@mozilla.com  wrote:
  tl;dr
  I would like to make the platform meeting more relevant for
  engineers. I have already made some changes (see below) and am
  interested in your feedback on what you would like to get out of
  this meeting. If you don't currently attend, what would make this
  meeting relevant for you?
 
  ---
  Since taking over management of the Platform meeting in February,
  my goal has been to make it more engineer driven and more
  relevant to the day-to-day activities of engineers. I think that
  there is value in having a forum for Mozilla's engineers to speak
  with one another on a regular basis. However, with the size of
  Mozilla's engineering base, creating a useful forum is a
  challenge.
 
  Some of the changes that we've made are:
 
  - Engineers are once again doing the talking - Many of the
  technical updates were being given by project managers. No more.
  Updates for engineers, by engineers. So far, I think this has
  been successful in changing the tone of the meeting.
 
  - More talk about work in progress - Reporting about completed
  work is great. However, we are now also talking about active
  projects. I think work that touches common sections of the code
  base or work that is likely to impact other teams is especially
  useful to flag.
 
  - Identify topics that are stalled / need more attention - Over
  the last month I have seen a new focus on stability and orange
  factor issues. I have also seen a number of calls for help in
  identifying the source of issues.
 
  - Invite other teams to speak with engineering - I invited Sheppy
  to join us to discuss documentation. I would encourage the
  invitation of other teams with which we collaborate to join the
  meeting for specific topics.
 
  - Flag important discussions from across Mozilla's mailing lists -
  A number of people have commented to me that there are too many
  

Re: Increasing the platform meeting's relevance for engineers

[Lawrence Mandel]

- Original Message -

 On Thu, Apr 25, 2013 at 8:02 AM, Lawrence Mandel 
 lman...@mozilla.com  wrote:

  My understanding from speaking with a few people is that the
  platform
  meeting was once useful to engineers.
 
 Well, part of that probably has to do with the fact that Mozilla used
 to be a much smaller org. In 2008 most of platform engineering could
 fit into a single room (with folks like roc and sayre on the phone)
 and hash out actual issues with some approximation of consensus. I
 just doing think that's really feasible anymore.

The size of the org definitely plays a role. We can't go back to what we once 
had. If there is to be an engineer specific meeting, we will need to think 
about what that would look like and what value it would add today. 

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

Increasing the platform meeting's relevance for engineers

[Lawrence Mandel]

tl;dr
I would like to make the platform meeting more relevant for engineers. I have 
already made some changes (see below) and am interested in your feedback on 
what you would like to get out of this meeting. If you don't currently attend, 
what would make this meeting relevant for you? 

---
Since taking over management of the Platform meeting in February, my goal has 
been to make it more engineer driven and more relevant to the day-to-day 
activities of engineers. I think that there is value in having a forum for 
Mozilla's engineers to speak with one another on a regular basis. However, with 
the size of Mozilla's engineering base, creating a useful forum is a challenge. 

Some of the changes that we've made are:

- Engineers are once again doing the talking - Many of the technical updates 
were being given by project managers. No more. Updates for engineers, by 
engineers. So far, I think this has been successful in changing the tone of the 
meeting.

- More talk about work in progress - Reporting about completed work is great. 
However, we are now also talking about active projects. I think work that 
touches common sections of the code base or work that is likely to impact other 
teams is especially useful to flag.

- Identify topics that are stalled / need more attention - Over the last month 
I have seen a new focus on stability and orange factor issues. I have also seen 
a number of calls for help in identifying the source of issues.

- Invite other teams to speak with engineering - I invited Sheppy to join us to 
discuss documentation. I would encourage the invitation of other teams with 
which we collaborate to join the meeting for specific topics.

- Flag important discussions from across Mozilla's mailing lists - A number of 
people have commented to me that there are too many lists to track. This 
meeting is an opportunity to surface key online discussions to ensure they have 
the participation of the right people and reach a conclusion.

Some other suggestions are:

- A review of best practices and anti-pattens in order to build the technical 
vitality of the Mozilla engineering organization.

- More involvement by more people. The product and project sections of the 
agenda do not have a specific owner. You can bring up any related work wherever 
you think it makes sense. There are also the catchall sections Key Issues and 
Roundtable if you are not sure where your update belongs.

I want this meeting to be relevant for you. However, I am just a steward for 
this meeting. I need your help. Why do you attend the platform meeting? If you 
previously attended the meeting, why did you stop? Do you have ideas to make 
the Platform meeting more useful?

Thanks,

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

Re: Increasing the platform meeting's relevance for engineers

[Lawrence Mandel]

- Original Message -
 One thing I love about the MoCo meetings is that if I don't go, I
 don't miss anything except the chance to ask questions: mbrubeck co
 create detailed minutes (really, transcripts) of every meeting, which
 I can read on my schedule.  He then e-mails the transcript out to
 everyone, so I don't even have to remember to go looking for it.
 
 Since in-person attendance at the MoCo meetings is non-zero, it seems
 clear that some people prefer being in live attendance.  That's
 totally fine.  But at the very least, I think it's useful to
 recognize
 that not everyone is willing or able to attend the meetings live, and
 if we think what's going on there is important, we should make an
 effort to broadcast it to a larger audience.

Good point.

 Last time I checked the wiki isn't a canonical record of the
 engineering meeting's contents, and last time I checked there's no
 way
 to get notified when a meeting's notes are up (via RSS or e-mail or
 whatever).

The wiki does have point form information of the topics raised but is 
definitely not a transcript. The minutes are available as soon as the meeting 
is over. I can create a notification but only if you think that's helpful 
without the transcript.
 
 On a related note, I think the engineering meeting is a bad place for
 having discussions or debating decisions.  Inevitably, many of the
 people in attendance won't care about this particular issue, so we're
 just wasting their time.  And similarly, at our current numeric and
 geographic scale it's inevitable that people who do care about the
 issue won't be in attendance at the meeting and thus won't be able to
 participate.  I think therefore that discussions / debates are
 better-suited for our newsgroups or for smaller meetings.

If this is in response to my comment about flagging mailing list discussions, I 
do this so that people are aware of the active discussions and have the links 
to comment. We have not spent much time discussing any of these items in the 
meeting itself.

Lawrence
 
 -Justin
 
 On Wed, Apr 24, 2013 at 2:26 PM, Lawrence Mandel
 lman...@mozilla.com wrote:
  tl;dr
  I would like to make the platform meeting more relevant for
  engineers. I have already made some changes (see below) and am
  interested in your feedback on what you would like to get out of
  this meeting. If you don't currently attend, what would make this
  meeting relevant for you?
 
  ---
  Since taking over management of the Platform meeting in February,
  my goal has been to make it more engineer driven and more relevant
  to the day-to-day activities of engineers. I think that there is
  value in having a forum for Mozilla's engineers to speak with one
  another on a regular basis. However, with the size of Mozilla's
  engineering base, creating a useful forum is a challenge.
 
  Some of the changes that we've made are:
 
  - Engineers are once again doing the talking - Many of the
  technical updates were being given by project managers. No more.
  Updates for engineers, by engineers. So far, I think this has been
  successful in changing the tone of the meeting.
 
  - More talk about work in progress - Reporting about completed work
  is great. However, we are now also talking about active projects.
  I think work that touches common sections of the code base or work
  that is likely to impact other teams is especially useful to flag.
 
  - Identify topics that are stalled / need more attention - Over the
  last month I have seen a new focus on stability and orange factor
  issues. I have also seen a number of calls for help in identifying
  the source of issues.
 
  - Invite other teams to speak with engineering - I invited Sheppy
  to join us to discuss documentation. I would encourage the
  invitation of other teams with which we collaborate to join the
  meeting for specific topics.
 
  - Flag important discussions from across Mozilla's mailing lists -
  A number of people have commented to me that there are too many
  lists to track. This meeting is an opportunity to surface key
  online discussions to ensure they have the participation of the
  right people and reach a conclusion.
 
  Some other suggestions are:
 
  - A review of best practices and anti-pattens in order to build the
  technical vitality of the Mozilla engineering organization.
 
  - More involvement by more people. The product and project sections
  of the agenda do not have a specific owner. You can bring up any
  related work wherever you think it makes sense. There are also the
  catchall sections Key Issues and Roundtable if you are not
  sure where your update belongs.
 
  I want this meeting to be relevant for you. However, I am just a
  steward for this meeting. I need your help. Why do you attend the
  platform meeting? If you previously attended the meeting, why did
  you stop? Do you have ideas to make the Platform meeting more
  useful?
 
  Thanks,
 
  Lawrence

B2G UA override criteria

[Lawrence Mandel]

(cross posting to dev-platform, dev-b2g, and compatibility - please respond to 
dev-platform)

As a mitigation strategy for sites serving non mobile content to B2G, we added 
a UA override (domain whitelist) mechanism that allows B2G to send a custom UA 
to a specific domain. For example, B2G sends the Fennec UA to maps.google.com. 
The policy of how to add a site to the list is documented [1] but the current 
policy does not include the criteria that makes a site eligible for an UA 
override. I assert that we can't override the entire Web - at this point we 
should admit that the B2G UA itself needs to change.

The initial approach and defacto current eligibility criteria is to limit the 
whitelist to the top 100 domains for target B2G locales. In support of this, UA 
overrides were added for sites in the top 100 Alexa ranking for specific target 
locales. However, there have been a number of UA override requests for domains 
that do not meet this criteria. I thought that it would be best to take this to 
the list to ensure that the discussion has a forum and that we reach a decision 
on the whitelist criteria. Some specific criteria to think about:

1. Should we continue to enforce a top sites threshold? If so, is 100 the right 
number? Is it reasonable to rely on Alexa data?
2. Should we limit the whitelist to target B2G locales? Should we accept 
overrides for any locale?
3. Should we limit the overall size of the whitelist? Are the 
technical/performance implications?

Lawrence

[1] https://wiki.mozilla.org/Evangelism/UA_Override_List_Policy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Update your Snappy status for Jan 17

[Lawrence Mandel]

Please share your Snappy status on the etherpad by EOD Thursday.

https://etherpad.mozilla.org/snappy

Thanks,

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

Snappy Meeting, Thurs Jan 10, 11am PT

[Lawrence Mandel]

Reminder: Snappy meetings are now held in the Performance Vidyo room.

The Snappy meeting is held bi-weekly to discuss issues with Firefox 
responsiveness and the various responsiveness initiatives that are underway. 
This week is a Snappy meeting ON week.

Please add your items and status to the agenda before the meeting.
https://etherpad.mozilla.org/snappy

Dial-in: conference# 99355
US/International: +1 650 903 0800 x92 Conf# 99355
US toll free: +1 800 707 2533 (pin 369) Conf# 99355
Canada: +1 416 848 3114 x92 Conf# 99355 
Vidyo: Performance
Vidyo Guest URL: 
https://v.mozilla.com/flex.html?roomdirect.htmlkey=SxuriCZcSSNL
IRC: #perf 

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

Re: Enabling Telemetry by default on Aurora and Nightly

[Lawrence Mandel]

(Moving this thread over to dev-platform.)

- Original Message -
 El 15/12/12 04:15, Lawrence Mandel escribió:
  We've carefully considered all of the implications of making this
  change and teams across Mozilla have been engaged throughout the
  process. Enabling Telemetry by default in these channels is
  consistent with user expectations associated with helping us fully
  test and evaluate new versions of Firefox. We'll provide notice to
  users of the change via multiple means and disabling Telemetry
  will be a simple process.
 I assume users will be informed about this before downloading
 aurora/nightly (at download page?), and already aurora/nightly users
 will get an in-browser message telling them now it's on by default
 and
 how to turn it off.

Correct on both counts.

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

Enabling Telemetry by default on Aurora and Nightly

[Lawrence Mandel]

(cross posted to governance@ and privacy@)

As I discussed during last week's development meeting and this week's 
coordination meeting, this post is to inform you of the intent to enable 
Telemetry by default on the Aurora and Nightly channels. This is a change that 
I first discussed back in Feb 2012 [1], and that may land as soon as Dec. 19, 
2012.

Most users on Firefox Nightly and Firefox Aurora are developers and highly 
technical users who actively contribute to help us build a more excellent 
browser by providing us with feedback. Enabling Telemetry by default on these 
channels makes it easier for them to do so by allowing Mozilla to better 
identify new issues and regressions early in the development cycle and make 
Firefox a better product.

We've carefully considered all of the implications of making this change and 
teams across Mozilla have been engaged throughout the process. Enabling 
Telemetry by default in these channels is consistent with user expectations 
associated with helping us fully test and evaluate new versions of Firefox. 
We'll provide notice to users of the change via multiple means and disabling 
Telemetry will be a simple process.

More details about this change and the rationale have been summarized in this 
FAQ: https://wiki.mozilla.org/Telemetry/faq

Please respond with questions and comments to dev-platform.

Lawrence

[1] https://wiki.mozilla.org/Firefox/Planning/2012-02-01
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Update your Snappy status for Dec 6 (no meeting this week)

[Lawrence Mandel]

Please share your Snappy status on the etherpad by EOD Thursday.

https://etherpad.mozilla.org/snappy

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

Update your Snappy status for Nov 22 (no meeting this week)

[Lawrence Mandel]

Please share your Snappy status on the etherpad by EOD Thursday.

https://etherpad.mozilla.org/snappy

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

Snappy Meeting, Thurs Nov 1, 11am PT

[Lawrence Mandel]

The Snappy meeting is held bi-weekly to discuss issues with Firefox 
responsiveness and the various responsiveness initiatives that are underway. 
This week is a Snappy meeting ON week.

Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy

Dial-in: conference# 95346
US/International: +1 650 903 0800 x92 Conf# 95346
US toll free: +1 800 707 2533 (pin 369) Conf# 95346
Canada: +1 416 848 3114 x92 Conf# 95346
Vidyo: PBJ
IRC: #perf

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

Snappy Meeting, Thurs. Oct 4, 11am PT

[Lawrence Mandel]

With people off helping B2G let's spend some time this week taking a good look 
at the open projects and the progress that we expect to make in Q4.

Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy

Dial-in: conference# 95346
US/International: +1 650 903 0800 x92 Conf# 95346
US toll free: +1 800 707 2533 (pin 369) Conf# 95346
Canada: +1 416 848 3114 x92 Conf# 95346
Vidyo: PBJ
IRC: #perf

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

Re: Snappy Meeting, Thurs. Oct 4, 11am PT

[Lawrence Mandel]

Correction. PBJ is booked this week. Those in MV should find another room. 
We'll use the ProgramManagement vidyo room.

- Original Message -
 With people off helping B2G let's spend some time this week taking a
 good look at the open projects and the progress that we expect to
 make in Q4.
 
 Please add your items and status to the agenda before the call.
 https://etherpad.mozilla.org/snappy
 
 Dial-in: conference# 95346
 US/International: +1 650 903 0800 x92 Conf# 95346
 US toll free: +1 800 707 2533 (pin 369) Conf# 95346
 Canada: +1 416 848 3114 x92 Conf# 95346
 Vidyo: PBJ
 IRC: #perf
 
 Lawrence
 ___
 dev-planning mailing list
 dev-plann...@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-planning
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] UA Override List Policy

[Lawrence Mandel]

 Sites should be added to the list if/when:

 1) An evangelism bug has been opened and the site has been contacted;

 2) The site has proved unresponsive or unwilling to accommodate us
 (how
 long we wait for this will depend on factors such as the popularity
 of
 the site and the extent of breakage);

 3) There is a specific proposed alternative UA for each broken
 product
 which has minimal changes from the default;

 4) Either: Deep testing (not just the front page) has shown that a UA
 override for that UA in that product leads to a significant UX
 improvement on the site; or we know that the fix works because it
 restores a UA which that product had previously;

 5) The override is only for the broken products;

 6) The entry in the prefs file comes with a comment with a reference
 to
 the bug in question.

 Criterion 2 and criterion 4 are the only ones which could potentially
 lead to significant delay. 4 is unavoidable; we don't want to be
 doing
 an override without checking that it actually improves things. Sites
 required by teams for functional testing or demoing of B2G would have
 a
 very short timeout for criterion 2.

 Sites should be removed from the list, for all active branches (I
 propose: including stable and ESR), once the site has confirmed that
 they have fixed it, or deep testing makes us believe they have.


 Does this strike the right balance?

I think this is a good list. Unless someone has a glaring issue I suggest that 
we run with this list and tweak it in the future if need be. As was raised in 
another response, I expect that as we get closer to the release we will 
continue to lower the bar for #2.

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

Re: Adding hardware tokens to UA string

[Lawrence Mandel]

  3. For v1, we probably need to still stick to the original plan for
  the UA that does include Android in the UA, even though that's
  sub-optimal to receive Android specific content. We should move to
  the optimal UA in long-term though without the platform identifier.
 
 Do we really think we will be able to make this shift post-v1? Surely
 shipping Firefox OS v1 with an Android-containing UA will simply
 embed
 the problem, as lots of sites will assume that the Firefox OS UA
 contains the word Android?

I would prefer to look at the specific problems introduced with the OS agnostic 
UA (drop the Android token) and, if a small subset need a workaround, use the 
whitelist mechanism to solve this for v1.

Note that the Android token is not a silver bullet to fix the mobile Web 
compatibility problem. This is simply one mitigation strategy for obtaining 
mobile content - and, as we've seen on Firefox for Android, the Firefox for 
Android UA still falls very short of the mobile Web content served to the 
Android stock browser and iPhone.

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

Snappy Meeting, Thurs. Sep 20, 11am PT

[Lawrence Mandel]

After our Snappy work week I'm left feeling energized yet sluggish. (MozFlu 
will do that to you.) I look forward to hearing your Snappy updates this 
Thursday at 11am PT.

Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy

Dial-in: conference# 95346
US/International: +1 650 903 0800 x92 Conf# 95346
US toll free: +1 800 707 2533 (pin 369) Conf# 95346
Canada: +1 416 848 3114 x92 Conf# 95346
Vidyo: PBJ
IRC: #perf

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

Update your Snappy status Aug 30 (no meeting this week)

[Lawrence Mandel]

Fair warning, this is a solicitation request. 

I want your Snappy news! Now! Just any news just won't do. Gimme, gimme Snappy 
news from the past week. You amazing individuals who contribute Snappy news to 
the wondrous and sometimes awe inspiring Snappy etherpad will be rewarded 
handsomely with smiles and adulation during next week's Snappy meeting.

Or, please update your status and any open issues to the etherpad by EOD 
Thursday, Aug. 30, 2012.

https://etherpad.mozilla.org/snappy

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

Snappy Meeting, Thurs. Aug 23, 11am PT

[Lawrence Mandel]

We're not the bear we're the fox!
http://www.cartoonstock.com/directory/r/responsive_to_needs_gifts.asp

Join us this Thursday, 11am PT, to discuss Firefox responsiveness.

Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy

Dial-in: conference# 95346
US/International: +1 650 903 0800 x92 Conf# 95346
US toll free: +1 800 707 2533 (pin 369) Conf# 95346
Canada: +1 416 848 3114 x92 Conf# 95346
Vidyo: PBJ
IRC: #perf

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

Re: Preliminary results of aliasing Webkit CSS properties in Gecko analysis

[Lawrence Mandel]

Cross posting to dev-planning to ensure that the planning audience sees these 
preliminary results.

Please post and responses to dev-platform.

- Original Message -
 The Layout, QA, and Market Insight teams recently analyzed the impact
 of aliasing Webkit CSS properties in Gecko with the goal of
 answering the question,
 
 Does aliasing a subset of Webkit CSS properties in Gecko improve
 mobile Web compatibility?
 
 The results thus far indicate that there is a very small benefit of
 adding Webkit CSS aliases to Gecko. However, our research is not yet
 complete, so we will refrain from making any definitive decisions
 until all our research has been carried out.
 
 The consensus from dbaron, jet, jsmith, tchung, aaronmt, jjensen, and
 me is that the value of aliasing Webkit CSS properties in Gecko
 alone appears to be pretty low and the benefit does not warrant its
 inclusion in the platform at this time. The following is an overview
 of our analysis which led us to reach this initial conclusion. There
 are four hurdles that we have to jump in order to receive and render
 Webkit content. These hurdles are listed in increasing technical
 cost:
 
 1. user agent sniffing
 2. Webkit CSS prefixes
 3. DOM/WebAPI aliases
 4. Implementation of missing CSS/DOM/WebAPI features in Gecko
 
 The analysis we conducted focuses on #1 and #2.
 
 Test Fennec build:
 To conduct the analysis, we wanted to compare Fennec builds with and
 without Webkit CSS property aliases. David Baron created a Fennec
 build that included aliases for the following properties, most of
 which we have recently unprefixed (notably text-size-adjust,
 appearance, and user-select have not yet been unprefixed):
 
 -webkit-animation, -webkit-animation-delay,
 -webkit-animation-direction, -webkit-animation-duration,
 -webkit-animation-fill-mode, -webkit-animation-iteration-count,
 -webkit-animation-name, -webkit-animation-play-state,
 -webkit-animation-timing-function, -webkit-appearance,
 -webkit-border-bottom-left-radius,
 -webkit-border-bottom-right-radius, -webkit-border-radius,
 -webkit-border-top-left-radius, -webkit-border-top-right-radius,
 -webkit-background-clip, -webkit-background-origin,
 -webkit-background-size, -webkit-border-image, -webkit-box-shadow,
 -webkit-text-size-adjust, -webkit-transform,
 -webkit-transform-origin, -webkit-transform-style,
 -webkit-transition, -webkit-transition-delay,
 -webkit-transition-duration, -webkit-transition-property,
 -webkit-transition-timing-function, -webkit-user-select. The build
 also includes the following @-rule alias: @-webkit-keyframes.
 
 Test methodology:
 Jason Smith and Aaron Train (QA) tested two lists of sites (more on
 the lists below) using the two Fennec builds and Safari on iPhone.
 In order to alleviate some of the issues due to UA sniffing, both
 Fennec builds were tested using their stock UA and using a spoofed
 iPhone UA (via the Phony add-on). The focus of this testing was to
 identify specific improvements to the user experience of a site,
 such as improved layout, appearance and function.
 
 Site data:
 John Jensen has been analyzing mobile Web compatibility issues,
 specifically related to UA sniffing and Webkit CSS property usage,
 using a tool that he wrote to scrape CSS from the top 18,000 Alexa
 sites. He has built up a database that provides the ability to
 identify sites that make use of Webkit CSS properties without using
 the equivalent moz prefixed or unprefixed properties. The two test
 runs that I will describe below were both conducted using lists
 created from John's site data.
 
 The test runs:
 
 Using the data described above, John created a list of sites that are
 known to use the Webkit CSS properties that David aliased in his
 build without using the equivalent moz or unprefixed properties.
 Aaron and Jason tested the top 20 sites on this list. In these
 tests, the Webkit CSS aliases resulted in 2 sites with improvements
 (Disney and Comcast), 17 sites with no noticeable difference, and
 one site (howtogeek.com) that actually had a degraded layout.
 
 The results of the first run were surprising given that we had
 targeted the specific Webkit CSS properties that David had aliased
 in his build. However, the two sites that had a noticeable
 improvement both make heavy use of Webkit CSS animations and
 transitions. For our second test run John created a new list that
 specifically targeted sites that use Webkit CSS animations and
 transitions without using the equivalent moz prefixed or unprefixed
 properties. The expectation was that this set of sites would see a
 more significant improvement. For this test run Jason and Aaron
 tested 18 sites. In these tests, the Webkit CSS aliases resulted in
 3 sites with improvements (allhiphop, Comcast, and Muslima), 1 site
 with a slight improvement (not enough to make the site usable), and
 14 sites with no noticeable difference.
 
 The results of Jason and Aaron's tests can be seen at