►
From YouTube: 2021-08-20 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
I
guess
what
I
discovered
today.
I
discovered
that
zipkin
lower
cases
all
span
names.
A
A
A
C
A
No,
no,
this
is
android
where
we're
exporting
zipkin,
because
our
back
end
right
now
only
ingests
it
for
rum,
lower
case.
A
No,
but
what
I
have
done
is
I've
copied
the
encoder
over
into
my
code
base
and
hacked
on
it,
but
it
had
the
encoder.
The
problem
is
the
encoder.
A
A
Yeah,
well
I
mean
we
really.
This
is
me
not
wearing
a
product
manager
hat
at
all,
but
we
should
have
an
end
point
that
just
accepts
our
dlp
or
for
this
use
case.
C
C
A
Anyway,
so
that
was,
that
was
the
surprise.
I
was.
I
seriously
thought
that
the
lower
case
was
coming
from
somewhere
in
our
back
end
pipelines,
and
I
was
like
wait,
but
ios
doesn't
have
lower
case
and
the
web
doesn't
have
lower.
Oh
no,
what's
going
on
looked
right
into
that
span,
builder
and
zipkin,
and
there
it
is
right
away
two
lowercase
on
the
name.
A
Yeah,
well,
what
we
need
is,
we
need
more
bandwidth
and
human
hours
to
go
and
be
able
to
actually
roll
out
otlp.
That
would
be
fine.
Well,
you
know.
The
thing
is
old
signal
effects,
ingest
mission,
I'm
not
sure
which
one
supports
jaeger,
but
our
rum,
it
just
doesn't
support
you.
A
A
C
A
A
C
B
B
B
B
C
That
made
me
remember
this,
since
it
won't
be
till
spring
six,
we
won't
get
to
it.
We
will
still
have
really
weird
things
like
this.
C
B
The
hotel
bridge
from
their
api
inside
the
repo
they
want
to
give
that
to
us.
I
guess
they
don't
want
to
maintain
that
then
so
right
yeah,
let's
see
what
he
says,
yeah.
I
don't
think
I
even
quite
parsed
what
he
said
yesterday
now,
as
I
read
it
again,
so
this
means
that
the
hotel
bridge
between
hotel,
tracer
and
spring
observability
abstraction
will
be
the
only
thing
that'll
be
necessary,
so
we're
proposing
that
we
would
rewrite
it
to
the
new
observability
and
donated
total
job
instrumentation
so
just
bridge.
I
guess.
B
I
said
yeah
that
sounds
good.
I
don't
think
I
quite
understand
it
when
I
said
that
I
was
focusing
on
the
less
instrumentation
and
maintain
aspect
which
sounded
good,
but
we
might
anyways.
If
we
just
do.
We
don't
want
this
bridge,
I'm
sure
they
want
this
stuff
for
somewhere
here,
but
that
was
the
proposal
we'll.
C
B
C
Yeah,
it
might
be
something
worth
raising
to
the
other
hotel
folks.
C
B
I
think
this
is
because
hotel
is
still
way
more
focused
or
unfocused,
but
the
membership
is
still
highly
skewed
towards
vendors
rather
than
anyone
else
like
framework
owners
or
users,
and
so
if
one
of
the
frameworks
is
so
powerful,
they
will
be
able
to
just
beat
hotel.
I
think
so.
That's
one
of
the
risks
of
this
project
in
general,
oh
you
mean
like
prometheus,
has.
B
B
C
If
they
have
big
spring
one
plans,
yeah
definitely.
B
And
so
they
have
to
make
their
abstraction.
I
guess-
and
so
this
is
probably
going
to
be
a
relatively
common
theme,
like
even
our
those
other
couch
spacer
vertex
vertex
vertex
has
its
tracing
instrument
abstraction
as
well,
and
the
main
reason
is
because
they
start
to
support
brave
and
openness
and
just
go
and
drop
it.
And
if
there's
a
point
where
generations
down
they
say
they
can't
drop
it,
and
then
they
just
delete
that
abstraction.
Maybe
that
might
happen,
but
it
feels
as
soon
as
you
have
an
abstraction.
B
C
Yeah,
I
think
the
other
thing
that's
going
to
cause
proliferation
of
those
tracing
abstractions.
Is
people
not
wanting
to
take
hard
dependency
on
hotel,
yet
not
not
wanting
to
bet
on
on.
B
C
Okay,
yeah,
it
got
a
lot
more
complicated
because
it's
now
handling,
I
mean
it's
cool.
It's
now
handling
the
the
wrappers,
the
contact
storage
wrappers
on
both
sides
like
what,
if
the
user
bring
wraps,
has
their
own
context,
storage,
wrappers,
and
if
you,
I
think
in
the
extension,
if
you
an
extension,
has
their
own
context
or
droppers
in
the
agent.
B
B
C
C
Which
I
think
I
think
is
a
good
thing,
because
otherwise
that
is
but
it's
debatable.
I
mean,
I
think
it's
nice.
If
we
can
support
earlier
hotel
versions.
B
B
A
B
A
A
I
guess
it
will
support
the
apis.
Maybe.
A
C
A
problem:
okay,
yeah
yeah,
and
we
had
split
out
already
the
into
two
different
instrumentations
one
for
the
metrics
and
one
for
the
tracing
plus
context.
So
this
I
think
this
should
still
apply.
C
D
D
B
B
D
I
was
gonna
say
if
you
needed
to
like
cross-load
a
different
shim.
C
For
stable
versions,
we'd
like
to
continue
supporting,
so
if
we
have
to
inject
a
different
version,
we
may,
if.
C
D
D
D
Given
the
instrument
lookup
from
instrumentation
happens,
asynchronously
right,
it
means
that
your
name
conflicts
happen
kind
of
asynchronously.
You
don't
know
when
the
user
is
going
to
be
registering
their
instruments
like
you
can't
control
what
order
those
names
come
in,
and
so
it's
entirely
possible
that
the
structure
of
your
jar
files
could
determine
your
error
messages
and
whether
or
not
you
have
a
whether
or
not
your
conflicts
like
are
reported
one
way
or
another.
D
D
You
yeah,
when
you
register
an
instrument
all
of
the
metrics
associated
with
that
instrument
need
to
be
clean
or
you
have
a
name
conflict
and
when
you
have
a
name
conflict,
how
do
we
want
to
report
that?
So
you
know
what
caused
the
name
conflict,
so
you
know
the
source
of
the
view
or
the
source
of
the
raw
metric
instrument
right.
D
D
Yeah,
this
would
kind
of
force
you
not
to
do
that.
Yeah
yeah.
So
so
that's
one
thing
I
was
thinking
about,
but
I
was
thinking
of
not
saving
the
whole
stack
trace,
just
saving
the
portion
of
it
prior
to
the
metric
api
call
like
just
that
line
number
and
class
name.
D
The
the
long-term
cost
like
memory
storage
would
change,
though
yeah
like
stack.
Traces
are
pretty
big.
D
D
Know,
if
you
don't
know
if
your
stack
trace
is
useful
or
if
you
have
it
so
like
on
brawl
vm,
that
doesn't
work
except
like
whatever
you
can
turn
off
the
debug
symbols
in
your
class
files,
if
you
compile
optimized,
not
that
anyone
ever
does
that
in
java,
but
that
would
destroy
your
stack
trace
as
well.
In
any
case,
that
would
be
like
that's
one
thing
I
was
thinking
about
doing.
I
might
make
that
just
an
optional
thing.
D
You
can
turn
on
and
off
yeah,
but
I'm
thinking
of
keeping
the
providence
of
instrument
registration
around
so
that
you
know
exactly
where
things
came
from
so
like
the
instrument.
Descriptor
would
actually
have
the
lines
of
code
that
lead
to
it.
The
problem
there
is,
you
can
register
an
instrument
in
multiple
locations
and
you
get
the
same
instance
back
right.
A
You
know,
I
would
think
that
most
of
this
would
be
covered
by
the
instrumentation
library
info,
like
it's
unlikely
that
a
single
instrumentation
plus
version
would
be
trying
to
register
the
same
thing
in
different
ways
right,
so
it's
either
like
if
you,
if
you
record
the
instrumentation
library
info,
which
you
should
have
anyway
from
the
meter
and
or
I
guess
and
also
then
record
information
about
the
view,
some
sort
of
identifier
around
the
view
that
you
could
reconstruct
and
explain
where
it
came
from
you
could,
then
I
think
that
would
give
you
almost
I
mean
it
would
cover
99.99
of
your
cases.
A
D
Yeah
I
mean
I
can
worry
about
this
later
too.
This
is
just
a
compiler
developer
talking
right
now,
but
the
reason
I
care
is,
I
agree
with
you.
Interpretation
library
info
should
cover
most
of
the
cases
for
most
of
the
instrumentation
we
care
about.
The
main
concern
I
have
right
now
is
that
default
meter
like
if
you
look
at
the
happy
path
developer,
who,
like
just
picks
it
up
and
tries
things
out,
and
they
run
into
some
weird
error
that
they
can't
decipher,
and
that
turns
them
off.
D
A
A
A
C
C
D
All
right:
well,
that's
that'll,
be
the
plan
going
forward
then
we'll
see.
Hopefully
it
doesn't
look
like
crack,
but
that's
my
next
well.
My
next
goal
is
having
multiple
metric,
sorry
yeah,
multiple
metrics
per
instrument,
and
then,
after
that
we
have
to
fix
the
error
messages,
because
then
we
have
all
the
complexity.
C
Yeah
we'll
get
to
one
of
josh's
logging
exporter.
A
A
A
No,
we
didn't
talk
about
https
on
it.
Yeah.
C
B
Plan
plan
for
the
protobuf,
like
I
should
my
next
pair
is
going
to
just
copy
in
the
small
amount
of
code,
encoded
output
stream
that
encodes-
and
I
don't
think
I'll-
do
it
only
for
binary
size,
because
proguard
would
also
do
a
good
job
with
that.
But
I
can
also
remove
that
annoying
buffering
that
it
does,
which
josh
also
pointed
out,
which
is
completely
pointless,
because
the
buffers
are
memory
already
anyways,
so
that'll
go
to
scones
with
one
stone
or
whatever.
I
still
can't
remember.
B
Nikita
nikita
taught
us
this
expression
that
I
forget
to
replace
the
mean
to
birds,
kill
two
birds
with
one
stone:
it's
not
very
acceptive
of
birds,
I
guess
yeah
yeah
anyways.
So
that's
my
plan
there,
and
so
then
the
product
of
java
dependency
has
gone
completely,
and
so
no
one
should
be
able
to
complain
about
that
anymore.
A
C
C
I
was
just
asking
for
sort
of
feedback
on
options
for
suppressing
internal
spans,
but
really
I
don't
want
to
suppress
all
internal
spans
like
I
don't
want
to
suppress
if,
like
with
spam,
if
somebody
uses
the
width
span,
annotation.
C
So
the
like,
what
do
we
call
these?
I
was
gonna.
Do
it
just
as
controller
like
suppress
controller
spans,
but
when
I
went
to
do
this
first,
one
the
web
mvc,
it
has
both
controller
and
view
span,
so
one
thought
that
matej
had
was
if
we
could
make
these
new
instrumentation
types
controller
and
view
and
use
the
existing
suppression
mechanism.
C
I
thought
a
little
bit
about
that
after
and
like
I'm,
not
sure
it's
worth,
I
don't
know
if
it's
worth
the
whole
span
key
thing
and
also
we
would
need
to
expose,
because
the
others
are
very
much
related
to
the
semantic
convention.
So
we
have
that.
D
C
B
B
B
B
And
we
would
want
to
consider
whether
these
should
even
be
suppressed
by
default
because
they're
not
in
the
specs,
so
it
is
a
bit
weird
like
I
always
get
confused
even
yesterday.
I
was
writing
unit
tests
to
test
the
number
of
spans
exported
by
something,
and
I
was
like
yeah.
It's
just
going
to
be
two
standard,
there's
like
five
spans
because
of
all
these
weird
things
that
I
wasn't
expecting.
So
that's
something
we
should
consider.
A
A
C
A
A
C
Cool
benchmark,
oh
yeah,
I
just
wanted
to
get
this
unblocked,
so
confirmed
with
jason.
He
said
which
that
this
made
sense,
but
he
just
he
wants
to
do
it
in
a
follow-up
pr.
C
A
Jack
and
I
chatted
about
exposing
the
the
hdp
otlp,
not
the
json,
with
the
proto
right,
yeah,
http
proto,
and
having
an
auto
configure
for
it
anyway.
He
put
in.
A
D
A
D
Just
so
you
know,
I
expect
that
pr
to
hit
a
whole
bunch
of
dumb
controversy
yet
again
flash
versus
underscore
bristles,
and
we
all
know
why.
D
No
so
there's
there's
supposed
to
be
a
document
coming
out
sometime
in
the
next
week
and
a
half
around
a
config
file
and
a
hierarchical
like
configuration
like
strategy
for
otel
and
then
blending
environment
variables
with
that
config
file
and
and
and
that
sort
of
thing
I'm
trying
to
make
sure
that
it's
supposed
to
come
out
of
the
tc
we're
trying
to
make
sure
that
we
learn
what
like
how
you've
all
been
handling
this
and
that
it
aligns
with
like
what
you've
done.
D
But
that's
that
effectively
that
that
was
the
decision
to
try
to
like
nip
that
you
know
frustration
by
defining
kind
of
a
standard
configuration
convention
so
that
you
can
have
a
configuration
file
for
an
sdk.
That's
somewhat
consistent.
D
And
so,
when
the
specification
has
some
of
these
parameters,
we
can
also
back
it
by
it'll,
probably
be
yaml.
I
mean,
if
we're
honest,
but
something
something
hierarchical.
A
D
A
D
It'll
probably
be
something
like
that,
but
if
you
remember,
I
believe
this
this
that
that
spec,
pr
that
you
have
around
otlp
environment
variables
didn't
one
go
through
about
six
months
ago.
That
was
almost
exactly
the
same
and
just
died
like
it
got
like
two
approvals
and
just
no
one
could
agree
on
it,
so
it
literally
just
didn't
get
submitted.
D
If
I
recall
correctly,
I
don't
remember:
okay,
not
sure
which
yeah
I'll
I'll
take
a
closer
look
at
it
and
see
if
it
aligns
with
the
hierarchy
that
we've
kind
of
been
talking
about
and
then
I'll
see.
If
I
can
help
push
it,
if
we
need
it.
B
D
Okay,
you
know
why
they're
reserved
that's
what
happened
to
the
other
pr.
Now
that
you're
you're
jogging
my
memory,
someone
someone
tried
to
specify
these
three
things
previously
right
and
we
couldn't
agree
on
what
the
hell
http
meant
as
a
as
a
thing
or
like
what
it
would
mean
across
the
different
languages.
D
What
authentication
meant-
and
there
was
this
huge
like
kerfuffle
I'll
see
if
I
can
find
the
original
issue,
but
the
reason
the
reason
it
wasn't
one
wasn't
added
was
because
whoever
makes
this
pr
has
to
go,
investigate
every
freaking
sdk
and
see
what
they
support
with
their
environment
variables
and
make
sure
that
it
all
lines
up.
No
one
was
willing
to
do
that
at
the
time,
so
it
just
died.
D
B
D
So
if
you
look
at,
if
you
look
at
what
the
the
one
I
adapted.
D
Oh
yeah,
it
was,
it
was
a
crap
just
just
getting
people
to
reserve.
The
variables
was
a
pain
in
the
butt,
but
if
you,
if
you
go
to
the
top
of
this,
there
was
a
I
link
an
issue
or
I
adapt
another
pr.
So
if
you
look
at
1340-
and
you
look
at
the
comments
on
this
sucker,
this
went
through.
D
I
think
it
was
at
least
three
spec
meetings
that
I
was
on.
You
know
like
three
different
30-minute
discussions
that
just
went
around
in
circles,
so
that
compromise
was
that
we
were
going
to
reserve
some
environment
variables
to
fix
it
later.
We
never
fixed
it
later
so
yeah.
D
I
should.
I
should
help
out
there.
That's
my
bad
anyway
I'll
see
what
I
can
do
here.
I
just
I
the
we
have
to.
We
have
to
go.
Look
at,
I
think
the
javascript
community
and
I
think
it
was
go
or
python.
I
can't
remember
which
python
python.
B
D
Yeah
yeah,
so
right
now
it
looks
like
you're
using
the
wire
library
to
generate
your
own
protobuf
files.
Can
we
just
use
wire
directly.
B
So
our
job
is
to
serialize.
These
objects
called
scan
data
which
aren't
protobuf,
and
so
that's
why
we've
written
a
lot
of
hand,
written
serialization
logic
for
those
guys
to
write
in
sort
of
a
format
so
wire,
since
it's
just
just
realized
protos.
I
don't
think
it
can
help
us
that
much
oh
you're
trying
to
avoid.
B
D
B
B
B
Okay,
cool,
at
least.
Maybe
my
plan
is
to
just
do.
C
B
D
I
I
mean
I
implemented
my
own.
B
There's
we'd
have
to
do
an
output.
We
have
to
go
into
an
output
screen.
D
Yeah,
what
I
wrote
is
in
scala
and
it
goes
to
an
output
stream,
but
my
question
here
is:
there's,
there's
a
bunch
of
like
weird
nuanced
context
of
coded
input
stream.
For
example,
it
assumes
that
you
are
storing
your
streams
as
utf-8
bytes,
instead
of
string
instead
of
java
strings
and
crap,
like
that,
you
can
get
a
little
bit
of
a
performance
win
and
a
little
bit
of
performance
loss
by
like
implementing
your
own
kind
of
wire
marshaling.
D
B
I
mean,
I
think
the
next
pr
is
to
just
get
something
up
quickly
and
then
we
should
iterate
on
it.
If
there's
ideas
to
go
from
there,
okay.
D
Then,
for
performance
is,
if
you
don't
pass
the
size
every
time
you
pass
in
an
output
stream,
you
get
you
get
a
significant
hit
to
your
gc
yeah.
So
that's.
B
B
Yeah
well
thanks
for
calling
that
up,
and
so
that's
as
I
vendor
this
and
I'm
going
to
remove
the
buffering
so
that
just
that
parameter
is
gone.
That's
my
plan
because
we
do
know
the
output
streams
are
not
actually
output
streams,
they're
buffers
because
it's
grpc,
so
this
just
happens
to
be
using
the
output
stream
api.
So
we
don't
even
need
that
buffering
so
I'll,
be
removing
that.
D
Okay,
I
had
a
hell
of
a
time
trying
to
beat
that
buffer
in
performance
benchmarks
for
various,
depending
on
what
our
rpcs
look
like.
D
I
was,
I
was
benchmarking
straight
against
bite
array,
output
stream
and
the
buffers
actually
did
matter.
Sadly,
okay,
so
I'll
check
that
yeah
I
so
they
they
do,
they
do
like
unsafe
raw
bite
or
system
memory
copies.
So
it's
it's
like
somewhat
efficient
for
them
just
to
shovel
things
around
at
times
I
forget
what
they
were
doing
with
the
buffer
that
mattered.
There
was
like
one
thing
that
I
couldn't
figure
out
how
to
replicate
externally.
D
C
D
Be
okay,
but
I
can't
I
can't
recall
off
the
top
of
my
head.
Definitely.
D
Okay,
oh
the
other
thing
is:
there
was
a
blog
article
from
I
think,
datadog
on
a
faster
way
to
encode
variance
that
does
lead
to
a
win.
D
If
you're,
not
storing
yeah,
it
does
lead
to
rent
a
win
when
you
encode
variance
depending
on
what
variant
encodings
you're
using
you
just
have
to
be
careful
if
you
use
it
as
written.
I
don't
know
if
you
care,
but
you
can
get
a
you,
can
get
a
performance
gain
specifically
for
a
fixed
size,
32
variant.
D
You
can
get
a
performance
game
for
fixed
size,
64
variants
and
then
for
the
mixed
one.
It's
like
a
little
bit
of
a
game,
but
it
it
is
kind
of
worth
it
if
you're
trying
to
super
hyper
micro
optimize.
But
it's
also
something
you
can
do
later.
A
D
Yeah,
they
said
never
use
program
for
telemetry,
but
whatever
they
at
least
gave
me
an
idea
for
how
to
optimize
that
the
leading
zero
lookup.
C
B
D
D
Let
me
see
if
I
can
find
my
code
and
see
if
it's
actually
useful.
It
might
not
be.
D
But
again,
that's
something
you
can
do
later.
It's
not
important
right
now,
those
are
just
randomized.
If
we're,
I
don't
how?
How
highly
are
we
trying
to
optimize
this
stuff?
Just
curious,
like
I'm
curious
what
led
to
us,
rendering
this
stuff.
A
B
But
yeah
so
they're
coming
from
android,
it's
like
yeah.
We
don't
want
all
this
binary
size,
let's
say
so
they're
up
there
solution
to
that
was
to
add
a
json
exporter
and
I
think
the
solution
to
that
is
to
just
not
have
binary
size
and
report
above
exporters.
So
that's
what
led
to
this
yeah
and
we're
almost
there
yeah
and
it
doesn't
seem
to
I
mean
bogdan-
did
the
crazy
stuff
already
in
december
or
something
and
I
like
the
auditions
to
get
rid
of
the
part
of
a
have
been
quite
slim
since
then
so.
A
A
I
no
there's
no
requirements
of
approvers
that
they
must
approve
everything
or
must
review
everything.
It's
mostly
it's
mostly
just
a
little
bit
of
a
like
the
more
people
who
can
help
me
and
honor
out
on
reviewing
the
stuff,
even
if
it's
only
like
can
pick
off
one
here
and
there,
especially
like
the
two
of
you
working
on
photobooks,
really
helpful
to
me,
because
it's
all
great
to
me
at
this
point
that
part
of
it
so.
D
Yeah,
I'm
I'm
happy
too
all
right.
Well,
this
this
is
code
I
actually
enjoy
reading
so.
D
D
Yeah
see,
but
that
that
would
be
what
we
call
20
time.
If
I
get
all
the
way
in
there
at
this
point,
we're
working
our
way
that
way,
you'll
see.
D
Yeah,
have
you
I'm
kind
of
curious
with
these,
with
these
optimizations
and
things
if
any
of
this
makes
sense
kind
of
across
the
board
or
if
it
was
highly
tuned
for
span
and
that
proto
conflict
like?
Are
we
doing
this
for
the
metric
serialization
code
as
well?
I
think
we
will
want.
B
To
once
it's
stable
we'll
want
to,
but
until
it's
stable,
I'm
not
planning
on
doing
anything
well,
the
protos
are
stable.
The
sdk
structure
is
also
pretty
stable.
B
D
Yeah
I,
if,
if
I
do
break
that
you
can
come
back
and
yell
at
me
or
like
hit
me
with
a
stick
or
something
because
but
like
at
this
point,
that
stuff
should
be
darn
stable
and
like,
or
we
made
a
giant
mistake,
but
yeah.
We
marked
all
that
stable
in
the
specs
so
far,
so
that
shouldn't
be
changing
one
other
thing
about
metrics.
B
That
I
wonder
about
is
even
though
otlp
is
stable.
Is
that
what
we're
all
like?
I
remember
this
open,
metrics
discussion
and,
like
I
don't
know
if
it's
still
100
certain
that
otlp
is
the
format
we're
definitely
going
to
use
like
it's
definitely
a
format,
but
we
might
use
a
different
one,
and
if
we
is
a
different
one,
then
we
may
as
well
just
focus
our
efforts
on
that.
So
that's
always
in
my
mind
also.
D
D
So
have
you
looked
look
at
the
details
of
columnar?
I
want
to
get
some
more
opinions
on
there,
but
there's
when
you
look
at
columnar
data
right,
there's
an
area
of
code
where
it's
highly
useful
and
it's
when
you
have
actual
multivariate
metrics
a
lot
of
the
stuff
that
you're
collecting,
isn't
necessarily
multivariate
and
to
the
extent
that
multivariate
makes
sense
great.
D
I
think
it's
going
to
be
super
useful
and
it's
going
to
be
a
great
addition,
but
I
also
think
that
we're
going
to
have
a
lot
of
hard
decisions
to
make.
I
don't
think
we
just
flipped
the
whole,
because
the
multivariate
story
is
everything
it's
logs,
traces
and
metrics.
D
So
so,
if
that
hits
that's
all
output
yeah!
That's
not
just
you
know,
metrics,
it's
a
good
way
to
put
it
yeah.
So
I
I
would
take
a
look
at
the
actual
details
there,
because
I
think
it's
going
to
be
highly
useful,
but
I
also
think
it's
going
to
be
a
little
situational
it
might,
it
might
even
have
its
own
instrumentation,
we'll
have
to
see
yeah
think
about
our
current
apis
and
trying
to
unify
everything
around
the
same
time.
D
D
But
if
you
look
at
what
we've
built
we're
not
building
metrics
from
spans
today,
that's
something
we
should
probably
talk
about.
I
saw
your
proposal
around
instrumentation
and
trying
to
make
that
easier.
That's
where
I
think
this
could
fit
in
real
well,
but
all
those
other
metrics
that
you
grab
that
aren't
tied
to
a
span
or
a
trace.
D
D
Yeah,
I
should
drop
two.
It
was
good
good
to
see
everybody
and
I'll
follow
up
this.
Just
a
quick
question
around
this
otlp
protocol
specification.
Pr
do
you
need
the
spec
pr
to
go
through
before
you're
willing
to
allow
the
environment
variability
used
in
that
way?
In
java.
D
Right
so
I
think
at
a
minimum
I'll
recommend
that
he
mark
the
protocols
as
like
sdks
must
support
that
or,
and
should
support
both.
They
may
also
support.
That's.
B
Even
though
our
auto
configure
module
is
unstable,
we
do
consider
the
variables
that
agent
exposes
table
yeah.
So
there's
no
problem
with
adding
hotel
underscore
experimental
underscore
exporter
underscore
whatever,
like
we
use
the
hotel
under
experimental
namespace
for
any
properties
that
we
haven't
committed
to,
so
that
there's
no
problem
and
if
that
unlocked
something,
but
I
don't
think
we'd
want
to
use
these
names
unless
it's
in
respect.
A
I
like
the
idea
honorary
of
the
experimental
so
when
jack
puts
the
pr
in,
we
can
add
that
to
the
er
comments,
all
right
cool
have
a
good
one
cool
see
y'all
later.
C
Cool
yeah
so
yeah.
I
will
plan
on
clicking
that
button
tomorrow
and
I
don't
think
we've
changed.
We
changed
the
gradle,
the
muzzle
and
gradle
stuff,
but
I
don't
think
that
should
affect
the
basic
release.
B
B
B
B
B
C
B
B
C
C
I'll
try
to
post,
I
have
the
I
started
the
I
have
a
draft
of
the
change
lag
so
I'll
post
that
end
of
before
I
turn
in
today,
so
that
in
case
you
want
to
review
anything
well,
I.