Re: running tests in HiDPI mode on the build machines
Asa Dotzler wrote: Testing the only Firefox platform that isn't on the above list? Wouldn't it be smarter to test on Windows 7 or some combination of Windows machines where almost all of our users are? If we've got the resources for it, sure. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar justin.le...@gmail.comwrote: If I can propose something that's perhaps different: 1) Write software to figure out who's slow with reviews. 2) We talk to those people. We've done this before too. But we should just do it again --- the definition of insanity aphorism is nonsense. Repetition helps people learn. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: running tests in HiDPI mode on the build machines
jmaher wrote: Can you explain what would need to be done for Android to get into this mode? It might be difficult to make this work with our current solution for automated tests. This proposal is just to affect how content is rendered, by setting that pref. If it's a XUL UI it should render at the higher resolution. It wouldn't cause native UI to be rendered differently. I don't really know how we'd achieve that, on any platform, without actual HiDPI hardware. (Maybe those dongles that fake a monitor can be used on the Mac Minis?) I just tried setting layout.css.devPixelsPerPx to 2 on my Galaxy Nexus, and though things look like they render OK, interaction is not quite working properly. I can't seem to set it back to -1, either. ;) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
We can't have a rigid rule about 24 hours. Someone requesting a review from me on Thursday PDT probably won't get a response until Monday if neither of us work during the weekend. But I think it's reasonable to expect developers to process outstanding review requests (and needinfos) at least once every regular work day. Processing includes leaving a comment with an ETA. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Wed, Jul 10, 2013 at 2:48 PM, Jeff Walden jwalden+...@mit.edu wrote: Reviewer-side: I've lately tried to minimize my review turnaround time such that I get things done, roughly FIFO, before I get a review-nag mail. I can approximately do that, while keeping up with most of my coding. Establishing one-day turnaround time on reviews, or on requests, would require a lot more polling on my review queue. And I don't think that's a good thing, context-switching from coding tasks being pretty expensive for any developer. I think a reasonable expectation is that paid staff process outstanding review requests at least once every regular work day. If you do it at the beginning of the day, before diving into your other work, it won't interrupt that other work. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reparenting a XulRunnner window in a Firefox Window
Gijs Kruitbosch wrote: On 02/07/13 17:34 , Paul Rouget wrote: The Firefox OS Simulator is a XulRunner instance run from Firefox. Two processes, two windows, two different version of gecko. It would be very useful if we could display the simulator as part of Firefox. Inside a tab. With Linux, we could use XReparentWindow [1]. I don't know about Windows and Mac. Any idea if this is something doable with Windows and Mac? Would there be any better approach? [1] http://tronche.com/gui/x/xlib/window-and-session-manager/XReparentWindow.html -- Paul I'm sure this is a dumb question since you didn't even mention it... but why not load whatever the contents of the simulator are in the Firefox tab? As in, why are these separate processes+geckos? We want app developers to be able to test apps in older version of Gecko. For example, today, users use Firefox Desktop 22, but Firefox OS is based on Gecko 18. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Thu, Jul 11, 2013 at 5:06 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Jul 10, 2013 at 6:09 AM, smaug sm...@welho.com wrote: One thing, which has often brought up, would be to have other automatic coding style checker than just Ms2ger. See https://bugzilla.mozilla.org/show_bug.cgi?id=875605, which is, ironically, waiting for review. https://bugzilla.mozilla.org/show_bug.cgi?id=880088 is similar (albeit SpiderMonkey-only), and is also waiting for review! Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote: Establishing one-day turnaround time on reviews, or on requests, would require a lot more polling on my review queue. You poll your review queue? Like, by visiting your Bugzilla dashboard, or something like that? That's *awful*. I personally use a push notification system called email with filters. Well, strictly speaking it's poll-like because I have to check my high priority bugs folder, but I do that anyway multiple times per day so I'm unlikely to take more than an hour or two (while working) to notice a review request. Seriously, if your bug management system causes you to not notice review requests very quickly, it is broken. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 11/07/13 12:09 , Nicholas Nethercote wrote: On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote: Establishing one-day turnaround time on reviews, or on requests, would require a lot more polling on my review queue. You poll your review queue? Like, by visiting your Bugzilla dashboard, or something like that? That's *awful*. I personally use a push notification system called email with filters. Well, strictly speaking it's poll-like because I have to check my high priority bugs folder, but I do that anyway multiple times per day so I'm unlikely to take more than an hour or two (while working) to notice a review request. Seriously, if your bug management system causes you to not notice review requests very quickly, it is broken. Nick I find this fascinating. I am like Nick in this respect (although I don't need to filter out review requests from other bugmail, I do use filters for bugmail and will notice them quickly enough, generally speaking). My email client is always open and I generally notice bugmail more or less as it happens. However, contemporary wisdom seems to be that people get more done if they use pull rather than push systems. I'm not sure we should force people to use a push system here (although I do think it'd be good to have reviews go faster / get ETAs if they can't go fast). ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 09/07/13 21:29, Chris Peterson wrote: I've seen people change their Bugzilla name to include a comment about being on PTO. We should promote this practice. We could also add a Bugzilla feature (just a simple check box or a PTO date range) that appends some vacation message to your Bugzilla name. Hey, if we had a PTO app that tracked all absences, we could integrate with it... sigh Some review tools track review comments, so checking subsequent patches is easier. A couple months, I heard discussion about an investigation of Review Board for Bugzilla. Is anyone still investigating Review Board? Yes; it's on the BMO roadmap to be integrated; I believe its even being worked on now. CCing glob. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 10/07/13 23:14, Taras Glek wrote: I tried to capture feedback from this thread in https://wiki.mozilla.org/Code_Review I just did a pass over that page to highlight the key points. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On Thu, Jul 11, 2013 at 10:49 AM, Chris Peterson cpeter...@mozilla.com wrote: Can you describe your patch queue-like workflow using git? git rebase -i lets you reorder commits, but how do you quickly do the equivalent of hg qpopping and qpushing a bunch of commits? What I normally do is make the change in the working directory, commit it as a temporary commit, then use interactive rebase to fold it into the final commit I want the change to belong too. When working on multiple patches for a bug these are all separate commits and I'm committing/folding/resetting as needed. And if I make a mistake there's the reflog to recover from or I can just create a new branch if I'm going to do major surgery to the commits, allowing me to go back to the old branch if I change my mind. -- http://www.bluishcoder.co.nz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Modules for workers
On 2013-05-18, at 06:09 , David Rajchenbach-Teller dtel...@mozilla.com wrote: Hi everyone, As part of the ongoing effort to make (Chrome) Workers useful for platform refactorings, we have been working on a lightweight module loader for workers (bug 872421). This loader implements a minimal version of CommonJS modules, aka require.js. Example: [znip] Once this loader lands, we will need some convention for where to place modules for workers. Unfortunately, main thread modules (both .jsm and Jetpack) can generally not be used by worker, due to different module semantics, and more importantly due to the fact that most main thread modules depend indirectly on XPCOM/XPConnect. This might kill my dream of having a debuggable worker via require'ing a debug-server.js module. It's certainly feasible to recreate a basic debug-server that conforms to the restrictions of workers though. We'd need a WebSocket-only transport anyway. Given that main thread modules are rooted in resource://gre/modules/ and Jetpack modules are rooted in resource://gre/modules/commonjs/ I would like to place worker modules in resource://gre/modules/workers/ I think this layout makes sense. ~ robcee ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
One thing I've been thinking about is /why/ people are slow at reviews. Someone who usually has a long review queue has told me that he hates reviewing code. I realized that we don't really have a place at Mozilla for experienced hackers who don't want to do reviews. Should we? Could we do this without violating people's sense of fairness? As another data point, someone told me recently that he's trying not to become a peer of the modules he's working on, because he doesn't want to review code. Maybe we're not incentivizing people enough to be reviewers. Roc said that we've spoken with people who are slow at reviews. Did we learn anything from that? I'd expect that people are slow for different reasons. It seems backward to me to focus on a solution without first understanding the causes. -Justin On Thu, Jul 11, 2013 at 3:08 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar justin.le...@gmail.com wrote: If I can propose something that's perhaps different: 1) Write software to figure out who's slow with reviews. 2) We talk to those people. We've done this before too. But we should just do it again --- the definition of insanity aphorism is nonsense. Repetition helps people learn. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 7:59 AM, Gervase Markham wrote: Hey, if we had a PTO app that tracked all absences, we could integrate with it... sigh Just in case you were talking about the moco PTO app, it doesn't track absences for non-MoCo employees, and even for employees it does not track non-PTO absences (being a PTO app and all). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to make Firefox open in the foreground on Mac when launched from terminal
On 2013-05-29, at 18:58 , Justin Dolske dol...@mozilla.com wrote: On 5/29/13 3:09 PM, Ehsan Akhgari wrote: Typically when you use the terminal to open an application on Mac, the application is opened in the background. Mmm, indeed. Someone told me long ago this this was a platform convention, but it sure is annoying. Seems like a nice refinement to me. I'd assume that the most common use-case for launching the browser is to, well, use the browser. If people don't want -foreground as a default, I'd like to understand why. (Loading a test page and focusing on console output is fair, and the -background proposed in the bug would help.) I'm assuming the convention is so you don't break flow when interacting with the Terminal. Stealing focus away from that means you'll need to refocus the Terminal and that could be annoying. That said, running open . in an OS X Terminal launches an instance of Finder and focuses it, so I think we'd be OK to do the same. ~ rob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
On 2013-05-31, at 15:46 , Boris Zbarsky bzbar...@mit.edu wrote: On 5/24/13 10:50 AM, Justin Lebar wrote: Consider for example how much better harthur's fileit and dashboard tools [1] [2] are than bugzilla's built-in equivalents. Wasn't fileit integrated into the New Bug page? That search suggestion drop-down was a relatively recent addition. [2] http://harthur.github.io/bugzilla-todos/ So I actually tried using the dashboard you link to for the last week. It's actually worse at least for my use case than what I do in bugzilla right now (which is just a saved search for review/feedback requests on me), because: 1) It does not show feedback requests. This may explain why some people are routinely ignoring them…. Good point. I filed: https://github.com/harthur/bugzilla-todos/issues/19 2) It's a lot slower to load than a saved search. With my current request queue it didn't seem that much slower. 3) If left open (see #2) it does a bunch of JS off timeouts, causing noticeable jank in my browser. It polls so you can see new requests come in in real-time. One of the nice features is if you have it in an app tab, the favicon grows a little badge showing you the number of new requests you have. Of course, this requires some round-tripping with the server. All of which is to say that use cases apparently differ, since I assume for you the bugzilla-todos dashboard is in fact a lot better. Of course I would love something that did what this dashboard does in terms of showing bugs to check in and whatnot without the drawbacks. ;) Fork and create! ;) I tend to use a mix of bugmotodo and the Bugzilla Dashboard. I find them both useful, though lately I've been using bugmotodo in an app tab and quite like it. As long as I can see review requests in a timely fashion, it's all good. :) ~ rob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 11/07/2013 12:59, Gervase Markham wrote: On 09/07/13 21:29, Chris Peterson wrote: I've seen people change their Bugzilla name to include a comment about being on PTO. We should promote this practice. We could also add a Bugzilla feature (just a simple check box or a PTO date range) that appends some vacation message to your Bugzilla name. Hey, if we had a PTO app that tracked all absences, we could integrate with it... sigh I'd rather have a custom field anyway. Sometimes I'm highly focussed on a project for particular reason, or doing meet-up weeks. During those times I rarely even check bugmail for my other projects. Mark. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 2013-07-11 3:06 AM, Robert O'Callahan wrote: On Wed, Jul 10, 2013 at 6:09 AM, smaug sm...@welho.com wrote: One thing, which has often brought up, would be to have other automatic coding style checker than just Ms2ger. See https://bugzilla.mozilla.org/show_bug.cgi?id=875605, which is, ironically, waiting for review. Anybody who knows python can help with reviews there, FWIW. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/2013 9:23 AM, Justin Lebar wrote: One thing I've been thinking about is /why/ people are slow at reviews. Someone who usually has a long review queue has told me that he hates reviewing code. I realized that we don't really have a place at Mozilla for experienced hackers who don't want to do reviews. Should we? Could we do this without violating people's sense of fairness? As another data point, someone told me recently that he's trying not to become a peer of the modules he's working on, because he doesn't want to review code. Maybe we're not incentivizing people enough to be reviewers. Roc said that we've spoken with people who are slow at reviews. Did we learn anything from that? I'd expect that people are slow for different reasons. It seems backward to me to focus on a solution without first understanding the causes. I can definitely sympathize with this, as the build system owner (now peer), and test harness owner I get a lot of reviews thrown my way. I have been able to pretty successfully grow the peer list of both modules over the past few years, and it's worked out pretty well. One nice benefit that people shouldn't overlook is that by becoming a peer in a module you work in you help spread out the review load, which means that the owner and other peers have more time to review *your* patches. This has been really great for me in the build system, where I prioritize reviews requests from the other peers, and in return also get quick turnaround on patches I need review for. It's a little tit-for-tat, but I think it's a healthy positive feedback loop. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to make Firefox open in the foreground on Mac when launched from terminal
On 11/07/13 15:38, Rob Campbell wrote: On 2013-05-29, at 18:58 , Justin Dolske dol...@mozilla.com wrote: On 5/29/13 3:09 PM, Ehsan Akhgari wrote: Typically when you use the terminal to open an application on Mac, the application is opened in the background. Mmm, indeed. Someone told me long ago this this was a platform convention, but it sure is annoying. Seems like a nice refinement to me. I'd assume that the most common use-case for launching the browser is to, well, use the browser. If people don't want -foreground as a default, I'd like to understand why. (Loading a test page and focusing on console output is fair, and the -background proposed in the bug would help.) I'm assuming the convention is so you don't break flow when interacting with the Terminal. Stealing focus away from that means you'll need to refocus the Terminal and that could be annoying. That said, running open . in an OS X Terminal launches an instance of Finder and focuses it, so I think we'd be OK to do the same. ~ rob The open command does quite complicated things: open X uses the LaunchServices framework to determine which application should handle X then sends it an open AppleEvent, and brings it to the front. There is only one instance of any Mac application, including the Finder. It will receive the AppleEvent and open the requested directory (which in this case is .). Note that the open command has a -g option to keep the receiving application in the background. Also worth mentionning, the open command quits and control returns to the calling shell, while the application keeps running and its stdin/out/err are redirected to /dev/null. I don't think this is what we want, because we need console output in the terminal. Using open is very different from typing (for example) /Applications/Firefox.app/Contents/MacOS/firefox, which is the basic way to launch any executable (including real Mac applications), and doesn't check for already running instances (launched Mac applications are registered through LaunchServices). This is probably what we are doing now, and in that case the launched application stays in the background while its output goes to the terminal. Unless the application brings *itself* to the foreground, which is contrary to Apple's HI guidelines. Today, if one types open -g /Applications/Firefox.app LaunchServices will tell the Finder to open Firefox (an application), and keep it in the background. If we make Firefox bring itself to the foreground when launched, we'll break the expected behavior. Do we care for that? André ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 9:23 AM, Justin Lebar wrote: One thing I've been thinking about is /why/ people are slow at reviews. Here are some possible reasons I've encountered myself: 1) Feeling overwhelmed because you have too many reviews pending and therefore just staying away from your list of reviews. Note that this can be self-perpetuating. 2) Feeling like you have to do your reviews in some sort of FIFO order, so that a review for a large patch (which takes a long time because that's just how large patches work) will block possibly-quick reviews for smaller patches. 3) Feeling like you want to do your reviews in some sort of most-expeditious order, so that a constant stream of small patches delays review of a big patch for weeks or months. 4) Feeling that you need multiple hours of uninterrupted time, probably over several days for review of a complicated patch and not being able to find it due to the scattering of meetings, people asking you questions, smaller reviews, etc that you're also doing. Note that anyone who has no time to code because of reviews probably also has no time to do big complicated reviews, for the same reasons! 5) Simply having too high a review load. Anecdotally, it typically takes me until sometime Tuesday afternoon at best to catch up on all the review requests that come in between end-of-work Friday and Monday morning. 6) Just disliking doing reviews (but more on this below). 7) Wanting to completely focus on some other complicated task for a few days ... or weeks. It would be interesting to see what other reasons there are and what the relative frequencies are. Someone who usually has a long review queue has told me that he hates reviewing code. Reviewing code is just not all that fun. You have to tell people they did something wrong, often with some fairly arbitrary (in the grand scheme of things; we do it so we have consistent coding style) nitpicks, there is not that much of a sense of accomplishment at the end. It feels very adversarial at times. Sometimes you learn new things in the process, but more often you try hard to politely tell people that they've screwed something up... possibly after you already told them that about that same thing in the previous iteration of the patch. At least for me, it can get downright depressing at times. But debugging leaks is not that fun either. Or trying to read through flat profiles and speed things up. Or hunting down a dangling pointer bug. Or trying to convince people on a standards mailing list to not do something insane, for that matter. Fundamentally, we feel that reviews are useful and that means they have to get done; the doing is not all that fun, but it's a sort of giving back to the community, in my view. I realized that we don't really have a place at Mozilla for experienced hackers who don't want to do reviews. Should we? Could we do this without violating people's sense of fairness? How do we handle this with the other unpalatable tasks above? Informally, what I see is that they get shunted to people who are either not as unhappy doing them or have a stronger sense of I don't like it, but it needs doing, and no one else is stepping up. And it sure as heck violates people's sense of fairness. Of course we do that with reviews too (a well-known technique for doing fewer reviews is just being slow about it so people stop asking, whereas someone who does reviews quickly is rewarded by people piling on reviews), and it likewise violates people's sense of fairness. Of course the other thing I see happen with the unpalatable tasks I list above is that they just don't get done in many cases because no one steps up. That's a bit rarer with reviews, because we don't consider those as optional. But it has happened: I've seen patches die because no one stepped up to review. Here's another way to look at this: do these hackers want _others_ to review their patches? If so, how do they expect that to happen? Obviously everyone would prefer to work on the things they _want_ to work on, not necessarily the things that _need_ to be worked on. To the extent that someone focuses more on the former than on the latter, they're shafting others whose sense of duty won't let them do that. The result is that you get people who are unhappy because they never get to work on the things they want to or who are unhappy because they're doing all their I would like to get this done work after hours. Or both, at times: only working on things that need to happen _and_ having to do it after hours... And as a further note, the more reviews pile on just a small subset of people, the more problems 1-5 listed above manifest. As Taras said, the right solution to review load is to grow more reviewers, but that's hard to do if people are basically shirking the responsibility. As another data point, someone told me recently that he's trying not to
Re: Code Review Session
self-reply. --1. On 2013-07-11, at 09:56 , Rob Campbell rcampb...@mozilla.com wrote: On 2013-05-31, at 15:46 , Boris Zbarsky bzbar...@mit.edu wrote: […] 1) It does not show feedback requests. This may explain why some people are routinely ignoring them…. Good point. I filed: https://github.com/harthur/bugzilla-todos/issues/19 This issue is closed. Apparently a more-recent version of bugmotodo now includes feedback requests in the To Review pane. ~ rob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 2013-07-10 6:27 PM, Mark Côté wrote: On 2013-07-10 2:18 PM, Boris Zbarsky wrote: On 7/10/13 1:58 PM, Mark Côté wrote: The BMO team is again considering switching to ReviewBoard, which should fix this problem How does ReviewBoard address this? Again, what we have in the bug is diff 1 against changeset A and diff 2 against changeset B that incorporates the review changes. What the reviewer would like to see is a diff from 1 rebased against B to 2. I guess that's possible if the system tries to automatically rebase diff 1 against changeset B, but if the automatic rebase fails you still fail... True, sorry, I meant only the part about it having access to source control. Apologies for the diversion. I've talked to the BMO folks about this before. ReviewBoard doesn't know what the base revision of patches are, so it will not be helpful. It's just a fancier splinter. To do this properly we need to push commits/changesets somewhere instead of attaching textual diffs, and unfortunately that doesn't seem to be a problem that the ReviewBoard switch is trying to solve. Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 7/11/13 12:05 AM, Justin Lebar wrote: On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch wrote: git rebase --interactive. It is /far/ more powerful than mq for this use-case. I even have a |git qrebase| alias for this. https://github.com/jlebar/moz-git-tools Looks very interesting, lots of nice tools I could make use of :) I have the feeling git is very powerful, but the commands to use it are not very intuitive. You have a repository full of commands I would expect git to have included. Yes, somehow rebasing seems to be the solution here, but with git its quite common that you push your changes to your own remote and then do pull requests. This again will require me to do push -f almost always, since I often change the order of patches. This doesn't sound ideal to me. I don't understand the objection here. Yes, if you're changing remote history (e.g. updating a pull request after you re-ordered patches), you have to push -f. What's the problem with this? It just seems wrong, or unclean to me to force a push. Maybe its just me used to hg where I keep things for myself and only upload patches for review. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
While I think your observations are useful, I think (hope!) you are a massive outlier and I don't think we should design a policy based on the assumption that your review commitments are in any way normal. I would be totally OK with a policy that explicitly applies to everyone except you. Or, we could parameterize it with a dynamic list of exceptions who are known to be overloaded with reviews. In fact, making that list explicit and publishing it would let people know not to request reviews from people on that list except as a last resort (which is, in fact, how I treat you and dbaron). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Thu, Jul 11, 2013 at 6:23 AM, Justin Lebar justin.le...@gmail.comwrote: Someone who usually has a long review queue has told me that he hates reviewing code. I realized that we don't really have a place at Mozilla for experienced hackers who don't want to do reviews. Should we? I think someone can hate doing reviews and also want to do reviews because they're important. I don't know anyone who loves doing reviews. As another data point, someone told me recently that he's trying not to become a peer of the modules he's working on, because he doesn't want to review code. If someone who can do reviews is avoiding them, they're pushing workload onto their peers who probably don't enjoy it much more. That's antisocial and unacceptable IMHO. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
The way I work is that review and needinfo requests go to my inbox and I process them with high priority. I can and do ignore them there temporarily if I need to. Given I use my inbox as a to-do list, that approach seems perfect for me. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 11:37 AM, Robert O'Callahan wrote: While I think your observations are useful, I think (hope!) you are a massive outlier Somewhat. My list was based on not only what makes my reviews slow but what I've heard people mention as making reviews slow. I do agree we shouldn't design a policy based on my review queue. ;) I would be totally OK with a policy that explicitly applies to everyone except you. Or, we could parameterize it with a dynamic list of exceptions who are known to be overloaded with reviews. So the thing is, I'm not _always_ overloaded with reviews. I generally keep on top of them unless I take time off or several large patches end up in my review queue at once. And I think that applies to most people who are trying to do their reviews... The problem is that right now there is no way to mark yourself as temporarily less responsive on reviews than normal, whether it's because you're on vacation or because you have a 500KB patch to review that will take all week. And then reviews pile on. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
Can you describe your patch queue-like workflow using git? git rebase -i lets you reorder commits, but how do you quickly do the equivalent of hg qpopping and qpushing a bunch of commits? qpop qpush is a nop, of course; what do you want to in-between those two commands? I have a |git qrebase| command which does |git rebase -i| on my whole patch queue. The patch queue is defined as the set of commits in the range $(git qparent)..HEAD, where |git qparent| is the first common ancestor between HEAD and |git tracks| (i.e., |git merge-base $(git tracks) HEAD|). |git tracks| is defined as the upstream branch that the current branch tracks (as set by |git branch -u| in newer versions of git). All of these commands are defined in my git-tools repository. https://github.com/jlebar/moz-git-tools As an example, to qpop your patch queue so that commit X is the new head, then add a new patch on top of X, then re-apply your patch queue, you'd do |git qrebase|, then mark commit X as edit, then |git commit| your new patch, then |git rebase --continue|. This is better than hg in a number of ways, but among them is the fact that the old state of your patch queue is not lost for 90 days or so. If you discover that you screwed up and want to go back to the old version of the patch queue, you merely need to look through |git reflog| and then |git reset --hard Z| where Z is the commit you were at before you rebased. This is in contrast to hg, where |hg qref| is destructive and can cause you to lose work (unless you're versioning your patch queue, which is a whole other can of worms). On Wed, Jul 10, 2013 at 6:49 PM, Chris Peterson cpeter...@mozilla.com wrote: On 7/10/13 3:01 PM, Justin Lebar wrote: I can't see how they are a good alternative. With patch queues, I can maintain a complex refactoring in a patch queue containing dozens of smallish patches. In particular, I can easily realize I made a mistake in patch 3 while working on patch 21 and make sure that the fix ends up in patch 3; I don't see how that is easily achievable in git branches. This is far easier to achieve in git than with mq. Can you describe your patch queue-like workflow using git? git rebase -i lets you reorder commits, but how do you quickly do the equivalent of hg qpopping and qpushing a bunch of commits? I use ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Thursday 2013-07-11 00:14 -0700, Robert O'Callahan wrote: We can't have a rigid rule about 24 hours. Someone requesting a review from me on Thursday PDT probably won't get a response until Monday if neither of us work during the weekend. But I think it's reasonable to expect developers to process outstanding review requests (and needinfos) at least once every regular work day. Processing includes leaving a comment with an ETA. So, partly, I'm really bad at figuring out ETAs for small tasks, since I find the priority order of small tasks to be relatively dynamic, given how often small things come up. For example, reading and responding to this thread (something I've spent at least 15 minutes on so far this morning, and it'll probably end up being more than 30, which is probably 10% of my non-meeting working day today). Should I have prioritized that above doing code reviews, or should I come back to this thread and give you my thoughts in 3 weeks (as I'm currently doing on the prefixing policy thread, which I feel requires more thought)? I spend a pretty big portion of my time on things that come up at the last minute: questions from colleagues, discussions on lists (Mozilla lists and standards lists, etc.). (Another interesting question: should I prioritize questions / needinfos from people in the *middle* of writing a patch over code reviews which are at the *end* of writing a patch? Right now I think I sometimes do, and sometimes treat them equally.) Like Boris, I feel guilty about not getting to reviews, and I feel like I'm bad at figuring out how to prioritize them. I suppose what leaving an ETA would do is force me to try to stick to what I've promised, which in turn means doing code reviews rather than doing things like reading email or responding to this thread. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Automated builds/tests can no longer rely on external resources (aka RelEng firewall now set to Deny-All)
It has been our policy [1] to discourage builds/tests run in automation from relying on resources outside of the build network, to avoid non-deterministic failures across the board and to reduce noise in performance tests. As of Saturday, this policy will be enforced by the RelEng firewall being set to Deny-All by default [2][3]. Recent traffic has been monitored and used to create a set of Allow rules and/or remove existing offenders - so there should be few surprises. However, this means that new tests/frameworks added to the tree will need to be designed with the expectation that they will not be able to access outside of the build network - otherwise they'll fail when pushed to Try/integration repository of choice. Best wishes, Ed [1] https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy#8.29_Must_avoid_patterns_known_to_cause_non_deterministic_failures [2] https://bugzilla.mozilla.org/show_bug.cgi?id=617414 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=812342 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 2013-07-11 7:59 AM, Gervase Markham wrote: On 09/07/13 21:29, Chris Peterson wrote: I've seen people change their Bugzilla name to include a comment about being on PTO. We should promote this practice. We could also add a Bugzilla feature (just a simple check box or a PTO date range) that appends some vacation message to your Bugzilla name. Hey, if we had a PTO app that tracked all absences, we could integrate with it... sigh Some review tools track review comments, so checking subsequent patches is easier. A couple months, I heard discussion about an investigation of Review Board for Bugzilla. Is anyone still investigating Review Board? Yes; it's on the BMO roadmap to be integrated; I believe its even being worked on now. CCing glob. To be clear and to correct something I said earlier: we are standing up a somewhat independent RB service this quarter, which will be connected to Bugzilla's auth and will know about some common repos but nothing more. RB seems great but I don't think we've conclusively decided that it's the best solution; we probably need to experiment with it a bit to make sure it works best for us. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
That last thing was another item I found useful in the previous life. When requesting a review from somebody, people could see this person currently has X items in their review queue. You can ignore that information, but it's there and it may help. It's still probably simpler for the reviewer to know they're too busy, notify the author, and help them find somebody else if they can't agree on the timeframe. On 2013-07-11, at 11:37 , Robert O'Callahan rob...@ocallahan.org wrote: While I think your observations are useful, I think (hope!) you are a massive outlier and I don't think we should design a policy based on the assumption that your review commitments are in any way normal. I would be totally OK with a policy that explicitly applies to everyone except you. Or, we could parameterize it with a dynamic list of exceptions who are known to be overloaded with reviews. In fact, making that list explicit and publishing it would let people know not to request reviews from people on that list except as a last resort (which is, in fact, how I treat you and dbaron). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ 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: Embracing git usage for Firefox/Gecko development?
On 2013-07-11 11:26 AM, Philipp Kewisch wrote: On 7/11/13 12:05 AM, Justin Lebar wrote: On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch wrote: git rebase --interactive. It is /far/ more powerful than mq for this use-case. I even have a |git qrebase| alias for this. https://github.com/jlebar/moz-git-tools Looks very interesting, lots of nice tools I could make use of :) I have the feeling git is very powerful, but the commands to use it are not very intuitive. You have a repository full of commands I would expect git to have included. git rebase -i is more powerful, *and* more flexible, than mq is. Now you may not like git or not want to learn how to use interactive rebase, but arguing that mq workflow is better than what git can offer is flawed. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
I may have a skewed view of things, but I personally have not had problems getting prompt code reviews. I also don't have a problem talking to my reviewers about what I'm hacking on. I'm hesitant to throw a bunch of technology at this problem, if it's a social issue. Code reviews are a conversation and more code has to come with more conversations. Talk to each other, people! We'll cover this topic at the next Rendering Meeting. Let's have a look at the bugs sitting in review and reassign reviewers as needed. We need to grow more reviewers, and the only way I know to do that is to trust new people with reviewing code (and check their work.) --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 07/11/2013 03:09 AM, Nicholas Nethercote wrote: On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote: Establishing one-day turnaround time on reviews, or on requests, would require a lot more polling on my review queue. You poll your review queue? Like, by visiting your Bugzilla dashboard, or something like that? That's *awful*. I personally use a push notification system called email with filters. Well, strictly speaking it's poll-like because I have to check my high priority bugs folder, but I do that anyway multiple times per day so I'm unlikely to take more than an hour or two (while working) to notice a review request. I have https://bugzilla.mozilla.org/request.cgi?requestee=jwalden%2Bbmo%40mit.edudo_union=1group=typeaction=queue open in a browser tab and check it from time to time. I don't see how that's any different from a mail-filtering folder except in terms of the UI. They're both polling, as you note. :-) Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 8:24 PM, Jeff Walden wrote: On 07/11/2013 03:09 AM, Nicholas Nethercote wrote: On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote: Establishing one-day turnaround time on reviews, or on requests, would require a lot more polling on my review queue. You poll your review queue? Like, by visiting your Bugzilla dashboard, or something like that? That's *awful*. I personally use a push notification system called email with filters. Well, strictly speaking it's poll-like because I have to check my high priority bugs folder, but I do that anyway multiple times per day so I'm unlikely to take more than an hour or two (while working) to notice a review request. I have https://bugzilla.mozilla.org/request.cgi?requestee=jwalden%2Bbmo%40mit.edudo_union=1group=typeaction=queue open in a browser tab and check it from time to time. I don't see how that's any different from a mail-filtering folder except in terms of the UI. They're both polling, as you note. :-) Jeff I wish I could watch more than one requestee in one page. I actually have a tab with a history of three bugzilla accounts' requests page, and go back and forth and reload. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/2013 8:55 AM, Boris Zbarsky wrote: On 7/11/13 11:37 AM, Robert O'Callahan wrote: While I think your observations are useful, I think (hope!) you are a massive outlier Somewhat. My list was based on not only what makes my reviews slow but what I've heard people mention as making reviews slow. I do agree we shouldn't design a policy based on my review queue. ;) Maybe you need to start farming out reviews to other/newer members of the teams you work on? We've done that in media; giving reviews to the newer members of the team has been a great way to spread the load, and upskill the other team members. Obviously some patches need the attention of an experienced hacker like yourself, but style nitsand mechanical errors etc can be picked up a less experienced reviewer. You could always look for the big issues, feedback+/- and then reassign the review request to another reviewer. Chris P. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 2:41 PM, Chris Pearce wrote: Maybe you need to start farming out reviews to other/newer members of the teams you work on? Oh, that's been happening. A lot. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 7/11/13 8:00 PM, Ehsan Akhgari wrote: On 2013-07-11 11:26 AM, Philipp Kewisch wrote: On 7/11/13 12:05 AM, Justin Lebar wrote: On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch wrote: git rebase --interactive. It is /far/ more powerful than mq for this use-case. I even have a |git qrebase| alias for this. https://github.com/jlebar/moz-git-tools Looks very interesting, lots of nice tools I could make use of :) I have the feeling git is very powerful, but the commands to use it are not very intuitive. You have a repository full of commands I would expect git to have included. git rebase -i is more powerful, *and* more flexible, than mq is. Now you may not like git or not want to learn how to use interactive rebase, but arguing that mq workflow is better than what git can offer is flawed. Oh no, sorry if this came over wrong. I agree that git is much more powerful in quite a few aspects. I like git add -p much better than the qrecord extension, and the interactive rebase is quite nice too. git status is much more verbose, and there are likely a few other goodies I missed. I'm just saying that doing things in git has a higher entry barrier. hg and mq commands seem more logical at times (why does git checkout handle both reverting files to a revision and checking out branches?) or just require less typing (git log origin..HEAD vs hg out), which in turn means less need for the user to set up aliases. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 07/11/2013 11:00 AM, Ehsan Akhgari wrote: On 2013-07-11 11:26 AM, Philipp Kewisch wrote: On 7/11/13 12:05 AM, Justin Lebar wrote: On Wed, Jun 5, 2013 at 3:25 AM, Philipp Kewisch mozi...@kewis.ch wrote: git rebase --interactive. It is /far/ more powerful than mq for this use-case. I even have a |git qrebase| alias for this. https://github.com/jlebar/moz-git-tools Looks very interesting, lots of nice tools I could make use of :) I have the feeling git is very powerful, but the commands to use it are not very intuitive. You have a repository full of commands I would expect git to have included. git rebase -i is more powerful, *and* more flexible, than mq is. Now you may not like git or not want to learn how to use interactive rebase, but arguing that mq workflow is better than what git can offer is flawed. I may still be missing something, but afaict mq git rebase -i hg qcrecord (from the crecord extension.) This is speaking as someone who hasn't used git rebase -i much, but people who have seem to agree with me after seeing a qcrecord/qcrefresh demo. I wouldn't be surprised if something or other can give you something similar for git, but I don't know what that might be. Nor do I need to care... yet. I (of course) have my own hacked-up version that smooths over some of the friction in the workflow, so if someone forced me to use git it probably wouldn't be too hard to port the interesting bits of crecord to a git workflow as well. (Or at least to an stgit workflow. Or guilt, or whatever the current quilt-ish hotness is.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
Milan Sreckovic wrote: That last thing was another item I found useful in the previous life. When requesting a review from somebody, people could see this person currently has X items in their review queue. Even better would be if Bugzilla could compute their median review turnaround for you. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
I may still be missing something, but afaict mq git rebase -i hg qcrecord (from the crecord extension.) This is speaking as someone who hasn't used git rebase -i much, but people who have seem to agree with me after seeing a qcrecord/qcrefresh demo. qcrecord is, as far as I'm aware (it's been a while), much more like git add -i than git rebase -i. I would definitely be interested in having a patch-off with you sometime. :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
AppCache usage on Alexa top ~50,000 sites
As a result of a discussion a few of us had today at the Toronto work week about the use of appcache on the web (and if we should fix it), I did a quick scan of the sites using appcache in Alexa's top ~50,000 websites (only includes the landing page at a given URL). Of the search, 16 sites were returned - 2 of which have appcache commented out. 1 site only enabled it for Mobile IE. Details… The data is from June, 2013 and includes around 53,000 HTML files. It was downloaded from webdevdata.org. No user agent string was provided when retrieving the data. Please see webdevdata.org if you have questions about how the data is gathered. From the data, the search I did was: ` for b in */*.txt; do ( grep -lm 1 \smanifest\s*= $b ); done ` The results are not representative, but nonetheless throw a little weight towards the hypothesis that usage is generally low. A more in-depth look at usage is obviously needed and not too much should be read into this data. It's just a small data point. The sites were: metalsucks.net capitalone.com guinnessworldrecords.com forecast.io uni-due.de littlealchemy.com butfootballclub.fr leovegas.com netzkino.de shopfato.com.br giorgiotave.it jsonlint.com dragonbound.net nordea.se ex.fm amardeshonline.com -- Marcos Caceres ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AppCache usage on Alexa top ~50,000 sites
On Thu, 11 Jul 2013, Marcos Caceres wrote: As a result of a discussion a few of us had today at the Toronto work week about the use of appcache on the web (and if we should fix it), I did a quick scan of the sites using appcache in Alexa's top ~50,000 websites (only includes the landing page at a given URL). Of the search, 16 sites were returned - 2 of which have appcache commented out. 1 site only enabled it for Mobile IE. Note that the main use case for appcache is applications, which tend to be behind authentication walls and robots.txt blocks. For example, I would doubt that a grep is going to catch Google Docs' use of appcache. (Not that they want appcache to remain as is, but that's a separate issue.) appcache is, in this respect, similar to keygen (which is almost not used at all on the public web, but is used on intranets and behind paywalls and authentication walls). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
