Re: Bringing Marionette and Mochitest closer

to discuss this further via vidyo/skype/irc let me know. I am keep to fix any potential shortcomings in Marionette. David Burns AutomatedTester [1] https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html [2] https://github.com/mozilla/mozbase/tree/master/mozprofile [3] https://github.com

Re: Bringing Marionette and Mochitest closer

Marionette is one of the core frameworks for testing FirefoxOS but works pretty much everywhere since it is part Gecko. You can see it on TBPL with https://tbpl.mozilla.org/?tree=Mozilla-Inboundjobname=marionette for example. David On 30/01/2013 18:33, Benjamin Smedberg wrote: On

Re: Pushes to Backouts on Mozilla Inbound

be a good metric to see if other efforts are paying off. On 11/05/2013 07:09 AM, Ed Morley wrote: On 05 November 2013 14:44:27, David Burns wrote: We appear to be doing 1 backout for every 15 pushes on a rough average[4]. I've been thinking about this some more - and I believe the ratio

Re: js-inbound as a separate tree

Personally I find the branches we have annoying and are papering over the real problem that our feedback cycles once landed are far too long. Just for that reason alone I am against the idea. I think if we can solve the build/test scheduling and being smart about how we do our testing we can

Re: js-inbound as a separate tree

On 19/12/2013 23:56, Jason Orendorff wrote: On 12/19/13 4:55 PM, David Burns wrote: On 19/12/2013 18:48, Jason Orendorff wrote: Con: - more work for sheriffs (mostly merges) If mostly merges, are you suggesting there will be little traffic on the branch or the JS team will watch the tree

Re: Spring cleaning: Reducing Number Footprint of HG Repos

What are mission critical repos since you just put everything in the same list? If we start removing project branches to be put on outsourced VCS we remove any sheriff support for that project branch since, as been pointed out many times, we dont have access to the server side commit hooks

Re: Is XPath still a thing?

On 14/04/2014 22:28, Eric Shepherd wrote: I think I know the answer to this, but want to confirm: is XPath a going concern? We want to be sure of its current status before migrating its documentation to where it ought to be assuming that it is in fact something people still use. XPath is

Re: Is XPath still a thing?

Not from my side! David On 14/04/2014 22:41, Eric Shepherd wrote: On 2014-04-14 21:38:24 +, David Burns said: XPath is still a going concern from where I stand. Web Testing people, who use Selenium WebDriver, use XPath extensively since they struggle to get to have testable documents

Tree Closure Stats - May 2014

Hi Everyone, (cross posted to dev-platform) Below is the stats for Tree Closures for the main trees that the sheriffs manage. Please feel free to let me know if you have any questions. _Mozilla Inbound _Closures due to test failures on Inbound are slightly higher than normal. 2014-05

Tree Closure Stats - June 2014

Hi Everyone, (cross posted to dev-platform) Below is the stats for Tree Closures for the main trees that the sheriffs manage. Please feel free to let me know if you have any questions._ _A lot of the backlog numbers were down to there being AWS machines not picking up jobs fast enough.

Tree Closure Stats - July 2014

Hi Everyone, (cross posted to dev-platform) Below is the stats for Tree Closures for the main trees that the sheriffs manage. Please feel free to let me know if you have any questions._ Mozilla-Inbound _ 2014-07 checkin-compilation: 1 day, 1:19:41 checkin-test: 1 day, 2:44:14

Re: Tree Closure Stats - July 2014

in the recent past seemed to have peaked in April and have been declining since. Do you have any idea what we've been doing right? I am always uncomfortable with good results that I don't understand! Thanks a lot for sending these out! On 2014-08-04, 5:42 PM, David Burns wrote: Hi Everyone

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

I know this is tangential but the small changes are the least tested changes in my experience. The try push requirement for checkin-needed has had a wonderful impact on the amount of times the tree is closed[1]. The tree is less likely to be closed these days. David [1]

Marionette Mailing List

Hi Everyone! Marionette now has it's own mailing list[1] that allows us to be able to send a message to one place that is open for anyone to send to. We can use it to discuss changes that are happening in the WebDriver spec, breaking changes we want to do and for releases. Please join the

Re: Screen Capture

On 23/10/2014 22:10, Jet Villegas wrote: Roc wrote up a proposal last year for a web-facing screen capture API: https://wiki.mozilla.org/User:Roc/ScreenCaptureAPI Even if not web-facing, we could use the implementation code to cover chrome use cases like this one:

Re: Capturing additional metadata in moz.build files

The last bullet for me is the killer feature. I recently hit an issue where I made some fairly big change to an API and updated all the consumers that I was aware and even ran a try push for the happy set. Unfortunately this burnt the tree. I see this situation as a bigger waste of resources

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

Well done Sheriffs! Really proud of all the work you did this year! David On 30 December 2015 at 14:19, Carsten Book wrote: > Hi, > > Sheriffing is not just about Checkins, Uplifts and Backouts - its also a > lot of teamwork with different Groups and our Community like

Re: Dan Stillman's concerns about Extension Signing

Another data point that we seem to have overlooked is that users want to be able to side load their extensions for many different reasons. We see this with apps on phones and with extensions currently. I appreciate that users have grown to be warning blind but, as others have pointed out, this

Re: Basic Auth Prevalence (was Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies)

Is there a way that we can gather if people are using this for testing web sites? This might account for those numbers. For example, there is basic support, and I mean really basic support, in Selenium to handle Basic auth and we suggest to people that setting up a proxy in the middle to handle

Build System Project - Latest Update

Below is a highlight of all work the build peers have done since the last report[1]. We have reduced the time it takes to run reftests as well as the amount of I/O that happens during the tests by disabling some features in Firefox that are not used during the test. This has saved over 50GB of

Re: Taking screenshots of single elements (XUL/XULRunner)

You can try getting access to https://dxr.mozilla.org/mozilla-central/source/testing/marionette/capture.js and then that will give you everything you want or you can just "borrow" the code from there. David On 19 January 2016 at 11:22, Ted Mielczarek wrote: > On Tue, Jan

Build System Project - Update from the last 2 weeks

Below is a highlight of all work the build peers have done in the last 2 weeks as part of their work to modernise the build infrastructure. Since the last report[1] a large number of improvements have landed in Mozilla Central. The build system now lazily installs test files. Before, the build

Build System Project - Update from the last 2 weeks

Below is a highlight of all work the build peers have done in the last 2 weeks as part of their work to modernise the build infrastructure. Since the last report[1] we have seen thousands of lines of configure and m4 code removed from mozilla-central. We have removed over 30 Makefiles from

Report from Build Team Sprint

d data. There was also work to see if we can get speed ups by using different versions of compilers. We are noticing huge gains by upgrading to newer versions but some of the upgrades require some work before we can deploy them. When we are looking to do the upgrade we will email the list to warn you. David

Build System Project - Update from the last 2 weeks

Below is a highlight of all work the build peers have done in the last 2 weeks as part of their work to modernise the build infrastructure. Since the last report[1] a large number of improvements have landed in Mozilla Central. We have landed some more build improvements that have brought down

Build System Project - Update from the last 2 weeks

Below is a highlight of all work the build peers have done in the last 2 weeks as part of their work to modernise the build infrastructure. Since the last report[1] a large number of improvements have landed in Mozilla Central. We have been experimenting with making a global cache available to

Build System Project - Latest Update

Below is a highlight of all work the build peers have done since the last report[1]. The build peers have been working to get faster builds in automation as well as well as local developers. We are currently testing the distributed cache rewrite (sccache) to make sure that we have not regressed

Re: Faster gecko builds with IceCC on Mac and Linux

Yes! Part of the build project work that I regularly email this list[1] we have it on our roadmap to have the same distributed cache that we use in automation available for engineers who are working on C++ code. We have completed our rewrite and will be putting the initial work through try over

Build System Project - Latest Update

Below is a highlight of all work the build peers have done since the last report[1]. The build peers have been working to get faster builds in automation as well as well as local developers. We have updated the way that Taskcluster decision and linting jobs use version control[2]. This has driven

Re: Please don't abuse "No bug" in commit messages

Ideally we would be doing it in a way that we can audit things quickly in the case we think a bad actor has compromised someone's machine. While we can say what we want and how we want the process, we need to work with what we have until we have a better process. This could be between now and the

Re: Please don't abuse "No bug" in commit messages

I have raised a bug[1] to block these types of commits in the future. This is an unnecessary risk that we are taking. I also think that we need to remove this as acceptable practice from the MDN page. David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1336459 On 3 February 2017 at 15:11,

Re: Proposed change to Commit Access Policy Level 3

Looks great to me! David On 4 August 2016 at 06:20, 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

Build System Project - Latest Update

Below is a highlight of all work the build peers have done since the last report[1]. The build peers have been working to get faster builds in automation as well as for local developers. We have landed changes to stop generating XPIDL sources in artifact builds[2], which is a performance and

Build System Project - Latest Update

Below is a highlight of all work the build peers have done in the last few weeks as part of their work to modernise the build infrastructure. Since the last report[1] a large number of improvements have landed in Mozilla Central. The build peers have managed to get numerous patches landed for

Build System Project - Latest Update

Below is a highlight of all work the build peers have done in the last few weeks as part of their work to modernise the build infrastructure. Since the last report[1] a large number of improvements have landed in Mozilla Central. The build peers have landed support for a new construct in python

Re: unowned module: Firefox::New Tab Page, help me find an owner

On 22 March 2017 at 13:49, Ben Kelly wrote: > On Wed, Mar 22, 2017 at 9:39 AM, 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

Re: The future of commit access policy for core Firefox

As the manager of the sheriffs, I am in favour of this proposal. The reasons why are as follow (and to note there are only 3 paid sheriffs to try cover the world): * A number of r+ with nits land up in the sheriffs queue for checkin-needed. This then puts the onus on the sheriffs, not the

Re: Sheriff Highlights and Summary in February 2017

I went back and did some checks with autoland to servo and the results are negligible. So from 01 February 2017 to 10 March 2017 (as of sending this email). I have removed merge commits from the numbers. Autoland: Total Servo Sync Pushes: 152 Total Pushes: 1823 Total Backouts: 144 Percentage of

Re: Sheriff Highlights and Summary in February 2017

One thing that we have also noticed is that the backout rate on autoland is lower than inbound. In the last 7 days backout rate is averaging (merges have been removed): - Autoland 6%.(24 backouts out of 381 pushes) - Inbound 12% (30 backouts out of 251 pushes) I don't have graphs to show

Re: Sheriff Highlights and Summary in February 2017

as to why there is a difference. David On 7 March 2017 at 12:57, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 3/7/17 6:23 AM, David Burns wrote: > >>- Autoland 6%.(24 backouts out of 381 pushes) >>- Inbound 12% (30 backouts out of 251 pushes) >> > >

Fwd: Web Compatibility Testing Survey

Hi All, If you are working on web exposed features could you please take a few minutes to complete the survey. This will help us prioritize work on Web Platform Tests which helps us with our web compatibility story. David -- Forwarded message -- From: Date:

Re: Implementing a Chrome DevTools Protocol server in Firefox

Do we know if the other vendors would see value in having this spec'ed properly so that we have true interop here? Reverse engineering seems like a "fun" project but what stops people from breaking stuff without realising? David On 30 August 2017 at 22:55, Michael Smith

Re: Implementing a Chrome DevTools Protocol server in Firefox

I don't think anyone would disagree with the reasons for doing this. I, like James who brought it up earlier, am concerned that we from the emails appear to think that implementing the wire protocol would be sufficient to making sure we have the same semantics. As mentioned by Karl earlier, it

Re: Next year in web-platform-tests

On 15 December 2017 at 21:29, smaug wrote: > > Not being able to send (DOM) events which mimic user input prevents > converting > many event handling tests to wpt. > Not sure if WebDriver could easily do some of this, or should browsers > have some testing mode which exposes >

Re: Intent to require Python 3 to build Firefox 59 and later

I am not saying it should but if we have a requirement for python 3, we are also going to have a requirement for py2 to both be available for local development. David On 11 November 2017 at 14:10, Andrew Halberstadt <ahalberst...@mozilla.com> wrote: > On Fri, Nov 10, 2017 at 9:44 PM Da

Intent to unship: Linux 32bit Geckodriver executable

For the next version of geckodriver I am intending that it not ship a Linux 32 bit version of Geckodriver. Currently it accounts of 0.1% of downloads and we regularly get somewhat cryptic intermittents which are hard to diagnose. *What does this mean for most people?* We will be turning off the

Re: Intent to unship: Linux 32bit Geckodriver executable

Answered inline below. On 21 November 2017 at 19:03, Nicholas Alexander <nalexan...@mozilla.com> wrote: > > > On Tue, Nov 21, 2017 at 5:25 AM, David Burns <dbu...@mozilla.com> wrote: > >> For the next version of geckodriver I am intending that it not shi

Re: Intent to require Python 3 to build Firefox 59 and later

My only concern about this is how local developer environments are going to be when it comes to testing. While I am sympathetic to moving to python 3 we need to make sure that all the test harnesses have been moved over and this is something that needs a bit of coordination. Luckily a lot of the

Re: Intent to Ship: Shadow DOM and Custom Elements

Do we have sufficient tests for this to guarantee webcompat and interop with other browsers? David On 10 August 2018 at 15:49, smaug wrote: > I'm planning to keep Shadow DOM and Custom Elements turned on on > beta/release builds. > Target release is Firefox 63. > prefs are

Re: Intent to implement and ship: Referrer Policy for CSS

Are there web platform tests for this feature? David On Fri, 5 Oct 2018 at 13:32, Christoph Kerschbaumer wrote: > We just realized we have never sent an intent to implement and ship for > extending coverage of Referrer Policy to style sheets. Please accept my > apology for not sending the

Re: Intent to ship: unprefixed max-content and min-content for css sizing properties

Are there any web platform tests for this feature? David On Tue, 2 Oct 2018 at 20:49, Boris Chiou wrote: > Summary: > `max-content` and `min-content` are sizing values for width, min-width, > max-width, height, min-height, max-height, inline-size, min-inline-size, > max-inline-size, and

Closure of #ateam irc channel

For the last 2 years the Automation and Tools team (#ateam) has not existed as a single function as parts of the team were split up between Firefox Engineer Operations and Product Integrity. As traffic in #ateam has dropped it is time to close this irc channel and request people go to more

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

Thanks for this Philip. I have started raising bugs and blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1498357. David On Fri, 14 Dec 2018 at 08:41, Philip Jägenstedt wrote: > On Fri, Oct 19, 2018 at 2:42 PM Philip Jägenstedt > wrote: > > > > On Wed, Oct 17, 2018 at 11:53 PM Boris

Re: Intent to implement: report-to header as part of Reporting API

On Thu, 10 Jan 2019 at 12:27, Andrea Marchesini wrote: > web-platform-tests: just a little support. I wrote several mochitests which > can be converted to WPTs with a bit of effort. > There don't appear to be any WPT if I am looking in the right place[1]. Since Google are experimenting it feels

Re: Intent to ship: Visual Viewport API on Android

Not yet as we are stabilising tests for gecko view but hopefully soon! David On May 10, 2019, 7:22 PM +0100, Botond Ballo , wrote: > On Thu, May 9, 2019 at 7:50 AM David Burns wrote: > > There are a number of wpt that fail only in firefox. Are we planning on > > fix

Re: Intent to ship: Visual Viewport API on Android

There are a number of wpt that fail only in firefox[1]. Are we planning on fixing those tests with this work? David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1546387 On Thu, 9 May 2019 at 01:41, Botond Ballo wrote: > Hi everyone! > > I would like to ship the Visual Viewport API [1] on

Re: Intent to ship: CSS 'display:block ruby'

Are there any web platform tests for this or will they be added as part of this work? David On Wed, 14 Aug 2019 at 17:38, Mats Palmgren wrote: > Summary: > Add support for 'display:block ruby' which creates a block box > with a ruby box inside it. > > Bug:

Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

On Jul 25, 2019, 12:23 PM +0200, Tom Schuster , wrote: > On Wed, Jul 24, 2019 at 3:21 AM Boris Zbarsky wrote:> > > On 7/22/19 6:22 AM, Tom Schuster wrote: > > > This was also discussed at https://github.com/whatwg/html/issues/3255. > > > It seems like Chrome does NOT plan on shipping this at the

Re: Intent to prototype: Web Share Target

On Fri, 4 Oct 2019 at 03:30, wrote: > > > Web-platform-tests: requires manual tests. > Is this something that we could be tested with testdriver.js inside wpt? David ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Visibility of disabled tests

I think a lot of the problem is not necessarily a technical issue, meaning I am not sure that tooling will solve the problem, but it is more of a social problem. I think the problem is making sure that items are triaged and placed into peoples workflow sooner would solve this problem but I also