►
From YouTube: 2021-11-30 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
Hey
everybody,
I
think
we
can
start
in
one
minute.
Yes,
please
add
your
names
to
the
agenda,
please,
likewise
an
important
item.
You
see
a
few
items
there.
Well,
two
and
metrics.
A
B
Good
morning,
everyone
it's
been
a
few
weeks
since
I
showed
up
here
to
remind
us
that
we
have
this
fairly
large
and
complex
open
pr
with
the
results
of
an
otep
or
two
which
has
now
been
through
several
review
rounds
from
qualified
people.
At
this
point,
I'm
I
think
we
have
enough
momentum
to
to
consider
getting
to
merge
this,
but
we
need
a
few
more
approvals.
B
I
know
that
this
is
a
complex
subject
and
it's
difficult
for
casual
readers
to
come
through
and
approve.
I
don't
know
what
to
do
about
that.
The
latest
proposal
that
I
have
is
that
we
should
stop
trying
to
extend
the
current
pr
merge
it.
It
is
marked
experimental,
and
this
way
we
can
at
least
have
another
pr
to
to
complete
some
of
the
work.
There
was
one
point
raised
in
the
most
recent
round,
which
has
to
do
with
recommendations
for
producers
and
consumers,
basically
trying
to
explain.
B
There
are
a
few
ways
that
you
can
use
this
incorrectly
and
if
you
do
this
is
what
will
happen.
That
type
of
language
is
something
we
could
continue
to
refine
forever.
I
think,
but
I
don't
think
we
should
so
if
you
have
anywhere
near
the
inclination
to
review
this,
I
would
like
your
help
and
an
approval,
and
if
you
get
down
to
the
bottom,
you'll
find
the
the
latest
topic
is
is
what
type
of
validation
we
should
do
under
certain
circumstances
for
the
legacy
parent
based
sampler,
we're
really
down
into
the
details.
B
A
Sounds
like
we
are
fine,
so
let's
discuss
details
in
the
pr
itself.
Thank
you.
John
watson,
service.
C
Yeah,
I
don't
know
it'd
be
good
if,
if
maybe,
if
carlos,
you
could
bring
up
this
particular
issue
or
pr
in
the
spec.
C
Finally,
so
I
don't
know
exactly
exactly
how
long
ago,
but
several
months
ago
there
was
this
pr
put
in
to
define
in
the
glossary
what
a
service
is,
I
guess
only
22
days
ago,
so
not
not
so
long
ago,
but
this
was
put
in
at
the
same
time
that
the
client
side,
telemetry
say,
was
starting
to
ramp
up
and
really
start
talking
about
what
it
means
to
be
a
client
what
it
means
to
be
or
how
back
ends
are
going
to
be
able
to
distinguish
between
client
generated
telemetry
from
the
rest
of
the
telemetry.
C
Since
client
telemetry
looks
it
looks
very
different.
It
has
very
different
shapes,
very
different
signals
than
back
end.
Telemetry
does,
and
this
popped
up
basically
declaring
that
everything
that
is
software
as
a
service
and
the
client
group
disagrees
quite
strongly
with
this
sentiment,
that
a
web
app
is
a
service
or
that
a
mobile
app
is
a
service
or
that
a
iot
device
that
is
emitting
telemetry
is
a
service.
C
These
things,
in
our
opinion,
are
not
services,
their
apps
or
they
their
iot
devices,
they're
they're
different
in
kind,
and
they
generate
a
different
kind
of
telemetry
than
services
do,
and
so
we
do
not
think
that
services
should
be
everything.
C
That
is
essentially
the
the
basis
of
the
disagreement
here
that
it
feels
like
the
several
of
the
people
yuri,
especially
in
this
pr
is
pushing
service,
because
service
is
kind
of
already
there,
not
because
it's
the
right
thing
for
this
telemetry,
and
so
we
in
the
client
group.
We
really
don't
want
to
use
the
service
name
space
for
apps.
C
We
don't
think
it
makes
sense.
We
think
we
would
end
up
coercing
a
whole
bunch
of
stuff
into
the
service.
Name
says
that
is
app
the
client-side
specific
that
would
confuse
a
lot
of
people
and
that
application
developers
are
not
going
to
understand
that
they
should
call
their
thing
a
service
when
it's
not
a
service.
So
that's
kind
of
where
the
instrument.
C
There's
an
idea,
there's
already
a
pr
open
for
it
to
define
the
client
name
space.
I
don't
remember
exactly
where
it
is.
I
didn't
open
it.
I
just
been
I'm
just
here
more
as
a
spokesperson,
but
there
is
already
another
pr
in
the
spec
to
define
and
in
the
the
website
docs
to
define
what
a
client
is
and
how
it
is
different
than
a
service.
I.
E
A
Interesting,
so
does
that
mean
that,
for
example,
resource
attributes
such
as
service
id?
Likewise,
they
won't
be
used
for
some
kind
of
applications
by
the
way
for
for
web
apps
and
mobile
apps.
C
D
I
guess
the
fundamental
sort
of
meta
question
here
is
is-
and
I
tend
to
agree
with
john's
solution-
is,
should
for
any
given
piece
of
software
regardless?
If
it's
a
back-end
service,
that's
being
monitored
or
observed,
or
a
client
application
or
an
iot
application,
are
we
going
to
say
that
everything
is
a
service
and
we're
going
to
jam
everything
into
the
service
definition,
or
are
we
going
to
define,
have
separate
definitions?
D
G
G
It
there's
until
now,
only
to
say
like
hey,
service
name
is
mandatory,
but
but
this
back
is
not
speaking
about
what
is
a
service
technically,
and
so
I
found
it
important
to
to
have
a
definition
of
a
service
and-
and
apparently
this,
this
opened
up
this
box.
That
yeah,
not
not,
everything,
is
maybe
a
service,
and
I
I
also
told
already
like
I
I
can
live
with
with
both
solutions,
but
I
think
the
having
that
clarity
is.
This
is
the
important
part.
G
Nevertheless,
the
the
reason
why
I
also
think
that,
having
something
like
services,
some
some
kind
of
thing-
that
uniquely
identifies
everything-
and
I
said
it-
it
does
not
have
to
be
service-
is
at
least
helpful
to
you.
Yeah
say
like
hey
this:
is
this?
Isn't
this
thing
here,
and
this
has
this
in
this
name
and
id
and
and
then
I
can
find
it
easily
to
I
don't
know
I
say
in
in
some
searches
or
even
in
an
admin
context
where
I
say
like
hey.
G
What
was
this
thing
exactly
and
I
don't
have
to
think
about?
Is
it
a
service?
Is
it
the
device?
Is
it
the
app
or
what
that
whatever?
But
but
this
could,
of
course,
live
also
in
something,
like
the,
I
think,
there's
this
telemetry
sdk
space,
where
it
also
could
have
some
some
kind
of
unique
identifier.
C
I
think
one
thing
that's
important
to
note
independent
of
whether
our
users
will
be
confused,
which
I
do
think
is
very,
very
important.
I
think
we
need
to
make
sure
we
think
about
the
users
of
our
of
our
specification,
not
just
the
implementers,
but
the
back
end,
the
owners
of
back-end
services
that
need
to
process
and
route
telemetry.
We
need
to
be
able
to
distinguish
between
these
types
of
telemetry
some
way
somehow,
and
our
proposal
is
to
use
the
client
existence
of
the
client
namespace
versus
the
or
is
it
app
name
space?
H
I
agree
with
john
in
microsoft:
we've
seen
like
on
client.
Normally,
the
telemetry
is
owned
by
the
end
user
and
they
have
to
agree
before
we
can
collect
any
telemetry
and
on
the
service
side,
normally
we
collect
kilometers
by
default.
But
we
split
that
according
to
whether
the
data
is
is
owned
by
the
customer
or
is
owned
by
microsoft
and
and
there
are
additional
things
you
might
consider
regarding
the
gdpr
and
the
eodb-
and
there
are
more
regulations
coming
so
having
a
clear
separation
between
clients.
So
is
important.
G
H
Of
no
the
course
there's
a
classification,
so
the
the
telemetry
from
the
service
has
many
different
classifications.
It
can
be
the
end
user
identifiable
information
eoi
or
it
can
be
owned
by
the
customer
that
if
the
customer
is
from
eu,
you
have
to
roll
the
data
to
you.
It's
just
different
classification,
but
having
having
a
top
layer
concept
trying
to
distinguish
whether
it's
client
and
service
is
important
because
on
clients
you
you
don't
own
any
telemetry,
it's
entirely
owned
by
the
customer,
because
you're
running
on
the
customer's
device.
G
That
makes
sense
yeah
where
you
say
like
okay.
Here
I
I
have
to
ask
for
any
kind
of
consent
and
on
the
server
side
there
I
have
to
to
look
into
the
details.
Yeah
that
makes
sense
from
from
that
perspective,.
E
Body
for
the
original
pr,
the
issue
is
like
calling
it
like
some
other
way
right
and
also
having
a
having
another
like
label
that
we
can
use
in
order
to
identify
these
groups
of
applications
right.
C
G
But
should
there
also
be
some
some
other
attribute
that
says
like
okay?
This
is
type
app.
This
is
type
service,
or
is
this
then
the
top
of
the
the
collector
or
the
back
end
to
to
check
for
haste
or
something
from
services
to
something
from
app
or
go
go
through
the
list
of
potential
attributes.
I
J
Is
that
correct?
I
I
thought
that
that
was
a
an
absolutely
required
resource.
L
The
last
time
I
checked
well
so
the
spec
says
that
it
is
required
to
be
to
be
there
in
the
end,
but
if
the
user
does
not
provide
it,
then
the
respective
sdk
has
to
provide
a
good
estimate,
and
I
think
that
might
be
something
like
unknown
service
colon
java
or
something
like
that.
So
there
is
a
statement
in
respect
saying
that
this
this
particular
resource
attribute
has
a
default
value,
unlike
all
others,.
G
So
if
I
understand
it
correctly,
then
there
are
multiple
things,
so
I
mean
I
started
with
this
pr.
That
said,
like
hey,
let's,
let's
add
a
definition
for
a
service
and
and
if
we
all
agree
that
that
not
everything
is
a
service,
then
the
definition
of
a
service
needs
to
cover
only
back-end
applications
or
whatever
is
in
in
the
space
and
then
service
name.
Also,
the
question
is:
is
this
then
also
in
the
future
a
required
attribute,
or
should
this
then
be
something?
L
So
I
think
now
we
have
the
guarantee
that
the
attribute
will
always
be
provided
and
so
for
consumers.
It
will
would
for
sure,
be
a
breaking
change.
I
wonder
if,
if
in
in
the
case
of
something
that
does
not
qualify
as
a
service,
if
just
leaving
the
unknown
service
in
there,
if,
if
that's
something
that
we
we
want
to
have,
but
that's
something
that
could
work.
M
This
might
be
a
little
bit
far
fetched,
but
there
is
an
otep
open.
I
think
it's
187
about
the
about
attribute
classifications.
I
think
that
is,
and
so
so.
M
As
far
as
I
understand
the
the
sort
of
the
the
app
name
and
the
service
name
and
those
are
sort
of
similar
concept
right
concepts
right,
so
they
they
sort
of
describe
a
similar
thing,
but
it's
like
basically
the
the
the
entity
that
emits
the
the
or
the
telemetry
data,
and
I
wonder
if,
if
like
something
like
this
classification
here
would
provide
a
way
for
us
to
sort
of
say:
okay,
listen.
This
is
classified
as
this
is
a.
I
don't
know
some
name,
that
is,
that
defines
the
origin
of
the
data
right.
M
This
is
again
like
rather
far-fetched,
but
this
just
came
to
my
mind
like
we
would.
We
would
then
sort
of
tag,
the
service
name
as
origin,
and
we
will
tag
the
app
name
as
origin
or
attack
whatever
it
is
as
origin,
and
then
that
would
sort
of
allow
backends
to
say.
Okay,
this
is
we.
We
want
to
use
it
as
a
service
name.
So
if
it,
if
it
comes
in
as
app
name
and
it's
it's
marked
as
this,
then
we
could
use
it
as
service
name.
M
L
C
N
I
remember
that
I
remember
the
discussions
at
the
time
was
like
we
want
to
have
a
name
that
we
can
refer
to
things
and
we
we
want
users
to
have
something,
and
we
there
was
discussions
around
application
versus
service.
N
It's
just
the
rum
slash
application
folk
were
not
quite
as
strong
in
the
specification
at
the
time,
so
the
decision
then
was
to
consolidate
on
service
and
say,
like
you
know,
even
though
service
doesn't
really
fit
we're
just
gonna
make
everyone
have
a
thing
called
service
name,
so
we
specified
service,
name
and
said
this.
This
will
be
the
one
thing
that
doesn't
change
and
it
just
means
the
name.
The
user
gave
this
thing
and
it's
a
way
to
tie
it
together.
N
Yeah.
I
remember
when
that
happened,
that
was
kind
of
the
discussion
and
the
shape
of
it.
I
don't
know
if
that
changes
anything
now
like
we
can.
We
can
reevaluate
that
decision,
but
that's
what
the
decision
was
and
that's.
Why
is
if
we
don't
have
something
specified
where
people
have
to
have
service
name,
we'll,
never
have
a
name
for
these
things,
and
it
doesn't
matter
if
it's
service
name
or
unique
name
or
whatever,
but
it's
some
sort
of
name
to
tie.
J
There's
also
that
jaeger
will
reject
spams
that
don't
have
a
service
name
attribute.
I
know
we
can
specify
that
that
a
jager
exporter
has
to
deal
with.
You
know
app
name
or
browser
name
and
convert
its
server's
name
or
something
like
that,
but
that's
still
going
to
end
up
that
as
a
different
value
in
the
downstream
system.
J
C
O
So
john
one
question:
is
you
just
use
the
term
software
like?
Is
there
a
more
universal
term,
because
we
do
have
semantic
conventions
versioned
with
a
schema
in
place
that
should
help
translations?
I
don't
know
if
that's
a
just
an
idea.
C
Well,
I
mean,
I
think
it's
not
even
software,
because
some
of
the
stuff
can
be
generated
by
hardware
right.
We
can
have
hardware
based
telemetry,
that's
not
really.
Software
related
at
all,
so
it's
kind
of
like
telemetry
source
is
really
what
we're
talking
about
here.
It
could
be
anything
that
generates
telemetry
software
firmware
hardware.
C
Don't
have
a
good
handle
on,
I
think.
Well,
josh
zarth
knows
all
about
how
to
deal
with
resources
and
the
schema
and
evolution
right
josh.
You
got
that
all
solved.
N
Sure
I
have
proposals
that
people
disagree
with,
but
yeah.
I
I
do
think
I
think
getting
this
right
is
is
critical
and
I
think
the
spirit
behind
service
name
is
is
accurate
and
I
think
the
name
is
hella
confusing
to
everyone.
I
think
all
of
those
things
are
equally
true,
and
I
agree
with
john
that,
like
it's
going
to
involve
a
lot
of
coaching
to
explain
to
people
why
they
need
to
use
service
name
instead
of
application,
name
and
we'll
be
like
well.
N
Applications
are
a
surface
and
that's
only
going
to
go
so
far.
Right,
yeah,
it's
similar
to
like
having
to
describe
up
down
counter
to
everybody
right,
that's
the
same
battle
that
we're
fighting
in
open,
telemetry
and
there's.
There's
a
question
in
my
mind
of:
is
that
worth
the
social
cost?
Because
it's?
N
I
think
that
technical
value
is
high
of
having
this
name,
that
we
require
people
to
have
and
making
sure
it's
consistent
when
it
comes
to
resource
and
evolution,
though
these
kinds
of
things
we
have
technical
things
we
can
solve,
where
we
can
move
resources
around
easily,
there's
solutions
to
it.
But
it's
there's
a
high
technical
cost
for
the
social
cause
like
it's
a
small
social
win,
high
technical
cost.
N
If
we
do
this
later,
is
what
I'm
saying
if
we
change
things
later
so
when
it
comes
to
resource
semantic
conventions,
anytime,
we
make
a
change
there.
We
need
to
be
very,
very,
very
careful.
I
guess
is
all
I'm
saying,
because
changes
to
it
are
really
really
expensive
and
if
you
want
like
evidence
of
why,
as
john
mentioned,
I
have
an
otep
on
what
some
notions
of
the
expense
of
changing
resources
but
effectively
it.
This
breaks
our
ability
to
correlate
telemetry.
A
Well
to
me
I
don't
know,
but
it
sounds
like
more
people
need
to
to
think
about
these
and
probably
more
people
especially
well.
I
don't
know
josh
joshua,
I
mean
whether
you
are
coming
to
the
to
the
client
meetings,
but
I
think
it's
probably
a
good
idea.
I
will
try
to
go
to
the
next
one.
We
can
discuss
it
more
there.
It
seems
that
an
important
one
and
we'll
try
to
focus
young
as
well,
who
might
have
an
opinion
about
this.
H
I
have
a
stepping
back
question,
so
do
we
think
those
like
name
like
key
value
pairs
in
the
resource
is
very
similar
to
semantic
convention?
So
all
the
problems
we're
facing
here
is
essentially
the
same
as
semantic
condition
like
how
do
we
name
something
and
how
do
we
communicate
that
make
sure
it's
consistent?
J
I
think
it
should
be
and
there
are
resource
semantic
conventions.
I
think
service
name
is
kind
of
the
one
three
generous
attribute
that
is
called
out,
as
must
be
provided
by
the
sdk
cannot
be
missing,
must
have
some
default
value
of
this
form.
Everything
else
is
symmetric
conventions
that
have
their
own
sort
of
requirements.
J
I
think
some
are
required
if
others
are
present,
for
instance,
by
the
terms
of
the
semantic
conventions,
but
none
of
them
are
specified
in
the
main
spec,
and
none
of
them
are,
in
a
part,
that's
stable,
which
is
the
complication
we
face
here.
H
Yeah
I
understand
my
gut
feeling
is
like
if
we
have
some
conversation
like
this,
like:
what's
the
name
for
the
resource
and
what's
the
meaning,
maybe
we
should
make
sure
the
the
people
who
are
heavily
involved
in
the
semantic
convention
are
also
contributing
at
least
have
visibility
here.
I
I
think
a
bad
outcome
would
be
in
the
resource.
We
have
something
that
looks
like
something
trying
to
clarify:
what
is
the
device?
What
is
a
service
and
the
instrumented
convention?
We
have
the
same
thing
and
they
conflict
with
each
other.
D
N
I
guess
I
am
now
so
yeah
I
mean
just
in
all
frankness:
we've
been
holding
off
on
really
folk.
I've
been
holding
off
on
focusing
on
resource
semantic
conventions,
specifically
to
make
sure
metrics
get
shored
up
and
launched.
So
that's
why
you
know
we
made
a
few
oteps
and
just
put
them
put
them
down
for
a
little
while
to
show
up
metrics
now
that
metrics
is
getting
closer
to
stable
and
there's
less
there.
My
plan
was
to
pick
that
up
and
just
drive
through
some
of
these
issues.
N
Personally
and
there's
been
a
lot
of
good
work
from
a
lot
of
people
that
I
need
to
get
caught
up
on,
so
I
can
take
ownership
of
trying
to
make
sure
progress
gets
driven
here.
I
just
need
I
need
to
start
attending
some
new
meetings
and
and
get
caught
up
with
where
people
stand
on
semantic
conventions
with
resources
today,
because
I
I've
been
out
of
touch
with
a
bit
of
the
specifically
the
client
instrumentation's
sake,
but
a
few
of
the
other
instrumentation
sigs.
A
Yeah,
I
will
be
joining,
I
would.
I
will
be
trying
to
bring
the
young,
but
if
you
know
any
using
anybody
that
may
know
better
or
more,
please
invite
that
person.
I
feel
like
you,
ted
and
josh
are
already
a
good
crew.
A
Perfect.
Okay,
I
think
that's
it
for
today,
there's
metrics.
A
H
Okay,
so
so
this
is
the
the
project
board
and
I
think
so
far,
there's
some
some
like
issue
on
the
exemplar
part.
It
requires
for
the
clarification
and,
if
you
look
across
all
the
issues
that
we're
working
on
to
get
the
matrix,
spec
too
stable,
I
I
I
think
the
only
thing
that
seems
a
little
bit
suspicious
is
how
we
can
correlate
matrix
with
traces.
It
includes
how
we
can
enrich
metrics
using
key
value
pairs
from
the
context
baggage
and
how
we
can
implement
exemplar.
H
H
We
mark
it
as
a
feature
freeze
for
now
and
we'll
will
improve
that
later
on,
and
the
only
section
that
is
not
stable
will
be
anything
that
relates
to
the
correlation
between
traces
and
metrics,
and
I
hope
we
can
use
the
december
time
to
hammer
those
out
so
far.
There's
a
there's,
a
good
there's,
a
good
momentum,
and
I
I
think
if
we
spend
more
energy
there,
we
should
be
able
to
get
the
entire
sdks
back
to
stable
by
end
of
december.
H
But
I
hope,
given
the
spec
is
going
to
have
another
release
next
week
and
I'll
be
gone
for
december,
I'm
taking
vacation
for
the
entire
month.
I
I
want
to
see
the
the
spike
making
progress
at
at
least
making
some
steps
further
before
I'm
gone,
and
in
addition,
while
marking
the
the
metric
provider
like
the
military
provider
metric
reader
and
exporter,
part
as
stable,
that
allows
us
to
mark
the
exporters
as
stable,
except
for
premises
for
premises.
H
I
have
a
ongoing
pr,
which
I
I
will
clean
up
and
that
should
give
us
a
good
confidence
to
mark
the
the
spec,
the
permissive
exporter
as
feature
freeze.
So
these
are
the
the
top
asks.
So
please
take
a
look
at
the
the
pr
here
mark.
The
metrics
at
cks
makes
the
stable
and
and
see
if
any,
blocking
issue,
and
please
be
explicit
if,
if
you
have
been
part
of
the
matrix
prototype
or
the
metrics
work
stream,
I
I
need
your
help
to
call
either
by
working
on
a
particular
language
implementation.
H
You
have
a
good
confidence
that
the
sections
we
called
as
stable
is
good
enough
for
you
and,
if
you
don't
think
so,
I
need
your
help
to
count
explicitly,
which
part
is
blocked
and
bear
in
mind
that
some
of
the
clarification
is
not
going
to
block
the
spec
release
like
some,
sometimes
people
from
the
type
hall
or
they
want
a
small
wording
improvement.
That's
totally
fine,
I'm
I'm
not
a
native
english
speaker,
so
we
try.
We
try
our
best.
I
know
many
folks,
including
john
joshua.
H
They
helped
me
to
correct
my
english,
but
bear
in
mind
those
things
are
not
going
to
block
the
stabilities.
So
what
we
track
here
is
things
are
required
for,
for
ga
are
the
things
that
we
believe
will
have
to
be
resolved
before
we
can
mark
the
entire
spec
as
stable.
Some
items
like
the
like
the
baggage
handling.
If
we
only
mark
the
sdk
spec
as
mixed
status,
by
calling
out
this
section
as
a
feature
phrase
or
not
stable,
that's
totally
fine
and
anything
that
is
marked
as
allowed
for
ga
means
it's
some
nice
improvement.
H
We
can't
have,
but
it's
not
going
to
block
the
vr
so
so.
Based
on
this,
I
have
two
prs
that
I
I
need
your
help
to
take
a
look.
You
can
find
the
link
from
the
from
this
bag.
H
That
are
all,
and
and
after
after
the
spike
like
the
sdks
like
pr
got
merged,
I
need
your
help
to
look
at
the
exporter
pr.
You
can
also
find
the
link.
The
only
caveat
here
is,
after
we
mark
the
thing
as
stable.
H
H
So
please
comment:
if
you
think
we
should
make
this
part
as
feature
freeze
instead
of
stable
because
feature
freeze
later.
If
we
decided,
we
want
to
change
that,
we
can
still
make
breaking
changes
or
we
can
even
remove
that.
So
that's
the
only
thing
to
keep
in
mind
and
and
if
folks
agree,
we
should
make
this
stable
after
this
pr
got
merged
I'll
move
this
section
to
the
right
place.
H
Currently
I
kept
it
here
because
the
protocol
exporter
spec
is
stable,
so
this
thing
for
now
is
not
stable,
but
after
it's
stable,
I'll
I'll
be
able
to
move
it.
H
H
I
I
hope
we
can
make
progress
in
december
and
I
have
an
exemplar
prototyping.net,
which
gives
me
a
good
confidence
of
reasonable
performance,
and
so
I
I
actually
agree
with
josh
surish
that
if
you
think
long
term,
the
college
between
matrix
and
traces
is
a
killing
feature
for
open,
telemetry
and-
and
maybe
we
should
have
that
enabled
by
default.
H
So
I
try
to
do
my
best
to
support
him
I'll,
send
the
donut
prototype
vr
today
and
and
if
you
need
any
help
on
the
exemplar,
I
I
think
josh
surish
will
be
like
helping
while
I'm
away
and
another
important
thing
is
for
metrics
even
after
the
spike
is
stable.
We're
not
done
yet.
There
are
a
lot
of
things
that
we
should
discuss
after
stable,
like
the
the
base
two
exponential
histogram,
which
is
a
very,
very
efficient
way
of
handling
a
height.
H
Like
a
wide
dynamic
range
by
eating
a
very
low
cost
and
also
their
their
bond
api,
which
gives
like,
like
super
performance,
those
have
been
prototyped
in
gold
and
java.
So
my
suggestion
is
treat
this
as
the
the
second
priority
after
we
finished
the
exemplar
and
the
baggage
contacting
so.
H
E
Right
riley
just
a
quick
follow-up
question.
So
will
the
prometeus
exporter
block
the
sdk
being
stable
or
not?
No,.
H
So
so
the
sequence
should
be.
We
need
to
get
the
ick
spike
too
stable,
or
at
least
the
major
part
of
the
ic
case
back
to
stable,
including
the
the
matrix
exporter
which
is
critical
and
once
that
is
stable,
we
can
mark
the
in-memory
otlp
and
the
the
standard
output
or
the
console
exporter
spectac
stable,
because
they're
they're
quite
straightforward,
like
the
otlpxport,
basically
points
to
the
the
protocol
file
and
the
data
model
and
the
premises
part
has
some
additional
thing.
H
We
we
need
to
spend
time,
so
we
have
good
prototype,
but
they're
they're
questioning
about
how
do
we
handle
the
the
naming,
because
in
open
telemetry
we
have
different
layers
like
if
you
have
two
meters,
they
have
the
same
instrument
and
the
user
didn't
specify
additional
rename.
B
Cool
thanks
question
riley,
so
the
go
implementation,
as
it's
been
noted
in
the
pr
2150,
is
not
complete
and
it
sounds
like
there's
some
pressure
right
now
to
approve
stuff
and
get
it
done,
but
I
don't
think
we're
done
at
least
not
in
the
sdk
that
I'm
most
familiar
with.
So
I
haven't
been
approving
things
which
I
think
are
calling
something
stable
that
we
haven't
implemented.
But
I
wonder
if
we
could
all
agree
that
feature.
Freeze
is
a
acceptable
middle
ground,
because
we
all
have
reviewed
this.
B
We
don't
expect
to
change
it,
but
the
only
reason
we're
going
to
change
it
is
if
the
spec
is
actually
broken,
and
we
just
don't
know
it
yet,
in
which
case
that's
what
feature
freeze
is
for
so
I
feel
like
we
should
end
it
at
feature.
Freeze
right
now,
until
there
are
more
sdks
implemented-
and
that's
that's
just
a
question
for
you
riley.
What
do
you
think
we
should
do.
H
Yeah,
I
I
think
the
problem
with
feature
freeze
is:
it
indicates
we're
not
going
to
add
any
new
feature.
It's
it's
trying
to
scope
down,
but
it
they
don't
see
anything
about.
Are
we
going
to
remove
a
feature
completely
from
the
the
spike
by
making
certain
things
stable?
We
give
people
better
confidence
and-
and
it's
also
important-
because
I
I
I
I
want
to
have
this
as
a
forcing
function-
to
see
how
much
confidence
we
have
like.
If
we
think
the
exporter
part
is
not
stable,
it's
totally
fine
but
which
part
is
stable.
H
B
I
I
see
your
point
so
in
my
case
the
the
go
repository
has
a
fairly
stable
sdk,
but
it's
lacking
views,
which
is
a
pretty
huge
part
of
our
spec
and
it's
lacking
his
empires,
which
is
a
question
mark
right
now.
So
I
am
feeling
fairly
confident
that
we
can
do
the
rest
of
those
pieces.
But
until
we
do,
I,
wouldn't
I
wouldn't
say
that
it's
it's
perfect
or
that
we're
done.
You
know
what
I
mean
yeah.
It.
H
Yeah,
so
it
I
I
hear
you
so
if
we
think
the
the
view
part
and
the
example
part,
is
it's
not
like
good
enough
or
we
don't
have
enough
confidence
from
a
particular
language
shape.
I
I
need
your
help
to
code
explicitly
so,
for
example,
if
you
think
the
exposure
part
so
far
as
you
tried
everything
works
fine,
then
we
should
mark
the
exporter
as
stable.
B
I
see
I'm
going
to
have
a
meeting
to
talk
about
the
details
with
one
of
my
colleagues
today
at
least
we'll
work
on
the
hotel
go
picture,
but
if
it
were
up
to
me
today
I
would
say
that
views
can
be
continued
to
be
experimental
and
exemplars
can
be
continued
to
be
experimental,
but
the
rest
of
it.
I'm
ready
to
call
stable
okay,
just
because.
H
Yeah,
by
the
way,
I
I
I
might
confuse
folks
so
so
I
I
need
to
make
sure
like
the
pr
is
marking
since
as
stable
as
much
as
we
could.
Given.
We
have
a
reasonable
confidence
and
for
the
rest
of
the
things
they
will
be
marked
as
feature
freeze,
not
experimental,
because
the
spec
is
already
feature
freeze,
so
the
end
result
will
be.
N
N
Specifically
because
there
was
concerns
around
baggage,
interaction
between
trace
and
and
metrics,
and
then
there's
concerns
around
exemplars
versus
some
other
alternative
that
if
you
look
at
the
bug,
you
can
see
details-
and
we
can
talk
about
that
now,
if
you
want,
but
maybe
not
saline.
H
Yeah,
so
I
I
should
I
try
to
do
that
in
a
fairly.
I
try
to
be
aggressive,
because
metrics
has
been
running
for
very
long
time
and
I
want.
I
want
us
to
see
progress
in
this
case.
People
get
higher
confidence,
especially
from
the
outsider,
which,
like
folks,
are
not
highly
involved
in
open
time
tree.
They
think
that
we
announced
something
and
then
we
missed
the
the
deadline,
and
then
we
announced
another
thing
so
I
want
I
want
us
to
deliver
based
on
what
we
committed
as
much
as
we
can.
H
Meanwhile,
I
I
won't
have
to
feel
confident.
I
I
don't
try
to
push
anyone
who's,
not
confident
enough,
so
I
I've
updated
pr,
try
to
find
a
fair
balance
and
I
need
your
feedback,
because
the
balance
could
vary,
it's
very
subjective.
So
if
you
think
it's
too
aggressive,
please
call
and
tell
us
which
part
is
suspicious
or
we
don't
have
enough
confidence.
E
J
Okay,
I
think
that's
going
to
be
the
one
thing
that
really
will
give
me.
Confidence
is
seeing
three
or
four
languages
have
implemented
this
part
of
the
spec
successfully
and
and
not
run
into
issues,
especially
if
those
languages
are
very
broad.
You
know
you
know,
javan.net,
don't
give
me
as
much
confidence
as
java
and
go,
for
instance,.
E
L
H
Yeah,
so
I
I
think,
depending
on
the
the
feedback,
so
from
from
what
we
got
so
far,
I
I
think
the
majority
part
of
the
view
is
good
enough.
The
concern
was
around
baggage
and
contacts
and
that
part
is
marked
as
a
non-stable,
so
so
either
we
can
mark
the
view
as
mixed
and
for
majority
of
the
part
we
mark
them
as
stable,
with
some
exception
or
mark
the
entire
section
for
view
as
like
non-stable.
J
No,
I
think,
josh's
concern
was
that
we
don't
have
a
view
implementation
at
all
and
go
and
we're
not
sure
it's
possible
to
implement.
Yet
I.
H
Agree
so
if
that's
the
concern,
I
need
your
help
to
comment
on
the
pr
and
I'm
happy
to
change
the
balance,
because
you
can
see
like
once.
We
start
to
having
this
forcing
function
when
we
start
to
collect
the
feedback,
and
people
are
saying
no
to
something
and-
and
I
agree,
we
should
take
the
feedback.
But,
like
my.
J
N
N
We
should
be
very
careful
about
which
languages
like
I,
I
think,
one
of
javascript
or
python
and
then
go,
and
one
of
java.net
seem
like
reasonable
things
as
long
as
velocity
is
good
on
all
those
languages,
but
I
totally
agree
with
you
on:
not
all
languages
are
created,
equal
and
java,
and
net
can
be
very
similar
at
times.
So
it's
it's
more
important
to
me
personally
to
watch.
What's
going
on
with
the
java
and
the
sorry
javascript
typescript
and
the
python
implementations
now
to
see
see
what
happens
in
a
dynamic
language,
ish.
H
H
A
That
makes
sense.
Thank
you
so
much
for
that
yeah!
Please!
Let's,
let's
take
a
look
at
that
again,
I
think
that's
all
in
the
gender.
B
I
had
a
quick
item
I
wanted
to
broadcast
and
then
reminder
everyone.
I've
been
working
on
exponential
histograms
when
I'm
not
working
on
sampling
for
the
last
few
months,
and
I
have
a
fairly
solid
implementation.
That's
been
heavily
tested,
I
am
pleased
with
it
and
it
performs
very
well.
I
would
say
that
it
is
basically
ready
to
go
into
a
sdk
specification,
but
there
are
a
few
corner
cases
and
I'd
like
to
discuss
them
with
someone
else
who
wants
to
implement
this.
B
So
I'm
just
calling
for
interested
parties
to
discuss
things
with
me.
I
have
questions
about
like
do.
We
think
we
should
specify
subnormal
number
support,
which
is
kind
of
ridiculous,
but
someone
something
has
to
be
said
about
it
one
way
or
another
and
that
sort
of
detail
how
to
handle
prometheus
is
the
other
question
that
I've
got
on
my
mind
and
anyway,
I'm
looking
for
discussion
partners.
If
anyone
wants
to
talk
about
exponential
histograms.
Thank
you.
M
Just
a
quick
question,
a
clarified,
clarifying
question
riley
use
said
last
time
that
there
will
be
no
metrics
six
in
in
december
right,
like
none
at
all
or,
and
this
all
consolidated
into
this
meeting.
It's
consolidated
in.