Re: Launch of Phabricator and Lando for mozilla-central
On 06/06/2018 15:57, Mark Côté wrote: Similarly, there are two other features which are not part of initial launch but will follow in subsequent releases: * Stacked revisions. If you have a stack of revisions, that is, two or more revisions with parent-child relationships, Lando cannot land them all at once. You will need to individually land them. This is filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1457525. Have we considered the impact this will have on our CI load? If we currently have (say — I didn't bother to compute the actual number) an average of 2 commits per push, it seems like this change could increase the load on inbound by a corresponding factor of 2 (or perhaps less if the multiple-final-commit workflow is so bad that people start pushing fewer, larger, changes). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Launch of Phabricator and Lando for mozilla-central
On Wednesday, 6 June 2018 19:58:43 UTC-4, Xidorn Quan wrote: > On Thu, Jun 7, 2018, at 12:57 AM, Mark Côté wrote: > > Phabricator is a suite of applications, but we are primarily using the > > code-review tool, called Differential, which will be taking the place of > > MozReview and Splinter. Bug tracking will continue to be done with > > Bugzilla, which is integrated with Phabricator. You will log into > > Phabricator via Bugzilla. We will soon begin sunsetting MozReview, and > > Splinter will be made read-only (or replaced with another patch viewer). > > An upcoming post will outline the plans for the deprecation, archival, > > and decommission of MozReview, with Splinter to follow. > > Does using Phabricator still require using the PHP client? I recall gps > mentioned before that there was a plan to integrate it into hg or mach > instead of requiring developers to install another runtime and client. How is > that going on? > > If the plan is that everyone should just install the PHP runtime and use that > client, maybe MozillaBuild should include PHP (installing it on Linux and > macOS should be included in mach bootstrap I guess). > > - Xidorn Yes, it still requires PHP, and yes, I'd like to bundle it. This depends, though, on how we end up improving commit-series support. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Pseudolocalization in Firefox Nightly!
Hi all! We've just landed a new hot developer-oriented feature in Firefox Nightly - Pseudolocalization. Pseudolocalization allows developers to quickly test their UI against fake localizations helping us discover internationalization issues earlier in the cycle. You can find an introduction video here: https://www.youtube.com/watch?v=pmT9PINv6nE An introduction blog post here: https://diary.braniecki.net/2018/06/07/pseudolocalization-in-firefox/ And documentation here: https://firefox-source-docs.mozilla.org/intl/l10n/docs/l10n/fluent_tutorial.html#pseudolocalization The functionality is directly related to the new localization framework - Fluent - and in result works in areas covered by Fluent - mainly Preferences at the moment. As Fluent becomes available in other parts of our codebase, pseudolocalization will come with it. We're looking forward to hear your feedback and requests for more features! zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal: WebIDL generated bindings classes renamed from dom::FooBinding to dom::binding::Foo
We have a name conflict under the current system when trying to use these two classes from the webgpu sketch webidl: - WebGPUBuffer - WebGPUBufferBinding I'm proposing renaming the generated bindings classes from dom::FooBinding to dom::binding::Foo. This seems like a reasonable use of namespaces, and will be immune from naming collisions coming from webidl. Also considered was dom::Foo_Binding. (webidl really shouldn't have underscores, but technically could!) Talking with bz, dom::bindings::Foo sounds better to us, though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: WebIDL generated bindings classes renamed from dom::FooBinding to dom::binding::Foo
+1 on the namespace idea. We started using mozilla::dom::FooBinding::[ConstantName] namespace for constants in bug 792059, so we may also want to change that to dom::binding::Foo::[ConstantName] for consistency sake. On Thu, Jun 7, 2018 at 1:03 PM, Jeff Gilbert wrote: > We have a name conflict under the current system when trying to use > these two classes from the webgpu sketch webidl: > - WebGPUBuffer > - WebGPUBufferBinding > > I'm proposing renaming the generated bindings classes from > dom::FooBinding to dom::binding::Foo. This seems like a reasonable use > of namespaces, and will be immune from naming collisions coming from > webidl. > > Also considered was dom::Foo_Binding. (webidl really shouldn't have > underscores, but technically could!) Talking with bz, > dom::bindings::Foo sounds better to us, though. > ___ > 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: Proposal: WebIDL generated bindings classes renamed from dom::FooBinding to dom::binding::Foo
On 6/7/18 4:24 PM, Kyle Machulis wrote: +1 on the namespace idea. We started using mozilla::dom::FooBinding::[ConstantName] namespace for constants in bug 792059, so we may also want to change that to dom::binding::Foo::[ConstantName] for consistency sake. Right, that change would be part of the proposal here. All FooBinding would become bindings::Foo. (I guess we have to watch out for bindings::Foo vs binding::Foo; I wonder whether we should just "namespace binding = bindings;" and let people spell it however.) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Please use XPCOMUtils.defineLazyGlobalGetters rather than Cu.importGlobalProperties
tl;dr: importGlobalProperties is expensive. If you don't need the imported properties immediately, please use defineLazyGlobalGetters instead. Calling importGlobalProperties immediately defines the properties that you're importing and any prototypes that they require. Aside from CPU overhead, this also tends to consume a lot of memory, especially for objects with complex prototypes. And it does this once for every global you call it in. This is especially a problem for content processes, since we get this memory overhead in each and every content process (and remember, as a part of Project Fission, we're aiming to be able to run 100 content processes for ordinary users). Ordinary WebIDL globals don't really have this problem, since they're already defined lazily via resolveProperty hooks. In bug 1464548, I added XPCOMUtils.defineLazyGlobalGetters, which has somewhat similar behavior, and also has the benefit of always creating the global in the shared JSM module scope, no matter which global it's called from. Please use that helper from now on unless you have a very good reason not to. Thanks. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
