Re: review stop-energy (was 24hour review)
On 11/07/13 14:24, Boris Zbarsky wrote: 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). I was talking about a possible future app which did this. Hence the sigh that we don't have it. (We do have a new PTO app, but it's not been deployed, ostensibly due to legal reasons because it tracked non-PTO absences!) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Generic data update service?
On 12/07/13 21:12, Nicholas Nethercote wrote: Would such an update increment the version number? I suspect you'd want to be able to easily determine if an update has been applied, and having to distinguish e.g. Firefox 30 without update 1 vs. Firefox 30 with update 1 could be annoying (and makes me think of Windows service packs). Good question; don't know. Perhaps each resource needs to be separately versioned, and have info about that tucked away somewhere less obvious than Help|About where it can be referenced for the small subset of bugs where it's useful? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Generic data update service?
On 13/07/13 00:36, Clint Talbert wrote: This is all good stuff, and I want to support us being nimble. We also need to balance that against security and quality in our builds. We go through the release process for a reason, and we exert the energy to QA these builds and ensure we can update them incrementally, reliably, and repeatably. I think that such a service like this can be fine, but I'd want to be very certain we only change certain, safe items in the profile directory, and we stay away from items in the application directory. If that's the general feeling, then we'd need to move any of these data items which are currently not profile-specific (e.g. the PSL) to be profile-specific. (Which itself suggests that updating them should rev. the Firefox version number.) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Generic data update service?
On 07/12/13 05:37 PM, Robert Strong wrote: On 7/12/2013 1:12 PM, Nicholas Nethercote wrote: On Fri, Jul 12, 2013 at 9:49 AM, Gervase Markham g...@mozilla.org wrote: We keep hitting cases where we would like Firefoxes in the field to have some data updated using a process which is much lighter in expended effort than shipping a security release. Would such an update increment the version number? I suspect you'd want to be able to easily determine if an update has been applied, and having to distinguish e.g. Firefox 30 without update 1 vs. Firefox 30 with update 1 could be annoying (and makes me think of Windows service packs). Nick It wouldn't update all of the places where version numbers are stored today since that would break incremental updates but there is no reason that the places in the UI couldn't read in this information and show it in the UI and thereby avoid breaking incremental updates. Updating any of the things in the original would break incremental updates as things stand now. We could figure out a way around it (eg, forcing complete updates for those files), but it's something that we should work out up front. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Generic data update service?
On 7/15/2013 9:30 AM, Gervase Markham wrote: On 13/07/13 00:36, Clint Talbert wrote: This is all good stuff, and I want to support us being nimble. We also need to balance that against security and quality in our builds. We go through the release process for a reason, and we exert the energy to QA these builds and ensure we can update them incrementally, reliably, and repeatably. I think that such a service like this can be fine, but I'd want to be very certain we only change certain, safe items in the profile directory, and we stay away from items in the application directory. If that's the general feeling, then we'd need to move any of these data items which are currently not profile-specific (e.g. the PSL) to be profile-specific. (Which itself suggests that updating them should rev. the Firefox version number.) Or it means that we need to be willing to issue dot-releases to update these items. We're pretty nimble with the desktop release cycle already. We should definitely measure this tradeoff before doing a bunch of engineering on this. As I understand it, the major factor here is that we are not nearly as nimble for FxOS updates, and so this is more of an issue, correct? --BDS ___ 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/10/2013 3:09 PM, smaug wrote: Splitting patches is usually useful, but having a patch containing all the changes can be also good. If you have a set of 20-30 patches, but not a patch which contains all the changes, it is often hard to see the big picture. Again, perhaps some tool could help here. Something which can generate the full patch from the smaller ones. Since I know how hard reviewing is, when I'm submitting a patch for a review (usually a larger one) I always do: - explanation of what the patch is doing in few or more points ; anything that could be perceived unexpected in the patch is also explained very well - providing patch split to logically separated parts with numbers like part 1 of 6 - and also a complete (folded) patch for reference - strictly versioning the patch among review rounds - when submitting a new version of a patch after r- always explain what has changed and provide an interdiff - before that I take great care to address all r comments or discuss them well This should be a standard IMO. -hb- -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Rendering meeting today, Monday 5:30pm PDT (Tuesday in some locations)
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 15 at 5:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-July-15 San Francisco - Monday, 5:30pm Winnipeg - Monday, 7:30pm Toronto - Monday, 8:30pm GMT/UTC - Tuesday, 0:30 Paris - Tuesday, 2:30am Taipei - Tuesday, 8:30am Auckland - Tuesday, 12:30pm 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
Re: Using C++0x auto
On 7/13/2013 3:15 PM, Kyle Huey wrote: We've dropped support for versions of MSVC prior to 2010, and we're requiring at least GCC 4.4. According to [0] that means we should be able to use /auto/. Anybody know any reasons why we can't start using it? We don't yet require C++11 mode when building Mozilla. That said, all platforms on the buildbot farms now compile with C++11, this should be feasible (though, as Mike points out, it effectively means requiring Desktop Linux builds to go to gcc 4.5 or newer). Forcing C++11 mode to build Mozilla will also enable us to use the following features: mozilla/Char16.h [I may start tackling replacing PRUnichar with char16_t after I finish atomic conversion] auto rvalue references in limited fashion -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WebAPI Meeting: Tuesday 16 July @ 10 AM Pacific [1]
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=20130716T10p1=224am=30 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
new root certs
How can i add a new root cert to xulrunner from the command line in linux? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On 7/14/13 10:50 PM, Justin Lebar wrote: We can't require any c++11 feature until we drop support for gcc 4.4. [...] there are problems in the gcc 4.4 system headers that make using c++11 mode impossible (except on b2g/android). Is there any reason to support gcc 4.4 outside of B2G/Android? btw, Android builders default to gcc 4.7 (bug 877503 and bug 892361). chris ___ 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/15/13 7:10 AM, Honza Bambas wrote: - providing patch split to logically separated parts with numbers like part 1 of 6 - and also a complete (folded) patch for reference - strictly versioning the patch among review rounds - when submitting a new version of a patch after r- always explain what has changed and provide an interdiff If reviewee submits a new version of (say) patch 1 of 6, should they: * attach patch 1 version 2 * an interdiff between patch 1 version 1 and 2 * and a new complete/folded patch (of patches 1-6)? Which file would be r+'d for review? chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On Mon 15 Jul 2013 11:43:05 AM PDT, Boris Zbarsky wrote: On 7/15/13 2:36 PM, Chris Peterson wrote: If reviewee submits a new version of (say) patch 1 of 6, should they: * attach patch 1 version 2 * an interdiff between patch 1 version 1 and 2 Yes, to both. Bleagh. All of this points to an annoying gap in our tooling. Can't we get a multiheaded repo of some sort that we can push this stuff to, to avoid the need for these contortions? I guess it would probably suffer the same perf death as the try repo, unless we prune out heads from resolved (or shipped?) bugs. Which file would be r+'d for review? Generally whatever will actually get checked in. Even for the case of dependent patches (ones with separate parts that cannot be landed together, but are usefully split up for review)? In that case, I'd expect only the individual patches to carry the r+. I have occasionally uploaded a new rollup patch and marked it r+ myself in these situations, but usually I just ignore or obsolete the rollup when it's no longer needed for reviewers or fuzzers. Even when it's the rollup that I land. Perhaps that's wrong of me, but it seems like the patches attached to bugs and the patches that actually land aren't very well correlated in our current setup anyway. I regard bug attachments as totally review-focused, not commit-focused. The info about what was committed is communicated (accurately) via the landing revision urls. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing Gecko's URL parser
On Mon, Jul 1, 2013 at 1:01 PM, Boris Zbarsky bzbar...@mit.edu wrote: Another big one I'm aware of is the issue of how to treat '\\' in URLs. In the specification this is resolved in favor of how WebKit/Chromium/Trident go about it. Which is to treat it identically to / but flag it with a warning in the console, if applicable. What should we use as tactic for fixing URL parsing? a) Have side-by-side implementations as with HTML and slowly switch over callers. b) Incrementally fix the existing URL parser (file bugs on specific issues such as \) c) Both? I have an implementation in JavaScript: https://github.com/annevk/url Next I'm going to get the test suite into better shape. I guess what's unclear is how to track the Gecko bits. -- http://annevankesteren.nl/ ___ 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/15/13 2:58 PM, Steve Fink wrote: Even for the case of dependent patches (ones with separate parts that cannot be landed together, but are usefully split up for review)? Assuming s/cannot/must/, that's why I said generally, not always. ;) Perhaps that's wrong of me, but it seems like the patches attached to bugs and the patches that actually land aren't very well correlated in our current setup anyway. They should be for anyone using checkin-needed... But yes, in other cases maybe not so much. -Boris ___ 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/15/2013 2:58 PM, Steve Fink wrote: On Mon 15 Jul 2013 11:43:05 AM PDT, Boris Zbarsky wrote: On 7/15/13 2:36 PM, Chris Peterson wrote: If reviewee submits a new version of (say) patch 1 of 6, should they: * attach patch 1 version 2 * an interdiff between patch 1 version 1 and 2 Yes, to both. Bleagh. All of this points to an annoying gap in our tooling. Can't we get a multiheaded repo of some sort that we can push this stuff to, to avoid the need for these contortions? I guess it would probably suffer the same perf death as the try repo, unless we prune out heads from resolved (or shipped?) bugs. What I'd love to have is a per-bug repo that you could push to. You could push new trees after rebasing/review nits and all would be awesome. But alas, that is not yet a reality. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing Gecko's URL parser
On 2013-07-15 3:14 PM, Anne van Kesteren wrote: On Mon, Jul 1, 2013 at 1:01 PM, Boris Zbarsky bzbar...@mit.edu wrote: Another big one I'm aware of is the issue of how to treat '\\' in URLs. In the specification this is resolved in favor of how WebKit/Chromium/Trident go about it. Which is to treat it identically to / but flag it with a warning in the console, if applicable. What should we use as tactic for fixing URL parsing? a) Have side-by-side implementations as with HTML and slowly switch over callers. b) Incrementally fix the existing URL parser (file bugs on specific issues such as \) The second approach seems like less work, but of course we should hide changes behind pref kill switches in case things go wrong with web compat. Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Shutting off leak tests?
Hi! Leak tests on OSX have been failing intermittently for nearly a year now[1]. As yet, we don't have any ideas why they're failing, and nobody is working on fixing them. Would anybody be very sad if we shut them off? Are these tests providing useful information any more? If they are still important to run, can we get some help fixing them? Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=774844 signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-07-15 1:45 PM, Chris AtLee wrote: Would anybody be very sad if we shut them off? I would be happy if you did, for the reasons you state. Please shut them off. -r -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR5GANAAoJEEcAD3uxRB3vaF8H/0gq4xVs/rOGumSonllWZ50X xh8HxJkvakk3mytq0Umcgxe/eVHnFQXesfXOcsg0PuvUNuWOFeo5o0iW0EBqoSAU FXr1CCfJfYB6E2C1holesMd9y6yWc4swaB5u4k/MRwUFUIgnTNjxMbY3/OwzUWyv Uozo6De42A3FFcpwo993w2eHr3jid0C6Mr45xr3D4G8Tbb0RNonD9cDJZoMXX97P wiPftPBz6a/Ql1+49lEN19kX3PlqyKW9e+6z/rwjcglnyjg3nGkVn3bQhOT902yi nylx0URcAO4T9VXEUQZ8AmrQdtVfir7re1eV6yxTEiUoEsVMiDYL0gbtyuhArG0= =bl35 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
Has a developer investigated? Steven, do you know anything about this? doug Chris AtLee wrote: Hi! Leak tests on OSX have been failing intermittently for nearly a year now[1]. As yet, we don't have any ideas why they're failing, and nobody is working on fixing them. Would anybody be very sad if we shut them off? Are these tests providing useful information any more? If they are still important to run, can we get some help fixing them? Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=774844 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
I'd say go ahead and shut them off. I'm not going to have time to investigate this for the foreseeable future. I'm already dealing with one very difficult (and possibly intractable) tests bug (https://bugzilla.mozilla.org/show_bug.cgi?id=884471), and that's more than enough at one time :-( On 7/15/13 4:07 PM, Doug Turner wrote: Has a developer investigated? Steven, do you know anything about this? doug Chris AtLee wrote: Hi! Leak tests on OSX have been failing intermittently for nearly a year now[1]. As yet, we don't have any ideas why they're failing, and nobody is working on fixing them. Would anybody be very sad if we shut them off? Are these tests providing useful information any more? If they are still important to run, can we get some help fixing them? Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=774844 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
I think we can only make this decision once we know the worst case scenario these tests are currently preventing, so that we can mitigate or plan for it. -Alex On Jul 15, 2013, at 1:45 PM, Chris AtLee cat...@mozilla.com wrote: Hi! Leak tests on OSX have been failing intermittently for nearly a year now[1]. As yet, we don't have any ideas why they're failing, and nobody is working on fixing them. Would anybody be very sad if we shut them off? Are these tests providing useful information any more? If they are still important to run, can we get some help fixing them? Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=774844 ___ 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: Shutting off leak tests?
On Mon, Jul 15, 2013 at 3:05 PM, Alex Keybl ake...@mozilla.com wrote: I think we can only make this decision once we know the worst case scenario these tests are currently preventing, so that we can mitigate or plan for it. -Alex On Jul 15, 2013, at 1:45 PM, Chris AtLee cat...@mozilla.com wrote: Hi! Leak tests on OSX have been failing intermittently for nearly a year now[1]. As yet, we don't have any ideas why they're failing, and nobody is working on fixing them. Would anybody be very sad if we shut them off? Are these tests providing useful information any more? If they are still important to run, can we get some help fixing them? Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=774844 ___ 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 FWIW now that we have AWSY and we don't really care about shutdown leaks specifically I don't think these tests are very useful to memshrink anymore. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
I brought this up ~2 years ago https://groups.google.com/forum/#!topic/mozilla.dev.platform/0lkjbtBK8eQ, and we concluded that discussion saying that we should turn these tests off, so bug 617441 was filed and then nothing happened. I don't think anything has changed since we had that discussion. On 2013-07-15 4:45 PM, Chris AtLee wrote: Hi! Leak tests on OSX have been failing intermittently for nearly a year now[1]. As yet, we don't have any ideas why they're failing, and nobody is working on fixing them. Would anybody be very sad if we shut them off? Are these tests providing useful information any more? If they are still important to run, can we get some help fixing them? Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=774844 ___ 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: Shutting off leak tests?
Makes me sad that the knee jerk reaction is to turn leak testing off before anyone actually does any engineering. Steven, anyone else that can take a look at this mac bug? Steven Michaud mailto:smich...@pobox.com July 15, 2013 2:15 PM I'd say go ahead and shut them off. I'm not going to have time to investigate this for the foreseeable future. I'm already dealing with one very difficult (and possibly intractable) tests bug (https://bugzilla.mozilla.org/show_bug.cgi?id=884471), and that's more than enough at one time :-( Doug Turner mailto:doug.tur...@gmail.com July 15, 2013 2:07 PM Has a developer investigated? Steven, do you know anything about this? doug ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
