Re: Canonical cinnabar repository

[Myk Melez]

Ehsan Akhgari 
2017 September 18 at 12:59
I think there is a way to have our cake and eat it too, which is 
enabling git-cinnabar to understand a custom mapping of SHA1 so that 
we can rewrite the history and have cinnabar be able to deal with that 
when it maps hg/git revisions to each other.
We might be able to use Git's replace command [1], which enables you to 
"graft" one history onto another without rewriting revision IDs, such 
that Git commands like log, bisect, and blame traverse the two histories 
as one.


To test this out, I created a new repository mykmelez/gecko-test [2]; 
imported CVS history into a branch called "cvs"; imported the "central" 
branch from mozilla/gecko [3] (which is synced with cinnabar); and 
replaced e18f9a37a98d, which is the initial (earliest) commit on the 
central branch, with 3ec464b55782, which is the tip (latest) commit on 
the cvs branch.


The resulting log, starting from a9d623d0878b (the third-earliest commit 
on central), still shows e18f9a37a98d but decorates it with the 
"(replaced)" label and displays its replacement's commit message, after 
which the next two commits (55d824018c96 and 62453dda752a) are from CVS 
history:



 git log --oneline --decorate a9d623d0878b

a9d623d0878b Bug 374866. Reftests for text-transform. r=dbaron
028d2077b626 Free the (distributed) Lizard! Automatic merge from CVS: 
Module mozilla: tag HG_REPO_INITIAL_IMPORT at 22 Mar 2007 10:30 PDT,
e18f9a37a98d (replaced) - update headers - remove pango workarounds - 
update wget files paths

55d824018c96 - updating headers
62453dda752a split out breakpad symbol build and upload into two config 
options, r=preed


Neither history is altered, as the replacement is stored as a ref (in 
refs/replace/), which most Git commands respect ("except those doing 
reachability traversal (prune, pack transfer and fsck)"). So the store 
still contains the original initial mozilla-central commit:



 git --no-replace-objects log --oneline --decorate e18f9a37a98d

e18f9a37a98d Set up .hgignore to ignore CVS files.

And removing the replacement ref reverts the "graft," returning the two 
histories to their original, disconnected state.


A downside of this approach is that the replacement ref isn't fetched by 
default. You need to fetch it manually after cloning the repo:


git fetch origin 'refs/replace/*:refs/replace/*'

But you only need to do that once. And if you don't do it, you still get 
a working clone with a central branch that is the equivalent of 
mozilla-central cloned with cinnabar, along with a branch containing the 
CVS history. You just don't get combined history.


The CVS history doesn't take much space either. A fresh clone of 
mozilla/gecko takes 4.9GB on my system, while a fresh clone of 
mykmelez/gecko-test takes 5.2GB (about the same as gecko-dev, which is 
5.3GB).


So this seems like a promising option for having our cake and eating it 
too. Although further investigation is warranted to ensure that it works 
well with the Git commands (and editor integrations) that developers use 
when traversing history.


-myk

[1] https://git-scm.com/book/en/v2/Git-Tools-Replace
[2] https://github.com/mykmelez/gecko-test
[3] https://github.com/mozilla/gecko

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Experiment: CSS Houdini Paint API Level 1

[tombouchard001]

Le jeudi 5 janvier 2017 11:01:04 UTC-5, Jet Villegas a écrit :
> Spec: https://drafts.css-houdini.org/css-paint-api/
> 
> Summary: The CSS Paint API is the first of several Web Rendering proposals
> from the CSS Houdini Task Force. The CSS Paint API allows Web authors to
> define and register a custom Paint method to be executed by the Layout
> engine as other elements are rendered.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1302328
> 
> Link to standard: https://drafts.css-houdini.org/css-paint-api/
> 
> Platform coverage: Android, Desktop
> 
> Estimated or target release: TBD
> 
> Preference behind which this will be implemented: TBD
> 
> DevTools bug: TBD
> 
> Tests - TBD
> 
> Implementation Details:
> 
> CSS Paint API depends on the implementation of the following features:
> CSS Houdini Properties & Values - https://bugzilla.mozilla.org/
> show_bug.cgi?id=1273706
> Houdini "Worklets" - https://bugzilla.mozilla.org/show_bug.cgi?id=1290021
> 
> The planned implementation in Gecko builds upon the HTML5 Canvas2D API to
> provide the rendering surface for CSS Paint.
> 
> Risks:
> 
> The experimental implementation has progressed enough to warrant this
> public Intent to Implement. However, significant risks will need to be
> mitigated by careful design and execution if these features are to pass the
> experimental stage and ship in Firefox, including:
> 
> 1. Use Cases. It's not clear that the use cases proposed in the
> specification warrant the additional Rendering System complexity. Apart
> from conical gradients, we haven't seen many author requests for the other
> use cases. If the existing Canvas2D feature set is lacking, what are the
> compelling use cases and maximally useful API for such use cases? It's not
> clear that the proposed Canvas2D-based API is desirable over a different
> API design (eg., WebGL) if most use cases need to directly manipulate
> pixels.
> 
> 2. Rendering Performance. The planned Canvas2D backing store approach may
> be too slow for real-world usage of the API. In the future, we may replace
> the Canvas2D approach to have the custom paint methods create Layout
> (displayList) nodes for direct rendering by the Layout engine, bypassing
> the need for a Canvas2D backing store. It's worth noting that the Paint API
> isn't directly compatible with existing displayList nodes (e.g., support
> for raw paths, funny shapes, & pixel manipulation.)
> 
> There may also be other performance issues that arise with the API's usage
> in combination with existing CSS features (e.g., CSS Masking, Filters,
> etc.) The displayList vs. canvas bitmap implementation would probably look
> a good bit different in WebRender. It's also worth noting that multiple
> implementations shipping a bitmap-based version can create dependencies
> that prevent us from switching to a faster alternative version in the
> future.
> 
> 3. Integration with Gecko Architecture. The Quantum Project <
> https://wiki.mozilla.org/Quantum> is a major overhaul of the Firefox
> Rendering Engine. Implementing the CSS Paint API while that effort is in
> progress may add significant impedance. However, a counter-argument is that
> we should design Quantum to allow for such extensibility in the future.
> Duplication of work ( writing code that would need to be rewritten for
> Quantum ) is not desirable and should be avoided.
> 
> For WebRender/Quantum, we could initially push this through the same path
> that SVG will go through (which will be rasterized on the CPU and then
> cached in a GPU texture atlas). It does seem like Houdini Paint could
> reduce the amount of acceleration we can do on the GPU (at least in the
> short term), but we won't be any worse off than other browsers in that
> regard.
> 
> 4. Dependency on incomplete implementations/specifications. The dependency
> creates a chicken/egg scenario where we can't sufficiently evaluate the
> dependent specifications (e.g, Worklets, and Properties & Values) without
> also implementing an initial key use case (e.g., CSS Paint or Worklets for
> Web Audio.) This is somewhat mitigated by getting the implementation far
> enough along to formulate informed opinions on all the specifications.
> 
> The Houdini Task Force is meeting next week in Seattle to discuss this and
> other specifications.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: WebVR on macOS

[Kearwood Kip Gilbert]

As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has been 
developed behind the dom.vr.enabled preference.  We have already shipped WebVR 
by default for the Windows platform.  macOS support has been implemented for 
several months but disabled by default.  Our WebVR implementation supports 
OpenVR for the HTC Vive on macOS High Sierra, which is now hitting release.
This feature was previously discussed in this "intent to implement" thread: 
. 
Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
Link to standard: https://w3c.github.io/webvr/spec/1.1/
Testing: 
Automated tests have been implemented and are already active for the macOS 
builds in taskcluster.  Platform conformance tests are shared with other UA’s.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposed W3C Charter: Web Authentication Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Authentication Working Group
  https://www.w3.org/2017/08/web-authentication-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2017Aug/0008.html

Mozilla has the opportunity to send comments or objections through
Friday, September 22.  (Sorry for failing to send this out sooner!)

A diff relative to the current charter is:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F03%2Fweb-authentication-charter.html=https%3A%2F%2Fwww.w3.org%2F2017%2F08%2Fweb-authentication-charter.html

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose 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: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TabChild visibility

[Boris Zbarsky]

On 9/20/17 3:18 PM, Mike Conley wrote:

it appears to be possible to have a non-visible but
active DocShell (despite the documentation [4]).


The documentation is kinda wrong.  A simple example of an active but 
non-visible docshell is a display:none iframe in the currently selected tab.


I should be able to dig through the rest of this stuff on Friday if 
someone else hasn't done it by then.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TabChild visibility

[Ben Kelly]

FWIW, our nsIDocument::VisibilityState() is updated when the docshell goes
active:

http://searchfox.org/mozilla-central/source/dom/base/nsIDocument.h#2855
http://searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#12504
http://searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#12552
http://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#6343


On Wed, Sep 20, 2017 at 3:18 PM, Mike Conley  wrote:

> Hello dev-platform,
>
> TL;DR: TabChild's don't seem to care about the nsIBaseWindow visibility
> attribute that they implement. In fact, they often lie about it.
>
> What should we do about that? What's the best way to detect and tell the
> TabChild that it's visible or invisible?
>
> Also, what's the difference between DocShell visibility and activeness?
>
>
> Longer story:
>
> In bug 1353013, I'm dealing with a permanent failure that I've tracked down
> to Marionette's listener.js causing focus to be pulled in the hidden,
> preloaded about:newtab that is running in the content process.
>
> With e10s disabled, nsGlobalWindow::Focus bails out early, because the
> function checks its visibility (via the nsIBaseWindow interface), and
> determines that it is invisible (because of this function[1] that sees if
> the frame is in the selected frame of a deck).
>
> With e10s enabled, visibility seems to be a lot less useful - TabChild
> implements nsIBaseWindow, and ignores attempts to set visibility[2] and
> always reports that it is visible[3]. This means that nsGlobalWindow::Focus
> decides that focus is indeed something that the preloaded about:newtab can
> do, and that causes my test failures.
>
> It seems to me that a TabChild always reporting that it's visible isn't
> amazing. For a browser window with a number of tabs open, it's the case
> that only one of those tabs really is visible, naturally; so the rest of
> those TabChild's are straight-up lying. I have no idea what the
> ramifications of that lying are. Perhaps we're doing more work than we need
> to because we're skipping some "don't do it if we're invisible"
> optimizations. I'm not sure.
>
> At any rate, it seems to me that the solution to my problem is to have the
> TabChild report the truth about whether or not it's visible. Using a sync
> IPC message to ask the parent is asking for trouble, so instead, I suspect
> we'll want the TabChild to be _told_ when it's made visible and invisible.
>
> What is the best way of doing that? Is there a clean way of having the
> nsFrameLoader / TabParent be told when they've been set as the active frame
> in a deck or not? Or is this something that the front-end needs to take
> responsibility for (like we do for DocShell active-ness) and we need to
> have tabbrowser.xml tell the TabChild that it has become visible?
>
> Or, alternatively, should I tie the activeness of the TabChild's DocShell
> to its visibility? That would be a change in behaviour between e10s and
> non-e10s; in non-e10s, it appears to be possible to have a non-visible but
> active DocShell (despite the documentation [4]). Perhaps somebody here can
> shed some light on the relationship (or lack thereof) between active-ness
> and visibility?
>
> Thanks,
>
> -Mike
>
> [1]:
> http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592
> 41010701e0/layout/generic/nsFrame.cpp#405-409
> [2]:
> http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592
> 41010701e0/dom/ipc/TabChild.cpp#936-942
> [3]:
> http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592
> 41010701e0/dom/ipc/TabChild.cpp#929-934
> [4]:
> http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a41314524592
> 41010701e0/docshell/base/nsIDocShell.idl#659-664
> ___
> 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

TabChild visibility

[Mike Conley]

Hello dev-platform,

TL;DR: TabChild's don't seem to care about the nsIBaseWindow visibility
attribute that they implement. In fact, they often lie about it.

What should we do about that? What's the best way to detect and tell the
TabChild that it's visible or invisible?

Also, what's the difference between DocShell visibility and activeness?


Longer story:

In bug 1353013, I'm dealing with a permanent failure that I've tracked down
to Marionette's listener.js causing focus to be pulled in the hidden,
preloaded about:newtab that is running in the content process.

With e10s disabled, nsGlobalWindow::Focus bails out early, because the
function checks its visibility (via the nsIBaseWindow interface), and
determines that it is invisible (because of this function[1] that sees if
the frame is in the selected frame of a deck).

With e10s enabled, visibility seems to be a lot less useful - TabChild
implements nsIBaseWindow, and ignores attempts to set visibility[2] and
always reports that it is visible[3]. This means that nsGlobalWindow::Focus
decides that focus is indeed something that the preloaded about:newtab can
do, and that causes my test failures.

It seems to me that a TabChild always reporting that it's visible isn't
amazing. For a browser window with a number of tabs open, it's the case
that only one of those tabs really is visible, naturally; so the rest of
those TabChild's are straight-up lying. I have no idea what the
ramifications of that lying are. Perhaps we're doing more work than we need
to because we're skipping some "don't do it if we're invisible"
optimizations. I'm not sure.

At any rate, it seems to me that the solution to my problem is to have the
TabChild report the truth about whether or not it's visible. Using a sync
IPC message to ask the parent is asking for trouble, so instead, I suspect
we'll want the TabChild to be _told_ when it's made visible and invisible.

What is the best way of doing that? Is there a clean way of having the
nsFrameLoader / TabParent be told when they've been set as the active frame
in a deck or not? Or is this something that the front-end needs to take
responsibility for (like we do for DocShell active-ness) and we need to
have tabbrowser.xml tell the TabChild that it has become visible?

Or, alternatively, should I tie the activeness of the TabChild's DocShell
to its visibility? That would be a change in behaviour between e10s and
non-e10s; in non-e10s, it appears to be possible to have a non-visible but
active DocShell (despite the documentation [4]). Perhaps somebody here can
shed some light on the relationship (or lack thereof) between active-ness
and visibility?

Thanks,

-Mike

[1]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/layout/generic/nsFrame.cpp#405-409
[2]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/dom/ipc/TabChild.cpp#936-942
[3]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/dom/ipc/TabChild.cpp#929-934
[4]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/docshell/base/nsIDocShell.idl#659-664
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Creating a content process during shutdown...

[Milan Sreckovic]

I've spoken to some of you about this, but at this point need a larger 
audience to make sure we're covering all the bases.


Do we have code in Firefox that would cause us to create a new content 
process, after we've entered shutdown?


I understand the possibility of user action that would create a new 
content process followed quickly by one that would cause shutdown, and 
the timing making it so that the new content process initialization can 
then happen out of order, but I'm more asking about the explicit scenario.


Thanks!

--
- Milan (mi...@mozilla.com)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[J. Ryan Stinnett]

There are also some details about MozReview with git-cinnabar at:

http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/install-git.html

though it doesn't seem to appear in the contents sidebar on the left, so it
would be nice to make it more discoverable. (Though I suppose Phabricator
will be the tool we use soonish...)

- Ryan

On Wed, Sep 20, 2017 at 12:04 PM, Jeff Muizelaar 
wrote:

> I would recommend
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-
> git-workflow-for-Gecko-development.
>
> The other places should probably be updated to point at that.
>
> -Jeff
>
> On Wed, Sep 20, 2017 at 12:57 PM, Ethan Glasser-Camp
>  wrote:
> > Sorry if this is a bit off-topic. It seems from these threads that there
> is
> > a more-or-less canonical way to use git to hack on Firefox. Where can I
> > find out more about it?
> >
> > Looking online, the only information I could find was at
> > https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-
> git-workflow-for-Gecko-development.
> > Is that the best source of information? I didn't see anything under
> > https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
> > http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
> > https://firefox-source-docs.mozilla.org/.
> >
> > Thanks!
> >
> > Ethan
> >
> >
> > On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
> > wrote:
> >
> >> This message was inspired by the `mach try` thread but is off-topic
> >> there so I think deserves its own thread.
> >>
> >> It seems to me that a lot of people are now assuming a cinnabar repo
> >> is the canonical way for git users to develop on mozilla-central. If
> >> we want to make this mozilla policy I don't really have objections,
> >> but I think that if we do that, we should maintain a canonical git
> >> repo that is built using cinnabar, rather than having everybody have
> >> their own "grafted" version of a cinnabar repo. The problem with the
> >> latter approach is that different people will have different SHAs for
> >> the same upstream commit, thus making it much harder to share repos.
> >>
> >> I've tried using cinnabar a couple of times now and the last time I
> >> tried, this was the dealbreaker for me. My worfklow often involves
> >> moving a branch from one machine to another and the extra hassle that
> >> results from mismatched SHAs makes it much more complicated than it
> >> needs to be. gecko-dev doesn't have this problem as it has a canonical
> >> upstream that works much more like a regular git user expects.
> >>
> >> As an aside, I also think that the cinnabar workflow as it exists now
> >> actually demotes git to more of a "second-class citizen".
> >> Conceptually, if you're using gecko-dev, everything works exactly as a
> >> git user would expect, and only when you need to push to official
> >> mozilla hg repos do you need to overcome the vcs translation hurdle
> >> (which things like moz-git-tools help with). However if you use
> >> cinnabar the vcs translation is more woven into your everyday git
> >> commands (e.g. git pull) and you need to be more consciously aware of
> >> it. This makes it harder to use whatever your normal git workflow is,
> >> which is why I claim it demotes git to second-class. It would be great
> >> if we could come up with a way to avoid this but honestly since I
> >> haven't used a cinnabar workflow for any significant period of time I
> >> haven't given much thought as to how to go about doing this.
> >>
> >> Discussion welcome!
> >>
> >> Cheers,
> >> kats
> >> ___
> >> 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
> ___
> 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: Canonical cinnabar repository

[Soledad Penadés]

I started with that wiki page, but I am (lazy|efficient), so I automated 
it the next time I had to perform those steps in a different computer:


https://github.com/sole/cinnabarify

My script will set up remotes and stuff including setting up the helper 
(otherwise it'll be too slow for practical purposes). If you just want 
to look at what it does instead of running it:


https://github.com/sole/cinnabarify/blob/master/main.sh

There's also a list of frequent tasks and how to perform them e.g. 
updating from 'm-c', sending patches, pushing to mozreview, etc, as I 
didn't know how to use the resulting repo.


Hope that's useful. I particularly use the README all the time :)

Caveats: I couldn't make it work in Bash on windows, and it doesn't 
"say" in Linux, but the rest should work.


sole


On 20/09/2017 18:04, Jeff Muizelaar wrote:

I would recommend
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.

The other places should probably be updated to point at that.

-Jeff

On Wed, Sep 20, 2017 at 12:57 PM, Ethan Glasser-Camp
 wrote:

Sorry if this is a bit off-topic. It seems from these threads that there is
a more-or-less canonical way to use git to hack on Firefox. Where can I
find out more about it?

Looking online, the only information I could find was at
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
Is that the best source of information? I didn't see anything under
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
https://firefox-source-docs.mozilla.org/.

Thanks!

Ethan


On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
wrote:


This message was inspired by the `mach try` thread but is off-topic
there so I think deserves its own thread.

It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really have objections,
but I think that if we do that, we should maintain a canonical git
repo that is built using cinnabar, rather than having everybody have
their own "grafted" version of a cinnabar repo. The problem with the
latter approach is that different people will have different SHAs for
the same upstream commit, thus making it much harder to share repos.

I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.

As an aside, I also think that the cinnabar workflow as it exists now
actually demotes git to more of a "second-class citizen".
Conceptually, if you're using gecko-dev, everything works exactly as a
git user would expect, and only when you need to push to official
mozilla hg repos do you need to overcome the vcs translation hurdle
(which things like moz-git-tools help with). However if you use
cinnabar the vcs translation is more woven into your everyday git
commands (e.g. git pull) and you need to be more consciously aware of
it. This makes it harder to use whatever your normal git workflow is,
which is why I claim it demotes git to second-class. It would be great
if we could come up with a way to avoid this but honestly since I
haven't used a cinnabar workflow for any significant period of time I
haven't given much thought as to how to go about doing this.

Discussion welcome!

Cheers,
kats
___
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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
http://soledadpenades.com

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jeff Muizelaar]

I would recommend
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.

The other places should probably be updated to point at that.

-Jeff

On Wed, Sep 20, 2017 at 12:57 PM, Ethan Glasser-Camp
 wrote:
> Sorry if this is a bit off-topic. It seems from these threads that there is
> a more-or-less canonical way to use git to hack on Firefox. Where can I
> find out more about it?
>
> Looking online, the only information I could find was at
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
> Is that the best source of information? I didn't see anything under
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
> http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
> https://firefox-source-docs.mozilla.org/.
>
> Thanks!
>
> Ethan
>
>
> On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
> wrote:
>
>> This message was inspired by the `mach try` thread but is off-topic
>> there so I think deserves its own thread.
>>
>> It seems to me that a lot of people are now assuming a cinnabar repo
>> is the canonical way for git users to develop on mozilla-central. If
>> we want to make this mozilla policy I don't really have objections,
>> but I think that if we do that, we should maintain a canonical git
>> repo that is built using cinnabar, rather than having everybody have
>> their own "grafted" version of a cinnabar repo. The problem with the
>> latter approach is that different people will have different SHAs for
>> the same upstream commit, thus making it much harder to share repos.
>>
>> I've tried using cinnabar a couple of times now and the last time I
>> tried, this was the dealbreaker for me. My worfklow often involves
>> moving a branch from one machine to another and the extra hassle that
>> results from mismatched SHAs makes it much more complicated than it
>> needs to be. gecko-dev doesn't have this problem as it has a canonical
>> upstream that works much more like a regular git user expects.
>>
>> As an aside, I also think that the cinnabar workflow as it exists now
>> actually demotes git to more of a "second-class citizen".
>> Conceptually, if you're using gecko-dev, everything works exactly as a
>> git user would expect, and only when you need to push to official
>> mozilla hg repos do you need to overcome the vcs translation hurdle
>> (which things like moz-git-tools help with). However if you use
>> cinnabar the vcs translation is more woven into your everyday git
>> commands (e.g. git pull) and you need to be more consciously aware of
>> it. This makes it harder to use whatever your normal git workflow is,
>> which is why I claim it demotes git to second-class. It would be great
>> if we could come up with a way to avoid this but honestly since I
>> haven't used a cinnabar workflow for any significant period of time I
>> haven't given much thought as to how to go about doing this.
>>
>> Discussion welcome!
>>
>> Cheers,
>> kats
>> ___
>> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Ethan Glasser-Camp]

Sorry if this is a bit off-topic. It seems from these threads that there is
a more-or-less canonical way to use git to hack on Firefox. Where can I
find out more about it?

Looking online, the only information I could find was at
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
Is that the best source of information? I didn't see anything under
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
https://firefox-source-docs.mozilla.org/.

Thanks!

Ethan


On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
wrote:

> This message was inspired by the `mach try` thread but is off-topic
> there so I think deserves its own thread.
>
> It seems to me that a lot of people are now assuming a cinnabar repo
> is the canonical way for git users to develop on mozilla-central. If
> we want to make this mozilla policy I don't really have objections,
> but I think that if we do that, we should maintain a canonical git
> repo that is built using cinnabar, rather than having everybody have
> their own "grafted" version of a cinnabar repo. The problem with the
> latter approach is that different people will have different SHAs for
> the same upstream commit, thus making it much harder to share repos.
>
> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs makes it much more complicated than it
> needs to be. gecko-dev doesn't have this problem as it has a canonical
> upstream that works much more like a regular git user expects.
>
> As an aside, I also think that the cinnabar workflow as it exists now
> actually demotes git to more of a "second-class citizen".
> Conceptually, if you're using gecko-dev, everything works exactly as a
> git user would expect, and only when you need to push to official
> mozilla hg repos do you need to overcome the vcs translation hurdle
> (which things like moz-git-tools help with). However if you use
> cinnabar the vcs translation is more woven into your everyday git
> commands (e.g. git pull) and you need to be more consciously aware of
> it. This makes it harder to use whatever your normal git workflow is,
> which is why I claim it demotes git to second-class. It would be great
> if we could come up with a way to avoid this but honestly since I
> haven't used a cinnabar workflow for any significant period of time I
> haven't given much thought as to how to go about doing this.
>
> Discussion welcome!
>
> Cheers,
> kats
> ___
> 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: BHR Project Status

[Doug Thayer]

On Wed, Sep 20, 2017 at 9:06 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> > What impact has a stack which is being reported at 1% / 0.5% / 0% ?
>
> I see that the histograms on top are changing each time I highlight a new
> line.  When I mouse-over the histograms buckets I notice the  "ms/h" metric.
>
> What does it mean?  Does that mean that in any browsing session, any user
> will see the given signature for X ms per hour?
>

As a mean value, and for the date in question, yes. If a particular prefix
list of stack frames is responsible for one 20 second hang for one in 10
users every 5 hours (pretending all users use Nightly for the same number
of hours per day), you'll see a value of 20,000 / 10 / 5  == 400ms/h.


>
> Should the left column of the profiles report the time in  ms/h  instead
> of unit-less % ?
>

That's a good suggestion. I'll work on getting units in there.


>
> > Is the histogram indexed by build-id / report-date?
>

Build ID.


> > Is there a way to get the URL on which these hangs are reported?
>

If I'm understanding your question correctly I believe that's a privacy
issue. Maybe if we end up going with RAPPOR we'll be able to see some
aggregate stats on hanginess of particular domains though. Or we could
prompt Nightly users to opt into sending more sensitive information, but
that brings biases with it.


>
> > Can we have a larger history of hangs per signatures? (similar to
> crash-stat [1])
>

I'm working on keeping a dataset which will always go back to Sept. 1st.
[1] I think we should be able to maintain this, however the performance of
the UI will need to be addressed in some way, as even now it's a bit of a
hog.


>
> Calixte made a tool to associate a newly reported crash to a recent
> changes.  Would it be possible to look at the same kind of tools based on
> the reports of the BHR, with a given buildId ?
>

Do you have a link to this tool, so I can understand a little better?


[1] https://arewesmoothyet.com/?category=all=2048_65536_
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: BHR Project Status

[Nicolas B. Pierron]

On 09/20/2017 01:52 PM, Michael Layzell wrote:

Doug Thayer has written a visualizer for the collected data called
hangs.html (https://arewesmoothyet.com), based on the perf.html profiler
viewer. This interface allows analysis of the change in frequency of
specific hangs over time, lots of tools for filtering through hang
information, as well as a profiler-like interface for drilling into
specific hang stacks to determine what might be causing the problems.


This looks like a really interesting tools, and I am glad we have this 
information in a much more readable format now! While I think I got a rough 
idea of the content which is presented, I want to make sure I read this 
content correctly.


Thus, I have a few questions/comments, related to reading these data, and 
also related to investigating these reports, and to determine the importance 
(impact/priority) that we should give to each of these issues.



> What impact has a stack which is being reported at 1% / 0.5% / 0% ?

I see that the histograms on top are changing each time I highlight a new 
line.  When I mouse-over the histograms buckets I notice the  "ms/h" metric.


What does it mean?  Does that mean that in any browsing session, any user 
will see the given signature for X ms per hour?


Should the left column of the profiles report the time in  ms/h  instead of 
unit-less % ?


> Is the histogram indexed by build-id / report-date?

> Is there a way to get the URL on which these hangs are reported?

> Can we have a larger history of hangs per signatures? (similar to 
crash-stat [1])


Calixte made a tool to associate a newly reported crash to a recent changes. 
 Would it be possible to look at the same kind of tools based on the 
reports of the BHR, with a given buildId ?


[1] 
https://crash-stats.mozilla.com/signature/?product=Firefox=57.0a1=RtlEnterCriticalSection%20%7C%20mozilla%3A%3Anet%3A%3ACacheStorageService%3A%3ACacheQueueSize=%3E%3D2017-03-20T15%3A55%3A32.000Z=%3C2017-09-20T15%3A55%3A32.000Z#graphs


--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

BHR Project Status

[Michael Layzell]

In the last few months we've been putting work into making the data which
we collect from the Background Hang Reporter (BHR) more usable and
actionable. We use BHR to measure the frequency and cause of browser hangs
(when the main thread's event loop doesn't process events for 128ms or
longer). The goal being to collect information which lets us improve
Firefox's responsiveness by reducing the frequency of main thread hangs.

On the data collection side, the BHR stack walking code has been rewritten
to take advantage of Gecko Profiler internals. This reduced code
duplication, and enables us to take advantage of Gecko Profiler features
like JS stack interleaving. In addition, the ping submission logic has been
rewritten to perform less work on main thread, and submit hang information
outside of the main ping. This let us began collecting much more data,
including interleaved chrome-js/native stack frame information for all
hangs, and information about the browser's state, such as pending input
events. Platform support has also been expanded from win32 to include
linux64, win64 and macOS.

Doug Thayer has written a visualizer for the collected data called
hangs.html (https://arewesmoothyet.com), based on the perf.html profiler
viewer. This interface allows analysis of the change in frequency of
specific hangs over time, lots of tools for filtering through hang
information, as well as a profiler-like interface for drilling into
specific hang stacks to determine what might be causing the problems. Doug
is actively working on adding new features to the UI to improve filtering
and make it easier to get good results from the data, but we're already
finding and fixing important bugs. Some bugs which have been fixed include
bug 1393597 where we discovered that a synchronous GC on an edge case was
having more of a performance impact than we expected, and bug 1381465 where
we observed and prioritized the fixing of main thread I/O in the content
process.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Panos Astithas]

On Tue, Sep 19, 2017 at 7:20 PM, Andrew McCreight 
wrote:

> I've been using git for years now to develop Firefox, and I feel like it is
> a first class experience. There's a one time cost to setting up cinnabar,
> but after that, everything just works, including |mach try| and |mach
> mozreview|. It is still probably less setup than Mercurial users have to go
> through to install enough extensions to make hg usable. ;) Sure, there's a
> bit of "wacky custom machinery", but developers using hg also have to deal
> with some of that, so that's more of a Firefox developer problem than a git
> Firefox developer problem.


The experience with git-cinnabar has been pretty smooth for me, too. If we
could make the tool update process match the mercurial experience (mach
mercurial-setup -u), it would be great. I was planning to work on this, but
the long-term plans seemed unclear at the time:

https://bugzilla.mozilla.org/show_bug.cgi?id=1257478

Panos
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Jean-Yves Avenard]

On Tue, Sep 19, 2017 at 7:21 PM, Eric Rescorla  wrote:

> I've also had cinnabar fail badly at various times, and then it's been
> pretty unclear what
> the service level guarantees for that were.
>
>
time to try again maybe?

I use git with cinnabar on windows, linux and mac, and I haven't had any
issues with cinnabar in a long while.

I do copy my .git/config file whenever I'm switching machine because I can
never be bothered to learn the various URLs.

Whenever I ran into a (very rare) issue, :glandium was there to help

Thanks Mike!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform