Re: Moving reviews to Phabricator
If you commit with `hg commit -u` and post it to Phabricator, it will show up as authored by you in Phabricator, but when it lands it will have the correct attribution (i.e., the user you specified with `-u`). - brennie On Wed, Feb 6, 2019 at 7:27 PM Masayuki Nakano wrote: > > I sometimes rewrite patches from new contributor and commit them with > `-u` and the contributors name and email address, and land the patches > for them. E.g., https://bugzil.la/1513405 > > Is it possible to do that via Phabricator and Lando? If not, what should > I do when I meet similar situation? > > Of course, it is the best that contributors work all for their patches, > but in my experience, they may not update their patches after review or > they may don't have much time to update quickly. So, I think that full > timers should support them as far as possible. > > On 2019/02/07 5:42, Kim Moir wrote: > > On February 28 Bugzilla review flags will be disabled for Firefox and other > > mozilla-central products and components. From this point forward, all > > reviews of code changes to mozilla-central should be conducted in > > Phabricator. Tasks that have been identified as crucial to this transition > > have been set as blocker bugs to https://bugzil.la/1514775. > > -- > Masayuki Nakano > Software Engineer, Mozilla > ___ > 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: Moving reviews to Phabricator
I sometimes rewrite patches from new contributor and commit them with `-u` and the contributors name and email address, and land the patches for them. E.g., https://bugzil.la/1513405 Is it possible to do that via Phabricator and Lando? If not, what should I do when I meet similar situation? Of course, it is the best that contributors work all for their patches, but in my experience, they may not update their patches after review or they may don't have much time to update quickly. So, I think that full timers should support them as far as possible. On 2019/02/07 5:42, Kim Moir wrote: On February 28 Bugzilla review flags will be disabled for Firefox and other mozilla-central products and components. From this point forward, all reviews of code changes to mozilla-central should be conducted in Phabricator. Tasks that have been identified as crucial to this transition have been set as blocker bugs to https://bugzil.la/1514775. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New method for registering XPCOM components
On Wed, Feb 6, 2019 at 2:25 PM Kris Maglione wrote: > >* Perhaps a link (or multiple links) to MDN docs we already > >have on XPCOM components - which may provide an introduction as > >to what they are, when and why they’re used, etc. > > I'm not sure this is a good idea. Docs about Gecko internals on > MDN are generally deprecated, and the ones about XPCOM are > obsolete to the point of being useless. +1, just say no to internal docs on MDN. Documentation that we can auto-generate from the source code directly is preferred over standalone docs, although even in the latter case it's much better to have this live alongside the source code so we know which revision of m-c it applies to. In both cases https://firefox-source-docs.mozilla.org/ should always be used for Firefox internals, and MDN only for web standards and standard-ish things like WebExtension APIs. Speaking of auto-generation, could some/all of the code blocks in https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/build/docs/defining-xpcom-components.rst be generated via autodoc from https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/xpcom/components/gen_static_components.py ? I suspect it'd increase the readability of that file and make it easier to modify if those bits were separated into a Python class anyway. Note that I don't have particularly strong feelings about this, if you think it's easier to keep the docs separate and/or don't expect to change it much in the future then that's fine too. > I'm also a bit leery about mentioning old coding styles in docs > like this, since those kinds of mentions tend to stick around > long after everyone has forgotten that style ever really > existed... Agreed, we're still dealing with fall-out from people getting confused about old add-ons documentation and snippets etc. that look official since they are on MDN. An even better example where this causes confusion over internals is https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Observer_Notifications - that would be a great candidate for auto-generating from source code. > >* An example of ‘old style’ vs. ’new style’ xpcom definition, > > perhaps even a ‘good’ vs. ‘bad’ - but there’s a negative > > connotation there, which may not be preferred. > >* A full example (prolly on a second page would be best), which > > showcases the discrete steps to get from zero to hero. Err, I > > mean new component. > > > >I’m suggesting all this extra work, because I think it will > >actually save you a lot in the future; rtfm is a very simple, > >yet powerful response to all the queries you’re gonna get. > > Again, I'm not sure the linked doc is really the best place for > such things, since the doc is meant to be permanent, and it > would get dated fast. > > I can give examples in this thread, if you think it would be > useful. But given that I've already converted (or have pending > patches to convert) pretty much all of our old-style > registrations, it wasn't clear to me that it would. I would like to see examples in this thread. It'll be as easy to link folks to the mailing list archive, and it'll be clearer that it's ephemeral since it's a mailing list from a specific time period. Thanks again for making this change :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New method for registering XPCOM components
On Wed, Feb 06, 2019 at 11:31:20AM +0100, Michael de Boer wrote: That looks really neat and a nice step forward! I’m a fan of all the things you’re doing, btw ;-) Cheers. * Perhaps a link (or multiple links) to MDN docs we already have on XPCOM components - which may provide an introduction as to what they are, when and why they’re used, etc. I'm not sure this is a good idea. Docs about Gecko internals on MDN are generally deprecated, and the ones about XPCOM are obsolete to the point of being useless. I'm also a bit leery about mentioning old coding styles in docs like this, since those kinds of mentions tend to stick around long after everyone has forgotten that style ever really existed... * An example of ‘old style’ vs. ’new style’ xpcom definition, perhaps even a ‘good’ vs. ‘bad’ - but there’s a negative connotation there, which may not be preferred. * A full example (prolly on a second page would be best), which showcases the discrete steps to get from zero to hero. Err, I mean new component. I’m suggesting all this extra work, because I think it will actually save you a lot in the future; rtfm is a very simple, yet powerful response to all the queries you’re gonna get. Again, I'm not sure the linked doc is really the best place for such things, since the doc is meant to be permanent, and it would get dated fast. I can give examples in this thread, if you think it would be useful. But given that I've already converted (or have pending patches to convert) pretty much all of our old-style registrations, it wasn't clear to me that it would. On 5 Feb 2019, at 22:12, Kris Maglione wrote: As of bug 1478124, the new preferred method for registering XPCOM components is via static manifest files, as documented here: https://firefox-source-docs.mozilla.org/build/buildsystem/defining-xpcom-components.html And, as of bug 1524688, it will be the preferred method of defining JavaScript components as well as native ones. The primary motivation for this change is to decrease the amount of memory (and, to a lesser extent, startup performance) overhead that component registrations consume in content processes, which would not have been acceptable in the post-Fission world. It has the side-benefit, though, of making most registrations much more straightforward, requiring only a single entry, in a single place, for each component. Thank you to all of the reviewers who had to review a lot of very large patches to make this possible, particularly Nathan Froyd, Eric Rahm, and Mike Conley, on whom I dumped most of the biggest chunks. -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation All great truths begin as blasphemies. --George Bernard Shaw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving reviews to Phabricator
FWIW, I have exactly one machine with everything set up, and git-fetch/push and ssh into it in order to push up or pull down from moz-central. On Wed, Feb 6, 2019 at 12:49 PM Jörg Knobloch wrote: > > On 06/02/2019 21:42, Kim Moir wrote: > > On February 28 Bugzilla review flags will be disabled for Firefox and other > > mozilla-central products and components. From this point forward, all > > reviews of code changes to mozilla-central should be conducted in > > Phabricator. Tasks that have been identified as crucial to this transition > > have been set as blocker bugs tohttps://bugzil.la/1514775. > > Any simplification in sight to get this set up more easily for Windows > users? > > Last I looked you needed 12 steps to get there: > https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html > > I have three Windows development machines to set up :-( > > Jörg. > > > ___ > 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: Moving reviews to Phabricator
On 06/02/2019 21:42, Kim Moir wrote: On February 28 Bugzilla review flags will be disabled for Firefox and other mozilla-central products and components. From this point forward, all reviews of code changes to mozilla-central should be conducted in Phabricator. Tasks that have been identified as crucial to this transition have been set as blocker bugs tohttps://bugzil.la/1514775. Any simplification in sight to get this set up more easily for Windows users? Last I looked you needed 12 steps to get there: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html I have three Windows development machines to set up :-( Jörg. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Moving reviews to Phabricator
On February 28 Bugzilla review flags will be disabled for Firefox and other mozilla-central products and components. From this point forward, all reviews of code changes to mozilla-central should be conducted in Phabricator. Tasks that have been identified as crucial to this transition have been set as blocker bugs to https://bugzil.la/1514775. FAQ Phabricator transition Are we ready for this? The weekly average number of commits to mozilla-central that were reviewed in Phabricator has been hovering around 80% for many weeks now. While the system can always be improved, this number indicates that most engineers are able to use Phabricator effectively. The Engineering Workflow team has discussed this change with the remaining high-volume users of the old workflow to ensure there are no showstoppers with Phabricator. If you think there may be something we’ve missed, please get in touch with us directly. . What products and components will have the review flag disabled? The list includes the Core, Firefox, Firefox Build System, NSS, Geckoview and Toolkit products. It will also include some components of the Release Engineering and Testing products. It is entirely possible that we will miss some products/components, but users should not treat such omissions as invitations to continue to use Bugzilla for mozilla-central reviews. Adjustments will be made over time as necessary. Any code that will be landed to mozilla-central should be reviewed in Phabricator. Why are we making this change? Requiring Phabricator for code reviews will allow us to improve code quality by running linters and static analysis tools automatically on patches. It will also allow us to simplify and standardize our engineering workflow by reducing the number of request queues that developers are expected to monitor. The previous post ( https://groups.google.com/forum/#!topic/mozilla.dev.platform/JKbDxHSaVfM) announcing the general availability of Phabricator has further details and links to documentation. What about uplifts? Initially, only code landing in mozilla-central will be required to be reviewed in Phabricator. Once we have implemented more processes in Phabricator, we will move reviews of all of the mozilla-central “branches” to Phabricator. I have an unusual use case using patches and Bugzilla, how do I use Phabricator to do this? We’ve put together documentation https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html on how to accomplish various common tasks in Phabricator. If you’re doing something unusual that truly can’t be done with Phabricator, you can of course still attach a file to Bugzilla, and use a needinfo or IRC ping to get sign-off from the reviewer. We expect these cases to be exceedingly rare, and ask that developers use Phabricator wherever possible to unlock the benefits described above. Please also reference the Bugzilla actions and their equivalents on Phabricator https://wiki.mozilla.org/Phabricator/Bugzilla_Equivalents documentation. Where can I reach out if I have questions? Please reach out in the #phabricator channel in irc or Slack. Kim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Process Priority Manager enabled on Nightly for Windows (only)
>Hey Valentin, > >That's a good question. I haven't yet noticed any difference yet, but >I'm hoping people can keep an eye out to see if there's appreciable lag >when switching back to a tab with video, or if background audio starts >to stutter. Also this could impact webrtc calls or perhaps webrtc-based datachannel applications (file transfers, games, etc, though likely if it's just priority this won't be a problem). -- Randell Jesup, Mozilla Corp remove "news" for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New method for registering XPCOM components
Thanks so much for doing this! Having static XPCOM component manifests will be awesome both for Fission memory usage, and just general usability of our codebase into the future. On Tue, Feb 5, 2019 at 4:12 PM Kris Maglione wrote: > As of bug 1478124, the new preferred method for registering XPCOM > components > is via static manifest files, as documented here: > > > https://firefox-source-docs.mozilla.org/build/buildsystem/defining-xpcom-components.html > > And, as of bug 1524688, it will be the preferred method of defining > JavaScript components as well as native ones. > > The primary motivation for this change is to decrease the amount of memory > (and, to a lesser extent, startup performance) overhead that component > registrations consume in content processes, which would not have been > acceptable in the post-Fission world. It has the side-benefit, though, of > making most registrations much more straightforward, requiring only a > single > entry, in a single place, for each component. > > > Thank you to all of the reviewers who had to review a lot of very large > patches to make this possible, particularly Nathan Froyd, Eric Rahm, and > Mike Conley, on whom I dumped most of the biggest chunks. > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New and improved "about:config" for Firefox Desktop
>On 1/26/2019 10:09 AM, khagar...@gmail.com wrote: >> Does it take into account that the sorting is preserved between about:config >> calls? > >No, but 0.4% is still very low. We could imagine that a lot of people >keep the table sorted by type at all times, or that only a few people >do or even know that they can sort, depending on where our confirmation >bias stands. We're aware of this, and this is why this data point is >definitely not the only element that will influence the direction here. I frequently wished to see (only) modified prefs... and never realized I could sort on modification status. -- Randell Jesup, Mozilla Corp remove "news" for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: New method for registering XPCOM components
Hi Kris, That looks really neat and a nice step forward! I’m a fan of all the things you’re doing, btw ;-) Whilst reading through the docs you pointed at, I was missing a few things, to be honest: * Perhaps a link (or multiple links) to MDN docs we already have on XPCOM components - which may provide an introduction as to what they are, when and why they’re used, etc. * An example of ‘old style’ vs. ’new style’ xpcom definition, perhaps even a ‘good’ vs. ‘bad’ - but there’s a negative connotation there, which may not be preferred. * A full example (prolly on a second page would be best), which showcases the discrete steps to get from zero to hero. Err, I mean new component. I’m suggesting all this extra work, because I think it will actually save you a lot in the future; rtfm is a very simple, yet powerful response to all the queries you’re gonna get. Cheers, Mike. > On 5 Feb 2019, at 22:12, Kris Maglione wrote: > > As of bug 1478124, the new preferred method for registering XPCOM components > is via static manifest files, as documented here: > > https://firefox-source-docs.mozilla.org/build/buildsystem/defining-xpcom-components.html > > And, as of bug 1524688, it will be the preferred method of defining > JavaScript components as well as native ones. > > The primary motivation for this change is to decrease the amount of memory > (and, to a lesser extent, startup performance) overhead that component > registrations consume in content processes, which would not have been > acceptable in the post-Fission world. It has the side-benefit, though, of > making most registrations much more straightforward, requiring only a single > entry, in a single place, for each component. > > > Thank you to all of the reviewers who had to review a lot of very large > patches to make this possible, particularly Nathan Froyd, Eric Rahm, and Mike > Conley, on whom I dumped most of the biggest chunks. > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
