Re: Talos - Replacing tscroll,tsvg with tscrollx,tsvgx
On 7/23/2013 6:22 PM, Avi Halachmi wrote: TL;DR: Talos tsvg,tscroll are affected by timing much more than by rendering performance because they don't stress Firefox. tsvgx,tscrollx stress firefox: their results are different, better, noisier than the old tests. Will soon replace the old tests. I just wanted to say thanks for actually digging into these tests and finding a way to change them to measure what you care about. We have a *lot* of Talos tests that get run and they're not always strongly-owned, so making sure the data they generate is useful is an extremely valuable task. I wish all of our Talos tests would get this kind of scrutiny! -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Rendering meeting, Monday 2:30pm PDT - special topic
The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm PDT. The next meeting will take place today, Monday, July 29 at 2:30 PM US/Pacific The agenda is here: https://wiki.mozilla.org/Platform/GFX/2013-July 29#Agenda We will use this meeting for a special presentation, as the only agenda item: Akshay Agarwal manages the ARM Mali GPU Ecosystem in the US. He's coming to San Francisco to give an update on their roadmap/tools and also on a recent Skia summit he organized in Cambridge. He'll be here to discuss potential ways we can collaborate. San Francisco - Monday, 2:30pm Winnipeg - Monday, 4:30pm Toronto - Monday, 5:30pm GMT/UTC - Monday, 21:30 Paris - Monday, 11:30pm Taipei - Tuesday, 5:30am Auckland - Tuesday, 9:30am Video conferencing: Vidyo room Graphics (9366) https://v.mozilla.com/flex.html?roomdirect.htmlkey=vu1FKlkBlT29 Phone conferencing: +1 650 903 0800 x92 Conf# 99366 +1 416 848 3114 x92 Conf# 99366 +1 800 707 2533 (pin 369) Conf# 99366 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WebAPI Meeting: **NEW TIME** Tuesday 30 July @ *8* AM Pacific [1]
We're moving the meeting 2 hours earlier! 8 AM in California 11 AM in Toronto and New York, etc. 16:00 in the UK and Portugal 17:00 in most parts of Europe 23:00 in Taipei http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130730T08p1=224am=30 Meeting Details: * Agenda: https://etherpad.mozilla.org/webapi-meetingnotes * WebAPI Vidyo room * A room we can find, San Francisco office * Spadina conf. room, Toronto office * Allo Allo conf. room, London office * Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL) * US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US) * Join irc.mozilla.org #webapi for back channel All are welcome. Andrew [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130730T08p1=224am=30 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOM Bindings Meeting - Monday @ 12:30 PM PDT
Our (ostensibly) weekly DOM bindings meetings continue on Monday July 29th at 12:30 PM PDT. Meeting details: * Monday, July 29, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST) * Conference room 7-N, San Francisco office, 7th floor. * Dial-in Info: - Vidyo room: Boris Zbarsky - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference number 9235 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RE-SCHEDULED] Re: Enabling mozharness for talos for FF25 projects
This will be going live tomorrow Tuesday 30th. On 2013-07-23 4:38 PM, Armen Zambrano G. wrote: I need these new changesets to spread across the FF25 trees before going ahead with this: https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4ab37e3f3e https://hg.mozilla.org/integration/mozilla-inbound/rev/496a7582cf9e I'm postponing this until Monday. Sorry for the noise. I want to make sure that it all goes as expected. cheers, Jason Armen On 2013-07-22 2:44 PM, Armen Zambrano G. wrote: Last week we enabled mozharness for talos on the try server and we have resolved all found issues since then. The issues were related to proper integration with tbpl and talos's try support. We will switch talos jobs to be driven by mozharness rather than through buildbot by Wednesday morning in the morning of EDT. I assume that changeset 3d1c2ca7efe8 is already on your local checkout after a week being in the tree but worth raising it up again. There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. regards, Jason Armen [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 On 2013-07-16 8:51 AM, Armen Zambrano G. wrote: Hi, We have recently been working hard to separate the buildbot logic that runs our talos jobs on tbpl to its own separate script (using mozharness). [1][2] This has the advantage of permitting anyone (specially the a-team) to adjust how our harnesses run talos inside of our infrastructure without having to set up buildbot (which is what currently runs our talos jobs). This also permits anyone to run the jobs locally in the same manner as Releng's infrastructure. This also allows for further development and flexibility on how we configure the jobs we run. Initially, we will enable it on the try server today to see production-like load. So far, it's been looking great on Cedar. [3] The only gotcha is that there will be a small performance hit for the ts tests that we are willing to take. [4] There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. Once we get a couple of days worth of load on the try server and see nothing new we will go ahead and enable it for every m-c based repository. If you have any questions/concerns please write a comment on bug 713055. Best regards, Jason Armen Release Engineering [1] https://bugzilla.mozilla.org/show_bug.cgi?id=713055 [2] https://developer.mozilla.org/en-US/docs/Mozharness_FAQ [3] https://tbpl.mozilla.org/?tree=Cedarjobname=talos [4] https://bugzilla.mozilla.org/show_bug.cgi?id=802801#c10 [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Rethinking separate Mercurial repositories
I don't particularly care for our model of a single Mercurial repository per logical entity. I think it makes sense for things like twigs and to some extent integration repositories - you can do your work in your own little world without disrupting others. But for all the release branches, I think the model is suboptimal. I'm proposing that we merge all the release repositories (central, aurora, beta, release, esr, and b2g) into a single Mercurial repository. The default branch/bookmark of this repository would be the equivalent of mozilla-central. At train uplift time, we create a new branch (or bookmark) called gecko-N (or similar) where N is the core gecko/platform release version. If default/central is on 25, Aurora changes land in gecko-24, Beta in gecko-23, etc. These could be supplemented with build and release tags/branches as appropriate. A benefit of this model is it introduces a linear repository history for release branches. Contrast this with today, where we do non fast-forward pushes at uplift time as a new default head becomes aurora, beta, etc. gecko-25 is always Firefox 25 as it rides the trains: it doesn't go through an identity crisis as it crosses channels. Another benefit is it's a single repository. Wouldn't it be nice to have the full history of all landings for released code in one unified location rather than spread out over multiple repositories? I think it would. I know it would have better performance characteristics than maintaining multiple repos (reducing round trips, data duplication, etc). These are all reasons I've switched to a monolithic/unified repository for local development (just like the Github mirror). A downside of this approach (other than that it is work to change) is people may not realize which version aurora, beta, etc are on. However, that can easily be corrected with tools. e.g. |hg land beta| or even having friendly channel tags/aliases mirroring the core version numbers. Anyway, I believe the decisions on repository structure were made many years ago, apparently due to limitations in now ancient versions of Mercurial. Times have changed. I think we should revisit old decisions. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking separate Mercurial repositories
On 7/29/2013 1:43 PM, Gregory Szorc wrote: I don't particularly care for our model of a single Mercurial repository per logical entity. I think it makes sense for things like twigs and to some extent integration repositories - you can do your work in your own little world without disrupting others. But for all the release branches, I think the model is suboptimal. I'm proposing that we merge all the release repositories (central, aurora, beta, release, esr, and b2g) into a single Mercurial repository. The default branch/bookmark of this repository would be the equivalent of mozilla-central. At train uplift time, we create a new branch (or bookmark) called gecko-N (or similar) where N is the core gecko/platform release version. If default/central is on 25, Aurora changes land in gecko-24, Beta in gecko-23, etc. These could be supplemented with build and release tags/branches as appropriate. A benefit of this model is it introduces a linear repository history for release branches. Contrast this with today, where we do non fast-forward pushes at uplift time as a new default head becomes aurora, beta, etc. gecko-25 is always Firefox 25 as it rides the trains: it doesn't go through an identity crisis as it crosses channels. Another benefit is it's a single repository. Wouldn't it be nice to have the full history of all landings for released code in one unified location rather than spread out over multiple repositories? I think it would. I know it would have better performance characteristics than maintaining multiple repos (reducing round trips, data duplication, etc). These are all reasons I've switched to a monolithic/unified repository for local development (just like the Github mirror). A downside of this approach (other than that it is work to change) is people may not realize which version aurora, beta, etc are on. However, that can easily be corrected with tools. e.g. |hg land beta| or even having friendly channel tags/aliases mirroring the core version numbers. Anyway, I believe the decisions on repository structure were made many years ago, apparently due to limitations in now ancient versions of Mercurial. Times have changed. I think we should revisit old decisions. I'm certain that we would do things differently if we had it to do over from scratch. But that there is enough reward here to be worth making a change. A perhaps-obvious downside to making any change here is that it will require the releng machinery to change significantly: instead of checking out the aurora/beta branch, at every merge point something will have to be configured to check out a new branch/bookmark. You've already demonstrated that any user who wants can already have the single repository benefit by pulling multiple release repos into one local tree. Given all the things that we could be doing instead, why is this important to do now? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
Intent to implement seems premature. Why wouldn't we wait to see how this goes and let Google do that. I really dislike the idea of rushing into this API. A programatic API that does something like AppCache is a good idea -- only in that it is better than the declarative shit AppCache is. We know (have data, getting more) that AppCache isn't used by the top 50k sites (it is probably only used in WebApps). IMO, We need more data to show that this API is more important than the n number of other things Mozilla wants to implement. I would feel much better if we continued to monitor this api and not rush here. Let Google do the rushing, lets implement later. Didn't Jonas have a proposal for the 'offline' use case? Regards, Doug Ehsan Akhgari wrote: We're planning to implement a prototype of the NavigationController interface (see bug 898524). We will try to get feedback from web developers on the prototype and will use that feedback to change the spec and the implementation and iterate on the API. Our major goal for now is coming up with a good API that is useful for the intended use cases. Once we're there, we will talk about plans to ship the API. For now, all of this work will be disabled for web content. Please let me know if you have any questions! Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On 2013-07-29 2:46 PM, Doug Turner wrote: Intent to implement seems premature. Why wouldn't we wait to see how this goes and let Google do that. I really dislike the idea of rushing into this API. What is the reason you think we should not implement this? We're not exactly rushing into *shipping* anything here. A programatic API that does something like AppCache is a good idea -- only in that it is better than the declarative shit AppCache is. We know (have data, getting more) that AppCache isn't used by the top 50k sites (it is probably only used in WebApps). IMO, We need more data to show that this API is more important than the n number of other things Mozilla wants to implement. The main reason why we're looking into this API is better offline support for web applications. I believe that this is the best proposal that anybody has in hand, and we need to prototype in order to make sure that this API is something that we want to support, and that it's not broken in similar ways to AppCache. I would feel much better if we continued to monitor this api and not rush here. Let Google do the rushing, lets implement later. I'm still not sure what we're rushing into here. Didn't Jonas have a proposal for the 'offline' use case? Yes, he has proposed a declarative solution, which should be possible to implement on top of NavigationController. That is in fact one of our litmus tests for the viability of this API. Cheers, Ehsan Ehsan Akhgari wrote: We're planning to implement a prototype of the NavigationController interface (see bug 898524). We will try to get feedback from web developers on the prototype and will use that feedback to change the spec and the implementation and iterate on the API. Our major goal for now is coming up with a good API that is useful for the intended use cases. Once we're there, we will talk about plans to ship the API. For now, all of this work will be disabled for web content. Please let me know if you have any questions! Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking separate Mercurial repositories
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote: Given all the things that we could be doing instead, why is this important to do now? I share Benjamin's concern. Also, before we can discuss this, we need to make sure that every Mercurial command handles bookmarks sanely. Last I checked, things such as hg push did not do that (IIRC push just pushes everything on the named branch you're on by default.) Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Mon, Jul 29, 2013 at 11:46 AM, Doug Turner doug.tur...@gmail.com wrote: I would feel much better if we continued to monitor this api and not rush here. Let Google do the rushing, lets implement later. Didn't Jonas have a proposal for the 'offline' use case? We did discuss at the last meeting. This API is the way toward making offline work and giving developers full control over that. Jonas' proposal offers a subset of the functionality. The current thinking is that offering developers the primitives will give us a better higher level API longer term. Offline not working seems like the #1 problem of the web platform, so working on this API does not really feel premature to me. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking separate Mercurial repositories
On 7/29/13 12:49 PM, Ehsan Akhgari wrote: On 2013-07-29 2:06 PM, Benjamin Smedberg wrote: Given all the things that we could be doing instead, why is this important to do now? I share Benjamin's concern. Legit concern. Probably low priority. I wanted to have a discussion on it because I suspect it will be an issue down the road. e.g. it sounds like things in Git land [1] may force the issue. Also, before we can discuss this, we need to make sure that every Mercurial command handles bookmarks sanely. Last I checked, things such as hg push did not do that (IIRC push just pushes everything on the named branch you're on by default.) If you are referring to applied mq patches, if you use [mq] secret=True (recommended but not the default in Mercurial due to backwards compatibility), this will set the phase of applied mq patches to secret (as opposed to draft) which will prevent them from being pushed. This will muck with try pushes and you'll need an extension to work around this limitation - something I've been meaning to add to my new Mercurial extension! I do concede push does have some additional wacky behavior, but it's mostly around creating new bookmarks/branches/heads. Things also get much weirder when you start pulling from multiple repos locally, as Mercurial will try to push all non-remote changesets unless a specific revision is specified. I created a pushtree command [2] in my custom Mercurial extension to make this more intuitive. But the latter isn't a concern if the local clone mirrors the single remote. [1] http://escapewindow.dreamwidth.org/238476.html [2] https://hg.mozilla.org/users/gszorc_mozilla.com/hgext-gecko-dev/file/280d1ef3b017/__init__.py#l282 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
Do you think that NC is the right soluction here? Anne van Kesteren wrote: Offline not working seems like the #1 problem of the web platform, There are lots of problems with the web platform. Offline support is one of them, yes. :) so working on this API does not really feel premature to me. My issue wasn't if we were going to work on the 'off-line' problem or not. It was mostly around stating we're going to implement prematurely. It might be I don't really understand what the Intent to implement blink-like emails really mean.. if you say this, when is it going to show up in a FF release? Doug ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
Implementation detail, but I presume that you will also replace the existing appcache impl with NC, right? Ehsan Akhgari wrote: Offline not working seems like the #1 problem of the web platform, so working on this API does not really feel premature to me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
