On 12/5/22 9:26 AM, Chris H-C wrote:
Stepping in to first say: This is fantastic work, willkg!
Next: :asuth, do you think there'd be benefits to having similar
context-menu options for Glean metrics? Like on
`build_displaylist_time`[1] we could point to the Glean Dictionary
entry for it[2] and/or GLAM[3]?
Absolutely! In particular, both seem like places people would want to
go in a single click. It's probably also worth thinking about whether,
in the medium term, it's worth trying to bake any statistics or
trendlines into the searchfox HTML as an "inlay hint" to provide
immediate context to those reading the code. This could also include
accessible sparklines or other compact, static charts which might also
be integrated into any automatically generated control flow graphviz
diagrams[1].
A few questions:
- For a link like
https://glam.telemetry.mozilla.org/fog/probe/paint_build_displaylist_time/explore?aggType=avg¤tPage=1&ping_type=*
are the GET query arguments there something that will be correct across
all metric types? Would it better to drop the GET query args? I see
the GLEAN dictionary page uses
https://glam.telemetry.mozilla.org/fog/probe/paint_build_displaylist_time/explore?app_id=
- I see on the dictionary page
https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/metrics/paint_build_displaylist_time
that there is a link to the yaml definition point at
https://github.com/mozilla/gecko-dev/blob/ce78234f5e653a5d3916813ff990f053510227bc/gfx/metrics.yaml#L14.
Is there automation that already produces taskcluster artifacts that
searchfox could consume to be able to understand the metrics' yaml
config files, or that could be further instrumented to teach searchfox
things? Alternately, I have a plan in
https://bugzilla.mozilla.org/show_bug.cgi?id=1800016 to help searchfox
understand YAML (and potentially JSON) files via a combination of JSON
schemas and overlay heuristics, and maybe that would be a more
appropriate technique for processing the files. Arguably not all tooling
needs to be able to produce a full AST of its config files and it may
not be worth the extra effort if a schema or schema and a hacky custom
searchfox mapping can do it for free.
Andrew
1: In https://bugzilla.mozilla.org/show_bug.cgi?id=1773165#c2 I've been
thinking about showing some source excerpts in the control-flow
diagrams. Arguably a labeled sparkline-style diagram could be even more
useful in these cases. Probably the key thing for this would be that
for accessibility purposes we'd want to make sure we have some kind of
automated detection of notable discontinuities in the charts or other
alerts and that these are explicitly surfaced to searchfox so that in
the accessible dual of the graphviz diagram we could create a summary
table which could list all of the metrics and prioritize and indicate
those which have alerts with explanations. Such a table would be useful
to everyone, of course, I just want to make sure that anything I'm
proposing visually encoding has an alternate representation that's not
dependent on preattentive processing
(https://www.csc2.ncsu.edu/faculty/healey/PP/) or people having to
manually inspect the entirety of a results set to find the needle in the
haystack.
--
You received this message because you are subscribed to the Google Groups
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/bac173e9-39f1-f246-c6b5-8e2050a4befd%40asutherland.org.
