►
From YouTube: 2021-07-19 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
All
right
I'll
take
that
as
no
metrics
any
updates
riley.
Maybe.
C
B
Okay,
vlogs!
No,
I
can't
let
me
just
pull
up
my
list
of
just
because
here
he's
not
okay,
php
bob.
B
Perfect
cool
java,
no
updates
today
any
updates
for
java
instrumentation.
D
B
B
B
Okay,
so
moving
on
to
topics
I
haven't
written
this
down,
but
I
was
wondering
probably
just
most
relevant
for
like
josh
and
riley
if
we
can
update
on
just
generally
where
we
are
of
metrics
in
the
sense
of
like
what's
what's
left
before
we
declare
the
metric
specification
is
ready
for
implementation.
C
A
C
Yeah,
we
want
to
specify
a
list
of
aggregations
that
we
should
provide
from
the
sdk
by
default.
For
example,
we
won't
be
able
to
have
the
min
max
and
also
like
histogram
and
and
some
last
value
those
things,
so
we
we
just
need
to
list
them
all
and
most
of
the
things
shouldn't
be
a
problem,
but
for
histogram
we
have
a
dependency
like
what
histogram
sketch
are
we
going
to
provide
across
all
the
languages
and
and
what's
the
algorithm?
What's
the
default
value?
C
Besides
this,
I
I
think,
there's
some
some
smaller
things
which
I'm
I'm
less
concerned
about,
for
example
the
the
built-in
big
spotters.
I
I
think
we
all
know
like
we'll
provide
four
exposures,
but
we
just
need
something
like
the
console
exporter
premium,
six
power
like
in-memory,
etc.
C
C
The
pipeline
probably
will
take
longer
time
and
most
likely
we're
going
to
step
back
and
say
instead
of
trying
to
be
ambitious,
we
try
to
have
a
very
scoped
like
version
for
now,
the
third
one,
and
it
has
some
external
dependency
like
we
will
have
to
work
more
with
the
metrics
as
first
I
know,
josh.
E
Hi,
I'm
sorry
I
haven't
been
coming
to
this
meeting,
but
I'm
going
to
try
to
now.
I
don't
have
much
to
add
to
what
riley
said.
I
think
there's
a
definitely
desire
to
see
if
we
can
get
default.
Behaviors
like
fast
tracked
and
and
sidestep
some
of
this
discussion
about
views
which
is
very
much
sort
of
adding
optional
customization.
E
I
think
this
would
be
an
appropriate
time.
Stop
me
if
I'm
wrong
morgan
to
talk
about
this
histogram
question.
Let's
do
it.
I
put
a
link
in
the
notes
here
to
issue
number
1776
in
the
spec
repo
this
issue
has
had.
I
I
posted
this
issue
hoping
to
get
outsiders
to
talk
about
the
questions
and
what
I
got
was
a
bunch
of
my
experts,
contributing
to
the
same
conversation
we've
had
someone
recommended.
E
I
come
here
and
post
this
more
widely,
essentially
saying
we
are
about
to
propose
building
a
standard
histogram
based
on
sort
of
this
data
format.
That's
been
discussed
and
there
are
last
minute
questions
about
hey.
Why
don't
we
use?
You
know
hdr
histogram?
Why
don't
we
use
open
histogram?
What
does
prometheus
want?
E
It's
all
in
this
thread
the
the
people
who
have
contributed
on
the
open,
telemetry
side
have
reached
a
conclusion:
there's
pretty
strong
consensus,
it's
actually
agreeing
with
prometheus,
but
it
doesn't
involve
using
open,
histogram
or
hdr
histogram
and
there's
still
a
lot
of
discussion
left.
It's
about.
You
know
how
do
you
decide
whether
to
do
fixed
precision
versus
automatic,
ranging
sort
of
this
discussion
about
whether
bucket
bucket
boundaries
are
automatic
versus
space
is
fixed?
Those
are
the
two
kinds
of
dimensions
that
get
discussed.
E
I
would
like
if
you
are
interested
and
want
to
see,
histograms
move
faster,
to
take
a
glance
at
this.
It's
mostly
asking
for
algorithms
to
be
implemented
that
we
could
actually
put
into
sdks
that
produce
a
format
that
we're
willing
to
process
in
the
collector,
and
I
think
this
dot.
This
dialogue
has
actually
been
driven
by
what
we're
willing
to
do
in
the
collector
and
in
the
vendors
downstream
from
these
histograms,
and
this
has
led
to
a
sort
of
simple
exponential
histogram
at
the
bottom
of
this
thread.
E
You'll
see
us
discussing
ways
of
implementing
it.
I
guess
I
guess
what
I'm
saying
is
speak
now,
because
we're
going
to
end
up
somewhere
with
a
histogram
implementation
and
it's
going
to
be
either
one
of
the
existing
solutions.
If
everyone
can
agree
to
it
or
it's
going
to
be
something
that
we
implement
new,
it
may
be
derived
from
vendor
code
like
we
have
dd
sketch
and
others
that
can
implement
an
exponential
histogram
already,
and
I
would
encourage
you
to
take
a
look
at
this
so
far.
E
B
Do
we
have
so
circling
back
on
this
then
josh
and
riley?
Do
we
have
like
it
sounds
riley
you
said
like
a
few
weeks
into
august?
Is
our
eta?
What
what?
C
B
Okay
and
the
sdk,
once
we
have
the
sdk
specification,
you
know
through
experimental-
let's
let's
say
it
just
gets
declared
ga
is
there
anything
else
that
we
have
missed
for
metrics
like
is
there
any?
Is
the
only
thing
remaining
the
sdk
specification
or
is
there?
Are
there
other
things
that
need
to
be
specified
after
that?
There.
E
There
are
also
a
few
like
really
fine
data
model
questions
that
experts
are
able
to
discuss,
but
I
almost
has
no
impact
on
apis
and
sdks.
It's
like
if
you,
if
you
know
what
a
gauge
histogram
is-
and
you
want
to
talk
about
it-
we're
still
doing
some
some
work
there
and
there's
sort
of
remaining
questions
about
whether
the
sum
of
a
histogram
is
meaningful
or
monotonic,
and
all
those
questions
are
really
fine
grained
and
don't
really
impact
the
specs.
E
B
E
I
think
if
you
are
a
maintainer
who
works
at
a
vendor
with
background
in
histograms,
I'm
looking
at
datadog,
especially
but
also
dynatrace,
and
you
understand
what
it
takes.
You've
already
got
some
implementations
of
a
client
library
that
does
histograms
you're
in
a
better
position
to
kind
of
push
the
the
sort
of
resources
that
you
have
to
provide.
E
These
implementations
for
open
telemetry,
so,
although
dynatrace
has
has
given
us
one
prototype
new
relics
working
on
a
prototype
but
but
we're
kind
of
trying
to
balance
sort
of
simplicity
of
the
code
with
our
performance
demands
and
still
get
to
a
standard
format.
And
you
know
the
number
of
options
being
discussed
is
not
that
great.
If
so,
if
you're
interested
in
this
this,
this
ticket
is
readable
to
you,
you
should
go
through
it.
B
F
G
Ghost
specifically
correct,
correct
yeah,
we
discussed
in
the
say
last
week
attempting
to
release
a
v22,
but
not
a
an
rc2
for
the
stable
components,
and
I
have
that
on
my
plate
this
week
to
to
work
through
whether
we
can
do
that
or
not
I'm
going
to
try
that
today.
If
I
can
awesome
thanks.
B
All
right
well,
thank
you,
folks.
Are
there
any
other
topics
for
today,
just
generally.
H
I
don't
have
access
to
that
calendar
again
and
sergey
didn't
understand
how
to
add.
Does
anybody
else
on
the
call
understand
how
to
add
people
to
have
access
to
that
calendar.
I
By
the
way,
I
would
say
that
this
is
especially
important
for
people
working
in
europe,
at
least
because
you
know
it's
very
common
in
europe
to
take
long
holidays.
So
please
don't
forget
to
to
add
yourself
to
that
and
put
their.
You
know
the
relevant
dates.
Please.
B
All
right,
actually,
I
have
the
access
list
open
right
now.
So,
oh,
yes,
tyler
you
lost
access
because
beside
your
new
relic
email
tyler,
what
email
do
you
want
to
tie
to
here?.