►
From YouTube: 2021-10-21 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).
A
This
is
my
first
metric
sig
in
quite
a
while.
We
still
use
the
regular
specification,
sig
doc
right.
B
Yeah
all
right,
let
me
let
me
get
off
sorry.
I
was
a
bit
late.
I
was
attending
a
cig
right
before
this.
I
don't
even
know
what
time
it
is
in
mountain
view,
right
now
or
pacific
time.
Sorry,
it's
eleven
days,
it's
effective.
First,
it's
11,
pacific,
okay
cool.
So
this
is
metrics.
B
So
I
know
that
riley
has
updated
the
actual
open,
telemetry
project
for
metrics
and
let's
go
through
status
of
those
and
where
things
stand
so
because
there's
a
bunch
of
in-progress
stuff,
sorry
for
being
late.
B
Okay,
I
was
just
explaining
to
everyone
that
you
weren't
here,
which
is
why
we
didn't
have
an
agenda
yet
and
that
I'm
leaving
in
30
minutes.
So
I
can't
run
the
meeting.
But
it's
good
you're
here,
because
I
don't
have
to.
C
C
We
we
don't
have
multiple
pr's,
open
and,
and
hopefully
we
can-
we
can
merge
them
as
soon
as
possible
because
after
we
merge
all
of
them,
I
think
we're
we're
ready
to
move
the
spec,
the
sdks
back
to
feature
freeze,
so
maybe
I'll
just
quickly
go
through
those
pr's.
Let
me
open
the
board.
We
have
sharing
my
screen
now.
Let
me
know
you
can
see
it.
C
Yes,
we
see
it
yeah,
so
what
I've
been
doing
is
I
look
at
the
spec
issues
every
day,
if
there's
any
matrix
ratio
I'll
I'll,
do
a
quick
trash
and
decide
if
this
is
something
that
we
must
do
in
the
initial
spike
stable
release,
or
this
is
something
that
can
be
an
additive
change
we
can
do
later
and
if
there's
something
I've
seen
it's
really
like,
like
there's
a
high
demand.
People
want
that
and
and
I'll
look
at
the
what
we
did
for
tracing.
C
C
I
think
we
probably
should
merge
some
of
the
prs,
given
we
already
discussed
it
several
times
and
got
consensus,
so
they
ask
is
for
everyone
here.
We
focus
on
the
in
progress
prs
and
issues
and
see
if
we
can
finish
them
all
and
for
the
specific
matrix
requests.
I
think
we
have
six
open,
so
I
won't
use
the
time
to
go
through
every
one
of
them
and
you
have
other
topic
we
can.
C
We
can
cover
that
after
we
finish
the
pr
part,
so,
first,
regarding
the
feature
matrix,
I
think
we
discussed
that
several
times
we
agreed
that
we
should
just
merge
it,
knowing
the
fact
that
it
might
be
missing
something
or
the
wording
should
change,
because
it
is
setting
a
foundation
and
we
can
always
improve
the
metrics.
Given
the
fact
it's
not
the
matrix,
but
it
is
the
actual
spec.
C
C
D
I
I
thought
we
were
going
to
remove
a
section
on
exemplars
and
I
know
diego's
on
the
call,
and
he
personally
would
rather
see
us
structure
our
spec
in
a
better
way
for
testability.
But
I
think
this
is
the
right
thing
to
do.
I
think
josh
s
was
the
one
who
had
all
the
issues
with
exemplar
section
and
I
wanted
it
to
be
removed.
B
I
think
that
was
all
related
to
like
shoulds,
where
there's
a
whole
bunch
of
things
that
were
shoulds
that
I'm
like.
Oh,
I
don't
want
to
hold
people
to
make
them
think
that
they
have
to
write
this.
So
if
we
take
the
approach
that
we're
gonna
merge
it
as
is
and
fix
it
in
place,
that's
okay!
I
can
also
instead
just
make
a
pr
against
diego's
pr
with
fixes
to
the
exemplar
bits.
If
that
is
easier,
it
doesn't
matter.
E
If
that's
possible,
I
will
actually
prefer
it.
There
was
a
bit
hard
for
me
to
understand
exactly
what
steps
to
follow,
since
some
people
wanted
to
go
in
some
directions:
some
another,
so
josh.
If
you
want
to
state
what
changes
you
want
in
a
different
pr
platform.
C
Okay,
so
here
goes
my
suggestion.
I
think
this
matrix
is
not
going
to
be
perfect
anyways,
because
there
are
other
pr's
when's
the
merge.
We
need
to
update
the
metrics
anyways
right.
We
accept
the
fact
that
this
matrix
is
just
trying
to
kick
off
the
effort,
and
this
is
not
the
source
of
truth.
The
source
of
truth
is
actual
spec
and
before
feature
freeze.
We
have
to
compare
the
metrics
with
the
actual
spec
to
make
sure
it's
accurate.
C
D
Agree:
it's
I'll
let
diego
and
josh
decide,
but
I'm
ready
to
merge
something.
If
anyone
wants
me
to
merge
it.
B
As
long
as
it's
clear
to
someone
who
looks
at
that
spec
again,
so
just
just
as
an
fyi
I'm
putting
together
a
road
map
for
open
telemetry,
because
this
is
a
common
complaint
from
users
is,
they
can't
tell
the
status
of
things
if
we
have
a
compliance
matrix
for
for
metrics,
and
it's
not
clearly
denoted
that
it's
not
ready.
Yet
that
that's
that's!
That's
just
I.
B
I
want
to
make
sure
that
that
we're
not
doing
and
and
repeating
that
right
like
we
have
this
documentation
status,
let's,
let's
throw
it
on
there
and
say
that
this
is
like
a
draft
or
like
in
progress
and
just
make
that
super
clear,
then
that
I
want
to
stop
sending
signals
to
users
of
status.
That
is
unclear
in
general
and
when
you
see
a
compliance
matrix
right
and
we
start
filling
out
check
marks
on
it
before
feature
freeze
is
done.
B
B
I
think
that's
an
important
signal,
we're
sending
so
I
I
understand
the
idea
of
wanting
to
like
iterate
on
this,
I'm
fine
iterating
in
diego's
branch.
I
find
iterating
on
the
spec,
but
if
we
do
it
in
the
spec
pr,
we
should
at
least
just
be
very
clear
with
the
disclaimer
of
which
components
are
around
metrics,
which
parts
are
not
totally
stable.
Yet
that's
all.
F
Yeah,
I
would
agree
with
that
sentiment.
I
think
in
many
ways
it
doesn't
seem
appropriate
to
be
merging
things
that
we
know
that
we're
going
to
be
removing
if
this
can
be
pared
down
to
be
the
absolute
minimum
that
we
are
sure
about.
I
think
that's
a
little
bit
easier
to
swallow,
but
I
also
agree
that,
like
maybe
a
disclaimer
should
be
added.
F
Well,
what
I'm
hearing
is
that
there
are
things
that
are
being
added
in
this
pr
that
are
debatable
whether
they
should
be
added,
and
I
think
that,
if
you
want
to
iterate
on
them,
I
would
recommend
just
taking
those
out.
It's
a
lot
easier
to
add
things
than
it
is
to
remove
things.
It's
not
impossible
to
remove
things,
but
I
would
say
that
if
you
can
just
put
in
what
you
know,
you
want
to
add
and
iterate
on
that.
F
I
think
that
you're
going
to
have
a
better
signal
going
to
the
end
users,
and
I
think
that
to
josh's
point
also,
you
know
saying
that
this
is
still
something
we're
working
on
to.
Readers
of.
That
is
a
good
idea.
I
don't
know
how
to
communicate
that
the
most
effectively,
but
I
agree
it
should
be
in
there.
C
D
E
B
C
B
B
I
mean,
I
know
it
enough
that
I
can
make
fixes
if
you
need
them,
but
don't
you'll
have
to
slip
me
something
fun
like
a
lot
of
whiskey.
D
B
I
so,
oh
I
I
talked
to
honorog
about
this
a
little
bit.
He.
He
can't
generally
attend
these
meetings
because
a
time
zone
in
java
they
actually
implemented
express
serializer
separately
and
they
wrote
codegen
that
just
synthesizes
constants
that
you
use
to
hand
write
serializers,
that's
actually
an
approach
we
could
take
in
the
collector
he's
exploring
that
right.
Now,
he's
also
way
faster
at
me
than
implementing
anything.
So
he'll
probably
succeed
before
I
do
just
as
an
fyi,
but
that's
that's
so
we're
taking
two
avenues
of
exploration.
D
C
Okay,
we
can
move
on
to
the
next
one,
so
I
sent
this
pr
is
triggered
by
the
prototype
from
donut
and
and
java.
So
the
idea
is,
we
want
the
exporter
to
give
the
indication
what
they
support
and
what
they
prefer
and
the
isdk
should
be
smart
enough
without
asking
the
user
to
explicitly
configure
something.
So,
for
example,
if
you
use
premises,
then
you
don't
have
to
specify
anything
and
by
default
you
won't
get
the
cumulative
metrics,
because
that's
the
only
one
supported
by
premises
and
and
based
on
the
feedback.
C
We
think
the
current
approach
would
work
and
I
I
think
we
got
a
good
number
of
approvals,
but
the
only
valid
approval
is
from
gmact,
the
other
two
wouldn't
count.
So
I
want
to
see
like
josh
surish.
If
you
have
any
blogging.
B
C
C
Okay,
there
are
two
pr's
related
to
the
same
thing
and-
and
it
happened
like
we
sent
the
pr
at
the
same
time,
but
they
were
basically
saying
that
when,
when
the
exporter
trying
to
export
matrix,
they
should
have
access
to
the
instrumentation
library
information
like
what's
the
meter
name
and
what's
the
version,
it's
just
freezed
differently.
C
So
in
this
pr
it
isn't
before
the
second
pr
in
this
pr,
the
suggestion
included
some
names.
For
example,
it
can
be
an
actual
dimension
on
the
matrix,
so
the
ask
is
to
add
it
as
attribute
and
and
even
the
name
is
specified.
So
I
block
the
pr
because
I
think,
having
a
generic
name
and
version
as
the
attribute.
C
It's
not
something
we
can
decide
right
now.
It
has
dependency
on
the
semantic
convention
and
number
two
I'm
worried
about
the
performance.
It
seems
adding
that,
like
as
dimension,
might
be
a
wrong
thing
for
some
scenario,
but
I
understand
like
we're
not
requiring
that
it
is
an
optional
thing,
so
I
blocked
the.
B
One
I
want
to
ask
a
question,
because
I
actually
don't
understand
this
request
at
all,
because
otlp
has
instrumentation
library,
which
is
the
meter
attributes
like
built
in.
So
you
get
your
meter
built
in
right.
Then
the
only
attributes
are
like
name
version,
schema,
url
and
those
come
directly
in
otlp
as
part
of
the
instrumentation
library
component.
So
if
you're
exporting
otlp,
you
have
them
today,
you
have
to
so
what
do?
What
does
it
mean
that
they're
not
exposed
like?
Is
this
more
about
prometheus,
getting
access
to
them
or
exporters.
C
This
is
for
all
the
exporters,
specifically
for
non-otlpx
callers,
I'll,
open
the
the
second
pr
and
this
links
to
the
original
ask.
C
I
think
armin
asked
that
the
instrumentation
library
name
and
version
be
available
to
non-otlp
exporters
and
I
think,
all
the
implementations
we
have
that
functionality.
So
when
people
travel
through
like
in
the
exporter
like
you
got
a
batch,
you
travel
through
the
points.
Then
you
see
which
item
is
coming
from
which
meter.
So
you
can
access
all
the
information.
It's
just
not.
E
C
C
And
I
didn't
specify
how
you
can
do
that,
so
it's
just
a
one-liner
thing:
well,
the
the
pr
listen
before
me
was
actually
suggesting
it
can
be
added
as
attributes
and
and
mention
specific
name.
So
I
think
I'm
I'm
a
little
bit
stuck
here.
I
want
to
see
like.
B
Your
pr,
if
it's
not
already
explicitly
specified
it,
should
be
because
implicitly
it
is
if
we
generate
otlp,
we
have
to
do
this,
like
exporters
need
access
to
it.
So
I'm
a
fan
of
explicitly
saying
it
if
it
hasn't
been
explicitly
said
anywhere
else.
There's
a
there's.
Another
question
around
feature
freeze
around
our
prometheus
exporter,
so
one
of
the
reasons
I
tried
to
put
together
that
draft
prometheus
exporter
pr
or
prometheus
data
model
mapping.
B
B
So
I
think,
if
your
pr
is
absolutely
the
first
one
that
needs
to
get
merged,
if
we
don't
explicitly
call
this
out,
but
then
the
second
one
is,
we
should
get
a
prometheus
export
spec
pr
of
when
what
to
do
with
resource
labels
and
instrumentation
library
labels,
like
that's,
that's,
not
specified
right
now.
I
don't
think
they
should
be
default
on,
and
I
have
a
few
open
bugs
asking
some
questions
around
that
like
when,
when
should
resource
labels
go
to
prometheus,
but
that,
I
think,
is
the
the
key
question
there.
B
D
D
So
we
could
recognize
those
names
if
you
try
to
enable
those
attributes
through
the
view
and
just
treat
them
as
special
those
those
attributes
map
to
the
instrumentation
library
named
version
they're,
not
instantiated
until
you
ask
for
them
in
a
view,
and
that
way
you
could
turn
them
on
for
a
prometheus
exporter
via
view.
That's
it.
C
I
I
agree.
I
have
a
question,
probably
just
my
curiosity,
I've
seen
in
premises
the
common
convention
is
people
use
underscore
instead
of
adult
for
the
name.
I
believe,
if
we're
going
to
do
this
across
the
exporters,
it
might
be
some
semantic
convention
called
instrumentation
library,
dot
name
or
like
adult
version
information
it
might
be
underscore.
C
G
As
far
as
I
remember,
there
was
a
discussion
about
this
on
on
github
about
like
including
a
naming
convention
yeah.
So
I
have
no
idea
what
was
the?
What
was
the
the
outcome
of
of
that?
I
believe
that
was
just
like
who
would
really
picked
it
up
eventually,.
C
Yeah,
my
guess
is:
if
it's
depending
on
some
semantic
convention,
then
we
probably
won't
figure
out
a
clear
answer
before.
D
You
could
have
this,
you
could
have
this
problem
other
ways
though.
So
it's
not
it's
not
unique
to
the
dots
question.
If
you
have,
if
you
aren't,
including
the
meter
name
in
the
exported
metric
in
prometheus,
then
you
could
have
two
different
libraries
producing
one:
a
underscore
b
and
one
a
dot
b,
and
we
would
have
this
question.
So
I
don't
really
know
that.
We've
said
what
to
do
and
I'm
not
sure,
there's
always
a
good
answer.
C
Yeah,
so
I
I
mean
in
favor
of
what
the
two
geologists
mentioned
like
we
focus
on
premises
just
for
now
and
for
the
others
we
can.
We
can
do
that
later.
It
doesn't
have
to
be
a
blogger
and
for
promises.
I
I
think
it's
straightforward.
You
just
say,
like
it's
library
underscore
something
we
just
put
the
name
and
be
done
with
that.
B
I
actually
think
the
generic,
let's
just
turn
all
dots
to
underscores
in
prometheus
and
if
someone
is
using
both
underscores
and
dots
in
open,
telemetry
and
exploring
the
prometheus,
we
consider
that
a
bug
I
think
that's
that's,
actually
totally
reasonable
to
do.
But
I'll
put
it
in
the
pr
and
see
what
people
say.
G
What,
if
like
open
telemetry,
would
say
that
hey
we
have
one
aiming
convention
which
is
like
I
don't
know
you
can
choose
one
separator
character,
let's
say
dots
and
open
elements.
You
will
know
what
dots
mean.
That's
the
word
separator
and
it
doesn't
matter.
What
is
the
format?
It
will
know
how
to
convert
that
auto
word
separator
to
the
word
separator
of
the
exporter.
It
can
be
underscore
in
case
of
prometheus.
It
can
be
whatever
else.
B
B
G
B
B
That
is
no
right,
like
we
don't
expect
any
open,
telemetry
instrumentation,
that's
following
a
schema
to
have
anything
but
dots
in
it,
which
is
why
I
think
this
is
going
to
be
totally
fine,
but
a
user
could
still
use
an
underscore
right.
B
H
B
B
B
Yes,
because
again
in
otlp,
it's
kind
of
baked
into
otlp
right,
like
all
those
things
are
always
propagated,
so
you
should
have
access
to
them.
So,
even
if
you
send
data
to
the
collector,
you
should
be
able
to
use
that
flag
and
that
same
flag
in
the
collector
to
get
prometheus
to
have
those
labels.
If
you're
using
the
collector
descent
right.
C
Okay,
cool
and
the
last
pr
is
per
ask
from
jack
from
from
new
relic.
I
think
we
got
we
got.
Three
approvals,
probably
is
ready
to
be
merged.
The
idea
is
very
similar
to
the
the
trace,
like
the
batch
span
processor,
where
we
have
the
environment
variable
to
control.
C
How
frequently
do
we
export
data
and
the
the
only
problem
I've
seen
is
the
naming
and
I'm
back
at
naming.
So
what
I
I'm
trying
to
do
is
I
try
to
follow
the
existing
batch
processor,
but
I
I
think
john
mentioned
like
he.
He
would
always
prefer
something
easier
and
straightforward
for
the
user,
and
I
I
see
the
point
so
I
want
to
get
more
feedback.
This
is
not
something
I
I
I
I'm
super
convinced.
I
think
they're
pros
and
cons.
So
I'm
struggling.
I
So
my
my
comment
here
is
specifically
built
on
the
fact
that
java
introduced
an
environment
variable
which
was
had
imr
instead
of
p-e-m-r,
and
now
we
have
to
get
rid
of
it
and
change
it.
So
clearly,
we
did
something
wrong
by
naming
it
after
the
class
name,
because.
I
I
So
maybe
we
could
have
like
hotel
periodic
export
interval,
but
I
think
having
the
like
the
acronym
in
there
is
a
well
a
confuse
people,
because
they
won't
know
what
it
means,
but
also
lead
to
a
similar
thing
that
happened
to
us
already
in
java
with
the
interval
metric
reader.
C
Yeah
so
personally
I
love
the
idea,
because,
if
I'm
putting
myself
in
the
user's
shoe,
I
clearly
see
like
I
can
understand
this,
and
I
have
no
idea
about
what
is
p-e-m-r
and
initially
I
was
trying
to
pick
the
periodic
exporting
reader.
Then
it's
per-
and
I
think
my
name
sucks
so
so
I
loved
it,
but
that
leaves
the
tracing
part
in
a
bad
state
and
it's
inconsistent.
C
A
What
if
we
went
with
what
john
watson
suggested
hotel
metric
export
interval,
and
then,
if
you
have
you
know,
we
can
define
more
specific
ones
where
it
uses
that
unless
you've
defined
like
the
pemr1
or
if
we
have
someone
in
the
future
like
a
different
one
specified,
we
could
have
a
more
specific
one.
That
overrides
that.
But
you
just
have
metric
export
interval
that
all
of
them
will
use
by
default
if
something
more
specific
isn't
set.
C
D
Who's
going
to
but
who's
going
to
configure
more
than
one
push-based
metrics
exporter
and
ask
for
different
environment
like
variables
anyway.
I
I
already
thought
like
the
fact
that
we
have
what
daniel
described
for
limits
on
attributes
like
there's
a
single
limit,
general
limit
and
then
a
specific
limit
is
awful
and
I
like
more
trouble
than
it's
worth,
and
so
I
wouldn't
do
it
again.
I
C
I
C
C
It
has
yes,
okay,
it's
unfortunately
stable-
and
I
think
bogdan
brought-
has
a
very
good
point.
He
mentioned
in
one
of
the
stack
meeting
that
we
keep
adding
things
to
marmot
variable
and
it's
becoming
a
place
with
too
many
things,
and
it
starts
to
become
very
confusing,
and
I
think
we
concluded
that
we
we
need
to
revisit
this
and
come
up
with
a
better
configuration
story.
C
So
maybe
we
don't
add
this
environment
variable
at
all.
We
just
like
finish
the
metric,
stable
release
and
knowing
the
fact
that
we
don't
have
a
variable,
and
then
we
work
with
the
the
higher
level
specific
to
sort
out
the
configuration
issue
and
come
back
again.
A
I
I
mean
we
could
put
the
experimental
qualifier
in
that
environment
variable,
which
is
at
least
in
java.
We've
done
that
a
lot,
and
I
thought
that
was
somewhere
in
the
spec
that
we
could
put
experimental
in
the
name
so
that
it's
clear
we're
still
trying
to
figure
out
what
it
is
going
to
be
long
term.
I
A
I.E,
one
more
argument
in
favor
of
using
the
the
metric
and
the
name
instead
of
pemr
is
that
I
feel
like
periodic
and
interval
are
kind
of
you
know
if,
if
not
synonyms,
they
at
least
imply
each
other
so
like.
If,
if
you
have
an
interval,
you're
implying
that
it's
periodically
exporting
so
periodic
doesn't
add
any
information
at
all.
C
C
C
G
Go
ahead
yeah,
so
I
just
wanted
to
ask
if
we
can
get
like
a
public,
serializers
or
martialers
for
otlp
in
case
you
want
to
implement,
like
a
converter,
from
something
to
otlp.
G
G
These
these
exist,
but
they
are,
they
are
also
public,
but
in
an
internal
package,
so
they
are
basically
like
subject
to
to
change
any
time.
G
Yes,
there
is
right
now
a
like
marshalling
api
in
the
in
the
exporters.
They
are
just
like
internal.
A
G
So
the
value
is
basically
making
the
people's
lives
easier.
If
you
have
just
like
one
like,
I
don't
know
component
where
you
just
feed
all
of
the
like
open,
telemetry
objects
and
you
spit
out
a
buy
stream
that
you
can
write
to
the
buyer.
I
G
I
think
they
can,
but
there
are
so.
D
D
It's
that
people
want
to
reuse
the
sdks
exporter,
they
wanna,
they
wanna,
say:
okay,
I
don't
have
instrumentation
for
open
telemetry,
but
I
I
have
metrics
and
I'd
like
to
send
an
open,
telemetry
endpoint
and
I
can
easily
convert
them.
But
can
you
just
do
the
rest
for
me
and
it's
remarkably
difficult
to
use,
say
the
hotel
go
sdk
as
a
sync
for
metrics
without
constructing
instruments,
and
it's
not
something
open
telemetry,
it's
not
really
in
scope,
but
it's
a
common
request,
because
we've
built
this
very
difficult.
D
A
G
D
This
also
is
how
the
hotel
go:
sdk
bridges
from
open
census,
but
the
input
is
not
a
protocol
object.
It.
You
have
to
input
your
data
in
exactly
the
format
that
the
otlp
that
the
hotel
sdk
the
intermediate
format
used
by
the
hotel
sdk,
which
is
not
necessarily
straightforward
either,
so
it
just
makes
it
hard
to
reuse
an
hotel
sdk
for
something
that's
not
an
hotel
application.
D
I
I
mean
in
the
java
specific
case
where
we've
placed
all
the
all
of
the
these
classes
in
the
internal
name
space
it's
specifically
because
we
don't
want
to
support
them
like
as
a
public
api
like
we
just
don't
want
to.
So
you
know
if
you,
if
you're
interested
in
like
taking
over
maintainership
of
those
packages
that
we
could
you
know
we
can
talk,
but
honorable
and
I
don't
want
to
support
those
as
a
public
api.
A
D
I
I
mean,
I
think,
if
someone
were
interested
in
in
pulling
that
code
out
and
like
having
a
separate
repository,
maybe
even
in
the
the
one
where
we're
publishing
protobufs
at
the
moment
and
be
the
maintainer
for
that
code
like
onorag,
and
I
would
love
to
give
up
work,
I
mean
that's
always
a
good
thing,
it's
less
stuff
that
we
have
to
maintain.
C
A
I
guess
that's
all,
since
that
was
the
last
thing
on
the
agenda.
I
do
have
a
quick
question:
there
used
to
be
in
the
old
metrics
specification,
this
concept
of
like
bound
instruments.
A
I
was
working
on
implementing
metrics
in
in
js,
and
I
saw
that
it's
not
in
the
specification
anymore,
or
at
least
I
couldn't
find
it
was
it
removed
intentionally,
or
am
I
just
not
finding
it.
C
While
we
understand
that
bone
instrument
is
important
for
some
high
performance
scenario
and
also
there
are
folks
expecting
some
transactional
behavior.
Although
it's
not
super
clear
like
what
level
of
transaction
they
need
at
this
moment,
so
we're
going
to
cover
this
right
after
the
matrix,
backstab
already
so
it'll
be
like
metrics,
like
1.2
or
like
2.0
or
whatever.
We
call
it
and
then
josh
and
I
already
started
a
milestone.
C
If
you
look
at
the
spec
milestone,
you
can
see
the
matrix,
we
call
it
v-necks
or
something
so
that
will
be
the
place
where
we
track
those
important
things
that
we
haven't
covered
in
the
initial
metric
specs
save
already.
I
don't
know
what
part
of
that
also.
There
are
like
the
the
base
tool,
exponential
buckets
and
many
things.
If
you
look
at
the
previous
matrix,
meaning
you
can
find
some
some
things
there.
I
believe
I'm
not
going
to
waste
everyone's
time.
So
I
I
can't
find
the
link
and
I'll
send
to
you
offline,
yeah,.
A
That
that's
fine,
I
mean
you
answered
the
question
sufficiently.
I
was
the
reason
I
asked
is
because
I
went
to
remove
it
from
the
js
implementation
and
somebody
asked
the
question:
is
this
specifically
removed
from
the
spec
or
was
it
an
oversight?
And
my
answer
was
if
it's
not
in
the
spec,
I'm
going
to
remove
it,
but
I
figured
I
may
as
well
ask
while
I'm
here.
D
D
We
ended
up
was
that
we
don't
think
people
should
actively
remove
it
when
they
think
people
care
in
their
language
and
it's
so
it's
on
the
chopping
block
for
go,
but
in
java
my
impression
is
that
it
may
matter
because
it's
more
established,
so
I
think
it
should
be
left
to
each
sdk
language
at
this
time,
and
I
expect
that
we'll
get
some
optional
option
in
the
future
and
that
point
you
can
still
not
have
it
in
javascript.
If
you
think
nobody
wants
it.
A
Yeah,
I
think
not
only
in
javascript.
Does
nobody
really
ask
for
it?
It's
it's
was
actively
confusing
to
a
lot
of
people
and
then
once
you
explain
what
it
is,
they
were
like.
Oh
yeah,
I
don't
care
about
that.
I
A
Performance,
sensitive
users
in
javascript.
A
Yeah,
how
bad
it
is
yeah
I
that
that
wasn't
what
I
was
doing.
It
wasn't
the
question.
No,
I
understand.
C
D
In
a
very
early
spec
of
the
hotel
metrics
api,
I
tried
to
create
something
called
label
set.
That
was,
that
was
like
a
pre-declared
set
of
labels
that
that
interf
interfered
with
bound
instruments.
So
you
could.
The
question
is:
if
you
have
a
batch
observation,
couldn't
I
just
make
my
my
instruments,
my
my
label
set
once
and
then
include
a
bunch
of
observations,
and
I
think
that
that's
actually
the
more
performance
relevant
concern,
at
least
in
go
so
find
myself
not
needing
the
bound
instrument.