Re: Tasks to implement the Encoding Standard and to reduce encoding autodetection
On Wed, Nov 6, 2013 at 10:19 AM, Henri Sivonen wrote: > If Thunderbird still wants to have these, I think they should take > them into comm-central. This bit was buried in the large email, so let's highlight it separately. Do Thunderbird developers want to keep decoders that are going away from Firefox? These include: * MS DOS encodings (except for Cyrillic) * Mac encodings (except for MacRoman and Cyrillic) * EUC-TW * JOHAB * ISO-2022-KR * ISO-2022-CN * ISO-IR-111 * T.61 * Non-Windows encodings for Vietnamese * ARMSCII And do Thunderbird developers want to keep these encoders: * GB2312 encoder as something distinct from the GBK encoder * ISO Western, Turkish and Thai encoders as distinct from Windows Western, Turkish and Thai encoders As noted in the quoted part, if Thunderbird developers want to keep these, I think these should move to comm-central. That is, I think these should stop living in m-c in any case. -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
On Thu, Nov 7, 2013 at 2:24 AM, Nicholas Cameron wrote: > In the long term, OMTC basic layers will be the default for Linux and > forcing HWA will give OpenGL OMTC as expected. Do I understand correctly that all these users will get OMTC basic layers as the long-term solution? * Don't have 3D drivers on a pre-llvmpipe system (e.g. Ubuntu 12.04 LTS) * Don't have 3D drivers but have Unity or Gnome 3 running on llvmpipe * Have 3D drivers capable of running Unity or Gnome 3 but blocklisted by Firefox (e.g. VirtualBox OpenGL pass-through) -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Pushes to Backouts on Mozilla Inbound
On Wed, Nov 6, 2013 at 5:49 PM, Ryan VanderMeulen wrote: > What do we gain by having results that can't be trusted? The same that we gain from allowing any try pushes that don't run every single test. It's a tradeoff between reliability and time, not black-and-white. For instance, if I change a few lines in a .cpp file in editor/, I know there are a limited number of tests it could plausibly affect, and there's no reason to run mochitests in gfx/ just so I can run mochitests in editor/ and dom/imptests/editing/. Likewise, if I got try failures that I can't reproduce locally and pushed a revised patch to test the fix, it would be nice to run just the affected tests. More than once I've submitted a whole series of patches that had to run a whole test suite instead of just a few tests, and therefore took 20 minutes or so more than necessary per iteration. On Wed, Nov 6, 2013 at 6:46 PM, Ryan VanderMeulen wrote: > I'm just afraid we're going to end up in the same situation we're already in > with intermittent failures where the developer looks at it and says "that > couldn't possibly be from me" and ignores it. We already see "Try results > look good" backouts on a depressingly-regular basis. The entire situation with how intermittent failures are handled strikes me as mostly a technical problem. Known intermittent failures should be flagged and automatically suppressed, not require manual judgment calls every single time. To ensure that they don't get made non-intermittent, they could be automatically rerun a couple of times (just the file, not the whole suite) if they fail to make sure they pass at least once, and get reported as a real failure if they fail five times in a row or something. Trying to persuade people to be careful of something that isn't a problem 90% of the time is a losing battle -- the signal-to-noise ratio needs to be a lot higher before people will pay attention. On Wed, Nov 6, 2013 at 9:56 PM, Steve Fink wrote: > As for "faster", I'm skeptical of the reliability of incremental try > builds. We have too many clobbers. And the same slaves do a bunch of > different build types, so it may have been quite a while since the last > build of the type you're doing. (Sure, we could tweak the scheduling to > add some affinity in, but that's more complexity and a richer set of > failure patterns.) Right, good point. I didn't think it through. > I'm still a bit curious as to whether allowing slaves > to collaborate via a fast distcc network going to remote ccaches would > work, but it also feels complex and potentially counterproductive (I'm > not at all sure that it's faster to look up and transfer a remotely > cached build result than it would be to recompile it locally.) Why would it not be faster, in terms of throughput? The network transfer should use roughly no CPU time, and builds are mostly CPU-bound, right? Even in terms of latency, I wouldn't expect hashing input file plus making local network request plus transferring response to take more than a millisecond if the cached file is in memory, and not much longer if it's on an SSD, so I don't see how actually compiling the file could compete except for very small files. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Legacy character encodings and data inside fonts
Do we still really need the legacy Mac encodings and JOHAB in order to make sense of fonts? http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxFontUtils.cpp#1139 -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
Nicholas Cameron writes: > Currently on Linux our only 'supported' graphics backend is the > main-thread software backend (basic layers). FWIW basic layers is predominantly GPU-based compositing (not-softwared) on most X11 systems. > 5) We would love to spend time making OMTC OpenGL on Linux work > perfectly, but it is not a priority for the graphics team due to > the low number of users. I would have assumed the number of Linux/X11 users is greater than the number of Linux/Android users. > After removing MT OGL, our proposal is that Linux users on nightly > or who manually set MOZ_USE_OMTC will get OMTC OpenGL. That means > they will get the same(-ish) performance, but a possibly worse > experience. Other Linux users will get main thread basic layers, > whether they force on HWA or not. Their performance will be > degraded (sometimes), but the rest of the experience should not > (this is the current default configuration for Linux). The most significant performance degrading I expect here is for users that want to use WebGL maps or games. Flicking the pref for OpenGL layers is the current workaround a get reasonable performance there. The new workaround will also require setting an environment variable off nightly, but that's not so much more awkward than about:config. > So, does anyone have any objections to this plan? Or ways we could > do this better? If you use HWA please be aware of these changes > and report any bugs you find. And a heads up that we might be > seeing a few bugs filed around this by users when it happens and > at subsequent uplifts. Will any MoCo developers be permitted to spend some time fixing these or the already-known issues? If MoCo is prepared to use some of the developer time saved through removing MT OGL on fixing these issues, then that hopefully will be a net positive move. How about first moving Nightly OGL users to OMTC, and then remove MT OGL after the next uplift? Then we have some time to discover whether there are any show-stopper OMTC issues, and we reduce the time frame for other branches between paying the price and reaping the returns. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
On Nov 7, 2013, at 1:19 PM, Karl Tomlinson wrote: > Nicholas Cameron writes: > >> Currently on Linux our only 'supported' graphics backend is the >> main-thread software backend (basic layers). > > FWIW basic layers is predominantly GPU-based compositing > (not-softwared) on most X11 systems. > >> 5) We would love to spend time making OMTC OpenGL on Linux work >> perfectly, but it is not a priority for the graphics team due to >> the low number of users. > > I would have assumed the number of Linux/X11 users is greater > than the number of Linux/Android users. Please think about the potential user base, not just current user base. The potential user base of Linux users is tiny, and mostly stagnant. The potential user base of mobile Linux (Android, FFOS) is massive, and growing explosively. > >> After removing MT OGL, our proposal is that Linux users on nightly >> or who manually set MOZ_USE_OMTC will get OMTC OpenGL. That means >> they will get the same(-ish) performance, but a possibly worse >> experience. Other Linux users will get main thread basic layers, >> whether they force on HWA or not. Their performance will be >> degraded (sometimes), but the rest of the experience should not >> (this is the current default configuration for Linux). > > The most significant performance degrading I expect here is for > users that want to use WebGL maps or games. Flicking the pref > for OpenGL layers is the current workaround a get reasonable > performance there. > > The new workaround will also require setting an environment variable > off nightly, but that's not so much more awkward than about:config. > >> So, does anyone have any objections to this plan? Or ways we could >> do this better? If you use HWA please be aware of these changes >> and report any bugs you find. And a heads up that we might be >> seeing a few bugs filed around this by users when it happens and >> at subsequent uplifts. > > Will any MoCo developers be permitted to spend some time fixing > these or the already-known issues? Its not a priority to fix Linux/X11. We will happily take contributed patches, and people are welcome to fix issues they see, as long its not at the expense of the things that matter. > > If MoCo is prepared to use some of the developer time saved > through removing MT OGL on fixing these issues, then that > hopefully will be a net positive move. > > How about first moving Nightly OGL users to OMTC, and then remove > MT OGL after the next uplift? The old OGL code is a tremendous maintenance nightmare and is actively hurting our ability to make progress on the OMTC code. We would like to delete it asap. Andreas > > Then we have some time to discover whether there are any > show-stopper OMTC issues, and we reduce the time frame for other > branches between paying the price and reaping the returns. > ___ > 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: HWA and OMTC on Linux
Andreas Gal writes: > Its not a priority to fix Linux/X11. We will happily take > contributed patches, and people are welcome to fix issues they > see, as long its not at the expense of the things that matter. Do bugs in B2G Desktop on Linux/X11 matter? I assume glitches and perf issues that are not on the device don't really matter. How about crashes and security bugs? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
On Nov 7, 2013, at 1:48 PM, Karl Tomlinson wrote: > Andreas Gal writes: > >> Its not a priority to fix Linux/X11. We will happily take >> contributed patches, and people are welcome to fix issues they >> see, as long its not at the expense of the things that matter. > > Do bugs in B2G Desktop on Linux/X11 matter? > > I assume glitches and perf issues that are not on the device don't > really matter. How about crashes and security bugs? Nobody said Linux/X11 doesn't matter. The proposal was to focus on OMTC on all platforms, including Linux/X11. Andreas > ___ > 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: HWA and OMTC on Linux
Andreas Gal writes: > On Nov 7, 2013, at 1:48 PM, Karl Tomlinson wrote: > >> Andreas Gal writes: >> >>> Its not a priority to fix Linux/X11. We will happily take >>> contributed patches, and people are welcome to fix issues they >>> see, as long its not at the expense of the things that matter. >> >> Do bugs in B2G Desktop on Linux/X11 matter? >> >> I assume glitches and perf issues that are not on the device >> don't really matter. How about crashes and security bugs? > > Nobody said Linux/X11 doesn't matter. The proposal was to focus > on OMTC on all platforms, including Linux/X11. I assume games and maps and WebGL matter. The current direction for WebGL on Linux/X11 seems to be assuming that OGL will be the solution. The comments thus far in this thread imply that OGL-OMTC-Linux-X11 doesn't matter. If that is the case, then we need to find another solution for WebGL. However, OGL-OMTC layers is likely the best solution for WebGL, and not necessarily more work. And if OGL-OMTC-Linux-X11 doesn't matter for Firefox, then how much is B2G Desktop used on Linux? Even if only crashes on Linux B2G Desktop matter, then OGL-OMTC-Linux-X11 Firefox will benefit from sharing the same code, and benefits flow the other way too. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
(Not replying to anyone in particular, just replying to the lastest email in this thread at this point: ) Let's not transform the original conversation here, which was purely a technical conversation about improving the way we do compositing on Linux, into a prioritization conversation, which would not belong on dev-platform. One data point that Karl provided here is purely technical and needs to be taken into account in this technical conversation well before one would start talking priorities: newer types of Web content, e.g. WebGL, may mean that not having OpenGL compositing may become less and less viable going forward. Benoit 2013/11/7 Karl Tomlinson > Andreas Gal writes: > > > On Nov 7, 2013, at 1:48 PM, Karl Tomlinson wrote: > > > >> Andreas Gal writes: > >> > >>> Its not a priority to fix Linux/X11. We will happily take > >>> contributed patches, and people are welcome to fix issues they > >>> see, as long its not at the expense of the things that matter. > >> > >> Do bugs in B2G Desktop on Linux/X11 matter? > >> > >> I assume glitches and perf issues that are not on the device > >> don't really matter. How about crashes and security bugs? > > > > Nobody said Linux/X11 doesn't matter. The proposal was to focus > > on OMTC on all platforms, including Linux/X11. > > I assume games and maps and WebGL matter. > The current direction for WebGL on Linux/X11 seems to be assuming > that OGL will be the solution. > > The comments thus far in this thread imply that OGL-OMTC-Linux-X11 > doesn't matter. If that is the case, then we need to find another > solution for WebGL. However, OGL-OMTC layers is likely the best > solution for WebGL, and not necessarily more work. > > And if OGL-OMTC-Linux-X11 doesn't matter for Firefox, then how > much is B2G Desktop used on Linux? Even if only crashes on Linux > B2G Desktop matter, then OGL-OMTC-Linux-X11 Firefox will benefit > from sharing the same code, and benefits flow the other way too. > ___ > 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: Pushes to Backouts on Mozilla Inbound
On Thursday 2013-11-07 14:13 +0200, Aryeh Gregor wrote: > On Wed, Nov 6, 2013 at 6:46 PM, Ryan VanderMeulen wrote: > > I'm just afraid we're going to end up in the same situation we're already in > > with intermittent failures where the developer looks at it and says "that > > couldn't possibly be from me" and ignores it. We already see "Try results > > look good" backouts on a depressingly-regular basis. > > The entire situation with how intermittent failures are handled > strikes me as mostly a technical problem. Known intermittent failures > should be flagged and automatically suppressed, not require manual > judgment calls every single time. To ensure that they don't get made > non-intermittent, they could be automatically rerun a couple of times > (just the file, not the whole suite) if they fail to make sure they > pass at least once, and get reported as a real failure if they fail > five times in a row or something. Trying to persuade people to be > careful of something that isn't a problem 90% of the time is a losing > battle -- the signal-to-noise ratio needs to be a lot higher before > people will pay attention. I think this depends on what you mean by "known intermittent failures". If a known intermittent failure is the result of any regression that leads to a previously-passing test failing intermittently, I'd be pretty uncomfortable with this. There have been quite a few JS engine changes that led to style system mochitests failing intermittently; I wouldn't want all of the style system's test coverage to be progressively turned off as a result. But if you're talking about new tests that aren't yet passing reliably, or other cases where the module owner of the test recognizes that the regression is acceptable, then that seems ok. We need to get better about identifying and backing out changes that cause previously-passing tests to start failing intermittently. This requires better tools for doing it. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
On Thursday 2013-11-07 13:24 -0800, Andreas Gal wrote: > On Nov 7, 2013, at 1:19 PM, Karl Tomlinson wrote: > > Will any MoCo developers be permitted to spend some time fixing > > these or the already-known issues? > > Its not a priority to fix Linux/X11. We will happily take contributed > patches, and people are welcome to fix issues they see, as long its not at > the expense of the things that matter. I think having Linux/X11 be working and in good shape is important for attracting contributors to the Mozilla project, particularly those who write code. (Though I haven't seen recent data on OS use of Mozilla contributors who aren't paid to work on Mozilla. I'd be very surprised if it wasn't a much higher proportion of developers than users, though.) -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
Nicholas Cameron schrieb: Our goal is (basically) to be OMTC everywhere I have been using OMTC on Linux for a while (with both prefs on, actually) and with the exception of https://bugzilla.mozilla.org/show_bug.cgi?id=934250 everything works really fine (but then, I'm on the newest kernel/driver and Xorg versions and am using the open Intel drivers). 3) For nightly users, we initialise X for multiple threads in any case so that e10s works. Ah, so that is the reason why OMTC is now always on for me, no matter if I use the env var or not. That said, I thought we are targeting to get e10s enabled at some point anyhow, so maybe we should just take this hit and be done with it. 4) We do not want (non-nightly) users who do not use OMTC to pay the cost of multi-threaded X. As said above, I wonder if we actually should do that and be done with it. 5) We would love to spend time making OMTC OpenGL on Linux work perfectly, but it is not a priority for the graphics team due to the low number of users. We always hope to get community involvment here, but it has been patchy in the past. Maybe we need to communicate better that we need help there? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
On Nov 7, 2013, at 3:06 PM, "L. David Baron" wrote: > On Thursday 2013-11-07 13:24 -0800, Andreas Gal wrote: >> On Nov 7, 2013, at 1:19 PM, Karl Tomlinson wrote: >>> Will any MoCo developers be permitted to spend some time fixing >>> these or the already-known issues? >> >> Its not a priority to fix Linux/X11. We will happily take contributed >> patches, and people are welcome to fix issues they see, as long its not at >> the expense of the things that matter. > > I think having Linux/X11 be working and in good shape is important > for attracting contributors to the Mozilla project, particularly > those who write code. (Though I haven't seen recent data on OS use > of Mozilla contributors who aren't paid to work on Mozilla. I'd be > very surprised if it wasn't a much higher proportion of developers > than users, though.) I don't think anyone disagrees with you here, except if you are saying that somehow keeping the non-OMTC Linux code is critical to attract contributors to Mozilla. I don't think thats the case and I don't think you are trying to say that. Thats what the post was all about. We want to get rid of the old non-OMTC code because its blocking making OMTC better everywhere, including Linux. Andreas > > -David > > -- > π L. David Baron http://dbaron.org/ π > π’ Mozilla https://www.mozilla.org/ π > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
Andreas Gal writes: > On Nov 7, 2013, at 3:06 PM, "L. David Baron" wrote: > >> On Thursday 2013-11-07 13:24 -0800, Andreas Gal wrote: >>> On Nov 7, 2013, at 1:19 PM, Karl Tomlinson wrote: Will any MoCo developers be permitted to spend some time fixing these or the already-known issues? >>> >>> Its not a priority to fix Linux/X11. We will happily take >>> contributed patches, and people are welcome to fix issues they >>> see, as long its not at the expense of the things that matter. >> >> I think having Linux/X11 be working and in good shape is important >> for attracting contributors to the Mozilla project, particularly >> those who write code. > I don't think anyone disagrees with you here, except if you are > saying that somehow keeping the non-OMTC Linux code is critical > to attract contributors to Mozilla. I don't think thats the case > and I don't think you are trying to say that. Thats what the > post was all about. We want to get rid of the old non-OMTC code > because its blocking making OMTC better everywhere, including > Linux. It is a major discouragement to contributors when their efforts are regressed or discarded because they are in the way and don't matter. It wouldn't be reasonable to continue to expect contributions after doing this. Throwing out non-OMTC OGL without putting effort into making OMTC OGL as functional would be doing just that. This is what happened with native notifications, and I hope we don't have the same situation again here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tasks to implement the Encoding Standard and to reduce encoding autodetection
On 11/7/2013 5:42 AM, Henri Sivonen wrote: Do Thunderbird developers want to keep decoders that are going away from Firefox? These include: I don't think any Thunderbird developer is well-informed on the issue of charsets in email. The only non-web charset I know we need is the IMAP modified UTF-7 charset (and this is only for conversion of mailbox names in the IMAP protocol, not for body charsets). Owing to the nature of the release cycle, any negative impact on the removal of other charsets are unlikely to be discovered until the next ESR is released (TB 31, unless someone changes the release structure before then). I'm hoping to be able to use the same charsets that the encoding standard uses, but I do not know the impact of that decision. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Closure of trunk trees - owners for bugs needed
On Fri, Nov 1, 2013 at 12:52 PM, Nicholas Nethercote wrote: > > - Finish fixing the devtools leaks: > https://bugzilla.mozilla.org/show_bug.cgi?id=932880. Fixed on mozilla-central and backported to aurora, beta, and b2g26_v1_2. Nothing more to do. > - Finish fixing the social API leaks: > https://bugzilla.mozilla.org/show_bug.cgi?id=933551. Fixed on mozilla-central. Not yet backported to other repos. I asked ttaubert to nominate them for backporting. > - Improve the shutdown leak detection situation: > https://bugzilla.mozilla.org/show_bug.cgi?id=932898. Two of three patches have r+, and the third is awaiting review by ted. Not sure if these patches will need backporting or not. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
