Re: Tree Closures due to Bug 1286942 Buildbot DB Issues
On Friday, July 15, 2016 at 2:59:55 AM UTC-7, Carsten Book wrote: > Hi, > > we currently have a complete tree closure due to Buildbot DB Issues. > > The Teams working on resolving this issue and the Tracking Bug is: > https://bugzilla.mozilla.org/show_bug.cgi?id=1286942 > > There is no ETA yet for reopening. > > Thanks for your patience. > > - Tomcat > > P.S. one way to get patches checked-in automatically would be using > MozReview and Autoland to push it when then tree reopens. Just to close the loop here, the DB issues were resolved this morning. Trees remained mostly closed while the usual post-extended-closure backlog cleared up. All trees were re-opened this afternoon. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: realtime audio on linux
On Sat, Jul 16, 2016 at 5:09 AM, Steve Fink wrote: > I know it's kind of crazy given our garbage-collected, single content > process world, but reading this thread makes me wonder what it would take > to use the browser to implement a real linux-hosted audio workstation-type > app. As in, something that requires truly low-latency audio with mixing. My > (years stale) understanding is that pulseaudio is kind of the wrong model, > and can't really offer the right guarantees at an architectural level. ALSA > is, as ever, a mess, and just because you can play sound through ALSA on > one hardware configuration doesn't really mean much for other drivers. > > Last I knew, JACK was the only way to get basically no dropouts and still > be able to do nontrivial audio processing. But a JACK backend for the > browser just seems kind of silly; it's too much of a niche "market" to try > for anytime soon. > A JACK backend for cubeb, hence Firefox, exists but isn't compiled into Mozilla builds. The Web Audio API lets audio processing run on its own real-time thread, and that's what Gecko does, although on Linux unprivileged users running Firefox can't give that thread real-time priority. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Welcome new Data Stewardship Peers
Yes, people have been using the review? flag and I've bee marking that in mozreview. The only caution I'll make is that data stewards don't typically review the *code* that is being submitted: they review the data/documentation. So you'll need a code review as well. I look forward to the future with other flags as first-class citizens. --BDS On Wed, Jul 13, 2016 at 7:20 PM, Gerald Squelart wrote: > On Thursday, July 14, 2016 at 6:51:21 AM UTC+10, Benjamin Smedberg wrote: > > I'd like to welcome Chenxia Liu, François Marier, and Rebecca Weiss as > > peers of Firefox Data Stewardship, joining Ally and myself. I'm excited > to > > bring a selection of people from across the organization who are familiar > > with different products and projects within Mozilla, and I hope that this > > reduces the time needed for people to get review. > > > > As a reminder, all data collection from the Firefox products, including > > changes to telemetry histograms, should be reviewed by a data steward > peer > > before landing. More information about Firefox data collection can be > found > > at https://wiki.mozilla.org/Firefox/Data_Collection > > > > Please bear with the new peers as they learn the routine: it may be a few > > days or weeks until they are fully up to speed. > > > > --BDS > > Welcome to the new blood! > > > While I've got you here, can we please discuss one small details of the > review process? > > The wiki page reads "please request approval by setting the *feedback* > flag for the data collection module owner or a peer". > With mozreview becoming more prevalent (and easy to use) for reviews, > could we please just use the *review* flag instead? (At least for now*) > Of course the data collection reviewer should only look at the data > collection side, another reviewer should be nominated to look at the code. > > * A little bird told me that eventually the feedback flag will become a > first-class citizen in mozreview. ;-) > ___ > 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
realtime audio on linux
On 07/14/2016 05:36 PM, ajo...@mozilla.com wrote: On Friday, 15 July 2016 00:16:07 UTC+8, Georg Fritzsche wrote: This gives an overview of the current incoming Telemetry for Linux (from a 1% sample of our data, "canonical" is the Ubuntu distribution): https://sql.telemetry.mozilla.org/queries/678#table Also keep in mind, unless using opt-out probes, that the opt-in rates for Telemetry are low: https://sql.telemetry.mozilla.org/queries/682#table Most of the major distros use Pulse Audio so they can add Pulse Audio as a package dependency. Our official builds are in a different bucket so we're better to use the update ping to get data from them. Distros can still ship with ALSA support but they will need to take on the burden of making sure it works. There may be value in that for distros that are specific to a single piece of hardware. I know it's kind of crazy given our garbage-collected, single content process world, but reading this thread makes me wonder what it would take to use the browser to implement a real linux-hosted audio workstation-type app. As in, something that requires truly low-latency audio with mixing. My (years stale) understanding is that pulseaudio is kind of the wrong model, and can't really offer the right guarantees at an architectural level. ALSA is, as ever, a mess, and just because you can play sound through ALSA on one hardware configuration doesn't really mean much for other drivers. Last I knew, JACK was the only way to get basically no dropouts and still be able to do nontrivial audio processing. But a JACK backend for the browser just seems kind of silly; it's too much of a niche "market" to try for anytime soon. Can anyone comment who is knowledgeable about audio and the state of linux audio, unlike me? I'm curious how far off base I am. If I were to try to do this today, I'd probably just use the browser to create the UI and talk to a native app over a socket or ctypes or something. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Core: Tracking is no more!
The "Tracking" component has been a place for a random hodgepodge of bugs that were designed to track things, but often had very poor ownership and decision-making. So we've removed it! I went through the open tracking bugs and either closed them if they were no longer relevant, or moved them to a more appropriate component. You are welcome to keep using tracking bugs, but you should put them in a component related to the work being tracked. I would also encourage everyone to assign tracking bugs to the person who is actually tracking the work (program manager, engineering manager, or engineering lead). Having a tracking bug that is unassigned can be confusing, because it's not clear who is actually responsible for *doing* the tracking and followup. And that's a good way to remember to close out tracking bugs when we're done with them! As a reminder, the blocking relationship to use is that all the relevant component bugs block the tracking bug, so the tracking bug depends on its component work. Then when the --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Core Guidelines
Given GSL's pedigree, I was assuming that we'd bring it in-tree and switch out MFBT facilities with the corresponding GSL things as they became available. One of the main roles of MFBT is to provide polyfills for features standardized in C++ that we can't use yet for toolchain reasons (remember MOZ_OVERRIDE?); MFBT features get removed as we replace them with the corresponding std thing. Why would Range vs. GSL span be any different? On Fri, Jul 15, 2016 at 3:44 AM, Henri Sivonen wrote: > On Thu, Mar 24, 2016 at 6:01 PM, Jeff Muizelaar > wrote: > > On Wed, Jan 6, 2016 at 7:15 AM, Henri Sivonen > wrote: > >> On Thu, Oct 1, 2015 at 9:58 PM, Jonathan Watt wrote: > >>> For those who are interested in this, there's a bug to consider > integrating > >>> the Guidelines Support Library (GSL) into the tree: > >>> > >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1208262 > >> > >> This bug appears to have stalled. > >> > >> What should my expectations be regarding getting an equivalent of (at > >> least single-dimensional) GSL span (formerly array_view; > >> conceptually Rust's slice) into MFBT? > > > > Something like this already exits: mfbt/Range.h > > And we also have > https://dxr.mozilla.org/mozilla-central/source/gfx/src/ArrayView.h > whose comments say to prefer Range. > > ArrayView as well as GSL span use pointer and length while Range uses > pointer and pointer past end. > > Are we happy enough with Range to the point where Range should be > promoted in the codebase where the Core Guidelines would recommend > span? > > (What to call it is, of course, a total bikeshed, but when the Core > Guidelines are happening near the C++ standardization source of > authority, it seems rather NIH-y to call it something other than > "span" even if there are still compiler compat reasons [are there?] > not to use Microsoft's span.h outright.) > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > ___ > 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: Redesigning the docshell/loadgroup/document interaction
On 7/15/16 6:33 AM, Henri Sivonen wrote: While I've been looking at other things, have we already gained an object that tracks the load of a document all the way from when the navigation starts at link click through redirects before the document object exists? Sort of. There's the LoadInfo. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Core Guidelines
On Thu, Mar 24, 2016 at 6:01 PM, Jeff Muizelaar wrote: > On Wed, Jan 6, 2016 at 7:15 AM, Henri Sivonen wrote: >> On Thu, Oct 1, 2015 at 9:58 PM, Jonathan Watt wrote: >>> For those who are interested in this, there's a bug to consider integrating >>> the Guidelines Support Library (GSL) into the tree: >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1208262 >> >> This bug appears to have stalled. >> >> What should my expectations be regarding getting an equivalent of (at >> least single-dimensional) GSL span (formerly array_view; >> conceptually Rust's slice) into MFBT? > > Something like this already exits: mfbt/Range.h And we also have https://dxr.mozilla.org/mozilla-central/source/gfx/src/ArrayView.h whose comments say to prefer Range. ArrayView as well as GSL span use pointer and length while Range uses pointer and pointer past end. Are we happy enough with Range to the point where Range should be promoted in the codebase where the Core Guidelines would recommend span? (What to call it is, of course, a total bikeshed, but when the Core Guidelines are happening near the C++ standardization source of authority, it seems rather NIH-y to call it something other than "span" even if there are still compiler compat reasons [are there?] not to use Microsoft's span.h outright.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Redesigning the docshell/loadgroup/document interaction
On Fri, May 20, 2016 at 5:56 PM, Boris Zbarsky wrote: > Background: We have a problem right now where the thing representing a > "collection of loads" (a loadgroup) is attached to a docshell, not an > individual document. Slightly off-topic but: The notion of attaching load or loadingness into the docshell instead of the document has been a problem even for understanding the status of the document itself, so attaching stuff to the doc instead of the docshell seems generally good. While I've been looking at other things, have we already gained an object that tracks the load of a document all the way from when the navigation starts at link click through redirects before the document object exists? (Basically what's described at https://github.com/servo/servo/pull/3714#issuecomment-67650099 ) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Tree Closures due to Bug 1286942 Buildbot DB Issues
Hi, we currently have a complete tree closure due to Buildbot DB Issues. The Teams working on resolving this issue and the Tracking Bug is: https://bugzilla.mozilla.org/show_bug.cgi?id=1286942 There is no ETA yet for reopening. Thanks for your patience. - Tomcat P.S. one way to get patches checked-in automatically would be using MozReview and Autoland to push it when then tree reopens. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
On 2016-07-14 17:49, Mike Hoye wrote: On 2016-07-13 10:31 PM, ajo...@mozilla.com wrote: Our official Firefox builds on Linux support both PulseAudio and ALSA. There are a number of additional contributed backends that can be turned on at compile time, although contribution towards long-term maintenance and matching feature parity with the actively developed backends has been low. On Linux, we actively maintain the PulseAudio backend but we also approach the PulseAudio developers when we see issues in PulseAudio. The PulseAudio developers are generally good to work with. FWIW all of Arch, Fedora, Debian (including Raspian), (U/Ku/Xu)buntu, Mint, OpenSUSE ship PulseAudio by default, and have for a long time. You've got to work pretty hard to find a desktop linux distribution that doesn't; even Gentoo and Android-x86 have it reliably available. At least according to https://wiki.debian.org/PulseAudio, on Debian you don't get it by default when installing xfce or lxde. But I guess you can argue what by default means. I also wonder how this fallback thing works. Things are linked to the pulseaudio library, but if the pulseaudio binary isn't installed things fall back to something else like alsa as far as I know. Is this something the pulseaudio library does, or do you need to write the fallback yourself? Kurt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
