►
From YouTube: 2021-04-15 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
C
B
A
A
A
D
I
think
we
could
probably
get
started.
Actually,
I
am
probably
not
the
most
prepared
for
this
meeting,
so
I
apologize
in
advance
but
yeah,
let's,
let's
jump
into
it.
Welcome
everyone.
If
you
are
here,
please
make
sure
you
add
your
name
to
the
attendees
list
on
the
agenda.
Docs.
If
you
have
anything
you'd
like
to
discuss,
add
to
the
agenda.
D
I
have
one
thing
there
currently,
but
I've
got
probably
some
other
things
I
kind
of
wanted
to
go
over
the
the
rc
project
board
and
that
kind
of
thing.
So
let
me
start
sharing
my
screen
and
we
can
jump
into
it.
D
Cool
yeah,
we
can
start
off,
I
guess
by
noticing,
what's
not
there
and
that
would
be
the
open,
telemetry
specification
audit
for
our
sake
that
was
completed
last
week.
So
officially
yeah
we're
we're
all
done.
There
was
a
pr
that
was
closed,
and
so,
ideally
this
is
a
pretty
comprehensive
project
board.
Now
that
is
gonna
get
us
to
rc.
There's
some
caveats.
I
think
there
which
hopefully
we'll
kind
of
talk
about
in
a
second.
E
D
Yeah
overall,
like
momentum
here,
we're
doing
good
we're
going
down
in
the
two
column,
the
in
progress
is
going
down.
It's
actually
remaining
pretty
stable,
we're,
definitely
seeing
a
lot
more
activity
and
just
like
getting
things
across
the
board
done
still
a
little
slower
than
I'd
like,
but
you
can't
force
perfection
is
how
I
look
at
it:
yeah
not
still
making
progress,
so
that's
definitely
a
positive
direction.
D
The
issues
themselves
are
definitely
flowing
through.
I
would
like
to
go
over
these
a
little
bit
just
so
we
can
maybe
just
talk
about
at
a
high
level
for
anything,
that's
in
progress,
and
I
think
all
of
these
are
mine
for
prs
that
are
actually
open
for
the
review
to
approved,
which
I
can
kind
of.
Maybe
we
don't
have
to
go
too
deep
into
any
of
these.
I
do
know
that
this
needs
more
eyes.
D
It
definitely
needs
my
eyes
on
it.
That
is
something
that
I
think
that
pablo
has
just
submitted
another
pr
for
yeah
and
definitely
need
some
more
eyes
on
this
came
out
yesterday.
I
definitely
know
that,
if
you're
looking
for
pr
reviews
as
everyone
always
does,
you
know
at
every
hour
of
the
day,
these
are
also
some
really
good
pr's.
They
could
definitely
use
some
some
more
reviews.
D
Anthony's,
I
think
reviewed
almost
all
of
these,
if
not
all
of
these
yes,
so
anthony
is
definitely
exempt
from
that
request
and
thanks
again
anthony
for
doing
all
the
reviewing.
While
I
said
I
really
buy
and
do
none
of
it
so
yeah,
I'm
definitely
deploying
for
a
lot
of
it
as
well.
D
That
being
said,
blaming
aside
definitely
would
appreciate
any
kind
of
review.
It
is
really
helpful
in
progressing
the
projects
and
progressing
this
project
board
so
yeah.
I
really
appreciate
it.
We're
kind
of.
D
Yeah
I
wish
my
job
was
just
coding
yeah.
It
turns
out
there's
a
a
need
to
keep
current
and
help
help
progress
the
project
for
reviewing
but
yeah.
I
appreciate
it
so
maybe
yeah
we
can
just
jump
in
a
little
bit
in
progress.
I've
got
two
in
here
which
can
maybe
I
can
just
kind
of
highlight
what
I've
been
up
to
for
the
past
week
and
make
sure
that
everyone's
kind
of
aware
of
that
word
around.
D
Let
me
know,
because
I
don't
mean
to
offend
anybody
by
moving
things
up
or
down,
so
the
clarification
between
the
package
demarcation
for
sdk,
trace
and
xdk
export
hasn't
moved
since
last
week,
because
I
went
through
this
and
I
have
like
kind
of
a
proof
of
concept,
and
I
realized
that
one
of
the
blockers
is
that
the
bundler
in
the
jaeger
exporter
is
something
that
requires
a
value
to
be
set
into
it.
So
we
can
bundle
things
effectively
and
currently
we're
passing
in
whatever
the
export
spans
argument
is.
D
So
if
we're
going
to
change
that
into
something
that's
an
interface,
it
can't
work
with
the
bundler.
So
then
it
comes
to
the
the
question
of.
Why
is
the
bundler
even
there
and
I
didn't-
I
don't
have
a
good
answer
for
that
and-
and
I
think
I
went
through-
and
I
went
through
a
lot
of
the
history
and
I
think
it
extends
because
it
was
there
prior
to
spam
processors
existing
it
was
prior
to
actually,
I
think
it
was
prior
to
the
exporter
interface
existing
in
its
current
form.
D
I
definitely
know
it
was
there
before
its
current
form.
So,
like
the
exporter,
the
yeager
exporter
itself
creates
a
lot
of
stuff
in
the
tracing
pipeline.
So
I
think
that
the
bundler
was
there
prior
to
the
batch
expand
processor.
D
I
know
it
was,
and
so
I
know
that,
like
that
was
kind
of
the
original
idea,
but
it
seems
at
the
very
least
you're
going
to
have
an
impedance
mismatch
kind
of
identifying
this
issue
and
at
worst
you're
going
to
have
cognitive
overload
as
to
like
which
one
should
be
doing
the
batching
and,
like
I
don't
know
like
this,
is
really
confusing.
D
So
this
is
going
to
remove
it.
I've
got
a
proof
of
concept,
pr
that
I
opened
here,
which
has
a
bunch
of
other
cleanup
in
it,
and
mostly
the
go.some
files,
are
the
big
removals.
But
it's
still
a
very
large
pr.
I
didn't
want
to
like
force
that
on
people,
so
I've
broken
this
up
into
a
bunch
of
smaller
pr's.
D
That's
what
all
of
these
are
essentially
they're
about,
like
80
of
the
actual
work
and
then
there's
probably
one
or
two
more
follow-up
prs
once
these
actually
get
merged
the
really
important
one
and
like
really
important
one,
is
this
pr
which
adds
benchmarks
to
get
your
exporter
yeah
I'm
seeing
a
thumbs
up,
and
it
turns
out
like
it's
really
kind
of
helpful
in
understanding
like
the
allocations,
as
well
as
the
operations
and
that
kind
of
thing
and
making
sure
that,
like
removing
the
bundler,
isn't
like
an
added
a
huge
added,
you
know
burden
or
it's
gonna
cause
severe
performance
impact,
which
I
validated
in
that
proof
of
concept.
D
It
doesn't,
in
fact
it
reduces
a
lot
of
allocation,
reduces
operation
time
and
that
sort
of
thing
so-
and
I
think
it's
also
really
helpful-
to
have
these
sort
of
things,
probably
for
all
of
the
exporters.
I
think
there
might
be
one
for
the
otp,
but
like
maybe
zipkin
as
well
as
we
go
to
rc,
just
to
understand
like
as
we
make
changes
like.
Are
we
progressively
impacting
people
because
our
performance
is
being
degraded
like
these?
Are
these
can
be
definitely
used
in
really
high
throughput
systems?
D
So
we
want
to
make
sure
that
that's
kind
of
a
concern
that
we
address
so
yeah.
I
wanted
to
get
this
merged,
so
we
can
track
as
each
one
of
these
changes
go
through
I've
already
kind
of
like
pseudo
done
that
by
cherry
picking
this
pr
and
other
things
and
showing
like
the
actual
benchmarking
but
yeah.
I
think
it's
a
positive
change,
so
yeah
and
then,
while
waiting
on
those
prs
to
merge,
I
went
back
to
everyone's
favorite
flaky
test
and
by
everyone.
D
I'm
pretty
sure
it's
just
anthony,
because
we
have
to
deal
with
this
test
all
the
time
it
fails,
and
it's
this
idea
that.
D
D
I
found
a
partial
solution
prior,
but
now
I've
I've
got
a
actual
solution
where,
instead
of
doing
any
sort
of
waiting
or
just
using,
I
wrapped
the
listener
in
the
actual
mock
or
collector,
and
it
just
had
to
tell
you
when
it
gets
a
new
connection
instead
of
just
waiting
and
assuming
that
a
connection
came
through
and
I've
cleaned
up
a
few
other
things
as
well,
that
I
think,
were
actually
causing
some
underlying
errors
it's
hard
to
validate,
because
I've
also
found
that
the
majority
of
this
test
failure
comes
on
the
mac
platform
and
I'm
not
testing
on
the
mac
platform.
D
Yeah
in
the
past
month
saw
30
errors
on
a
mac
between
1.14
and
1.5
and
just
a
few
1.2
none
on
windows,
but
I
think
that's
because
windows
is
really
slow
in
our
ci
system
and
it
just
doesn't
get
to
it,
but
that's,
not
a
great
windows
just
that
the
ci
system.
Implementation
of
windows
is
just
got
a
lot
over
it.
So.
F
Yeah,
so
I
noticed
that,
like
in
github
actions,
stuff
done
using
mac,
os
takes
probably
the
the
bootstrapping
phase
is
like
10
times
longer
than
something
using
linux.
D
Yeah
yeah,
I
I
don't
actually
know
what
their
abstraction
is
there,
but
I
I
would
imagine,
there's
just
like
another
layer
in
between
the
two
to
try
to
you
know
shim
in
a
kernel
plug
or
something
like
that,
but
yeah.
D
Yeah,
I
think
that
that's
that's
ultimately
always
going
to
be
the
case
so
yeah.
I
think
that's
puna
on
the
the
telephone
as
well,
but
you
would
definitely
be
happy
to
know
that.
I
think
I
think
I
have
a
resolution
for
this
one.
I'm
thrilled
okay,
cool
yeah,
I'm
also
looking
through
a
bunch
of
the
other
errors
and
there's
just
when
I
have
free
time.
D
I
love
that
I
get
to
do
these
kinds
of
things,
because
they're
gonna,
they're
forced
multipliers
having
these
things
fixed,
just
gonna,
make
me
feel
better
cool,
so
I
think
that's
kind
of
it
for
the
two
that
I've
got
in
progress
here.
I
don't
know.
I
think
this
is
drew
or
is
this
I
can't
remember
psy
right,
I
don't
know
if
you're
on
the
call,
I
think
I
saw
a
pr
come
in
for
this.
D
C
There
is
a
pr
for
this,
or
where
did
it
already
land
yeah?
It
looks
like
that
pr
might
have
already
landed.
There
was
another
one
related
to
jaeger.
I
believe
that
was
in
process.
C
Nope,
sorry,
the
the
other
one
related
to
environment
variables
was
for
resource
that
that
was
the
one
that
drove
has.
D
Okay,
that's
right,
yeah!
I
definitely
that's
another
one
that
needs
more
attention
than
I've.
Given
it.
I
definitely
see
some
other
people
have
kind
of
come
in
here,
but
yeah,
that's
another
good,
one
cool.
I
think
this
can
be
closed.
Then
right.
I
think.
C
D
C
D
Look
at
that
we're
making
progress
again
in
the
meeting
awesome
down
to
four.
What
is
next
sorry
go
ahead.
Aaron.
B
I
do
have
a
thing:
the
convenience
function,
the
only
thing
that's
holding
that
up
is
the
jaeger
which
I
know
is
under
flux.
If
you
want
I'm
okay,
closing
that
as
long
as
something
in
jaeger,
we
can
review
the
jager
when
you're
all
done.
D
Oh
wow,
okay,
yeah,
thanks
for
bringing
that
up,
because
I
was
kind
of
waiting
on
you
on
that
one.
I
actually
need
that
trace
provider
to
be
returned
so
yeah
thanks
yeah.
I
I
can
submit
a
pr
for
that,
maybe
not
right
after
meeting,
but
today
I
can
definitely
do
that.
I
thought
that
you
would
submit
something.
So
I
just
didn't
do
anything
but
yeah.
B
D
Yeah
I'll
I'll
submit
a
pr
for
that
and
then
I'll
try
to
link
it
and
close
it
later
on
this
afternoon.
If
that
sounds
yeah,
that
sounds
great
yeah,
perfect
cool,
because
I
was
also
one
of
the
other
small
pr's
I
needed
to
break
out
from
this
so
looks
like
communication
is
a
really
helpful
thing
and
I'm
glad
we
have
these
meetings
cool
was
that
one
of
the
ones
that
was
in
proc,
okay
cool?
I
just
moved
it.
There
awesome
cool.
D
C
F
It
was
like,
is
there
a
spec
issue
about
possibly
changing
that
anthony.
C
I
haven't
created
one.
I
don't
know
how
much
I
care
to
fight
that
fight.
I
don't
know
if
it's
going
to
be
viewed
as
a
significant
breaking
change
or
oh
yeah,
we
of
course
we
always
meant
that
which
means
I
probably
should
just
open
an
issue
and
create
it
but
yeah.
I
I
don't
know
that
it
matters
enough
for
most
things,
because
I
expect
a
lot
of
the
resources
that
people
are
going
to
want
to
set
by
environment,
aren't
going
to
be
set
by
a
detector
and
vice
versa.
D
Yeah,
I
think
it's
a
good
question.
I
don't
know
it's
been
a
if
it's
been
a
part
of
the
conversation
at
the
spec
level
before
so
I
I
do
think
that
it's
probably
worth
at
least
posting
it,
and
this
is
probably
the
best,
as
you
said,
because
that
is
track.
C
Okay,
I
I
will
create
an
issue
in
the
spec,
then
and
bring
it
up
next
week
at
the
spec
meeting.
Awesome.
D
One
more
the
otp
exporter
only
for
traces.
I
think
this
had
a
pr
ryan
might
have
submitted.
Yes,
she
spoke
again
yeah.
It
just
needs
some
reviews.
Oh
I
was
actually
gonna.
Try
you
guys,
don't
have
to
see
me
label
things.
I
wanted
to
keep
these
in
the
project
as
well
as
we
see
these
and
have
them
tracked,
but
I
can
do
that
at
another
time.
D
Then
there's
aaron's
and
then
pablo
pablo.
Are
you
on
the
call
yeah.
E
D
Yeah
cool
that
was,
I
think,
what
the
consensus.
Well,
it
was
the
majority
of
the
consensus
I
think
from
last
week
was
exactly
what
you
said
you
know
go
through
both
of
those
and
then
look
at
the
collector.
The
other
thing
to
consider
also
is
if
this
is
gonna
be
a
severe
undertaking.
D
The
specification,
I
don't
think,
is
an
absolute
requirement
that
we
support
this,
so
it
may
be
something
that
we
could
also
document.
If
you
think
that
it's
going
to
take
like,
I
don't
know
a
month
to
do
but
yeah,
if
you
think
that
you
can
achieve
this,
which
I
I
don't
think
it's
gonna
be
like
impossible
to
just
copy
the
collector
algorithm,
then
yeah.
I
think
we
should
probably
try
to
do
that.
D
Cool,
that's
it
for
all
of
the
in
progress
issues
that
I
had.
I
don't
actually
think
we
had
any
more
to
do's
added,
in
fact,
just
lost
two,
so
making
a
lot
of
progress,
wow
and
all
of
the
twos
have
somebody
assigned
to
them,
except
for
this
one
which
it's
some
it's
an
investigation
before
our
solution
is
actually
defined,
so
yeah
we're
doing
really
good,
actually
cool.
D
Is
there
anything
else
that
anybody
want
to
talk
about
on
that
board
before
we
move
on,
or
can
we
kind
of
just
jump
into
the
next
issue
of
the
only
issue?
That's
on
the
agenda.
D
Cool,
so
I
just
wanted
to
bring
this
up.
I
had
a
colleague
here
at
splunk
who's
doing
some
some
work
to
try
to
integrate
a
customized
wrapper
around
http
instrumentation,
adding
particular
headers,
and
that
kind
of
thing
it's
linked
here
in
this
repo,
but
it
was
kind
of
one
of
the
things
that
I
was
noticing.
D
Is
that,
like
some
of
the
structure
in
the
creation
function
is
where
we
have
to
essentially
pass
in
all
of
these
other
like
options
that
are,
you
know,
vendor-specific,
and
then,
on
top
of
that,
you
have,
to.
D
You
know
wrap
like
the
the
idea
of
all
of
the
hotel,
specific
options
and
pass
those
in
as
well,
and
I
think
if
this
comes
back
to
the
the
idea
that
the
options
themselves
are
not
like
exportable
and
you
can't
really
extend
them
as
a
as
a
third
party,
they're,
essentially
locked
in-
and
you
know
I
I
mentioned-
maybe
there's
a
better
way
to
do
this
and
it
was
definitely
taken
off
and
robert
over
here,
just
kind
of
went
with
it
and
he
came
up
with
a
lot
of
ideas.
D
D
I
have
to
admit
that
I
haven't
seen
a
lot
of
the
stuff
that
just
came
in
today,
but
I
am
seeing
a
lot
of
familiar
faces
on
the
call
in
this
conversation
and
specifically
anthony,
I
think,
you're,
making
some
interesting
points
that
was
just
skimming
this
last
one
right
before
the
meeting
about
you
know.
Maybe
there's
just
some
structure
as
to
how
you
want
to
like
wrap
things
instead
of
you
know,
duplicating
things
is
a
really
good
point
and
I
think
that's
something
that
I
think
I
was
gonna
go.
D
Take
a
look
at
he's.
Also
in
I
think
estonia,
if
you're
watching
this.
On
recap,
I
apologize
if
that
isn't
correct,
but
yeah.
Definitely
I
don't
think
he's
awake
at
this
point
or
shouldn't
be
and
so
yeah.
I
think
that
there's
some
interesting
ideas
here,
because
it
really
like
pointed
out
to
me
that
this
is
not
going
to
be
something
that
is
a
pain
point
just
for
him
and
splunk,
but
I
think
for
many
people
that
want
to
wrap
that
instrumentation.
D
D
So
I
think
it's
a
really
a
good
issue
to
get
a
lot
of
feedback
on
and
get
a
lot
of
information
or
brainstorming
and
just
kind
of
like
get
this
get
this
right
before
I
you
know
go
through
and
try
to
redo
all
of
the
configuration
and
all
of
the
the
repos,
I
think,
is
a
good
idea.
C
Yeah,
I
think
the
the
comments
from
earlier
today
by
who
is
this.
C
Thomas
about
you
know
these
options,
really
shouldn't
even
be
exported
is,
is
a
good
one
as
well
right.
We
export
them
so
that
the
the
type
so
that
it
can
be
documented
so
that
people
can
create
slices
of
them
to
programmatically,
manipulate
the
options
that
they're
using
but
they're,
not
really
interfaces
that
are
meant
to
be
implemented
or
used
outside
of
the
package
where
they're
defined
they're
they're
for
configuring.
That
package,
and
as
as
for
the
the
structure
that
splunk
hdb
is
trying
to
take
here.
C
I
totally
get
the
desire
to
simplify
things
for
end
users
by
providing
them
hey,
run
this
one
function
and
hand
it
your
http
handler
and
you'll
get
everything
all
wrapped
up,
including
the
splunk
additional
bits
that
convenience
is
nice,
but
I
think
it
might
be
limiting,
because
it
then
forces
the
user
to
use
the
hotel,
http
instrumentation
and
and
precludes
them
from
using
anything
else
if
they
want
to
use
a
different
handler
or
a
router.
You
know
my
last
job.
C
I
had
a
function
like
that,
but
that
was
because
I
was
able
to
make
the
choice
for
us
that
we're
going
to
use
auto
http
we're
going
we're
not
using
you
know
another
router
or
if
you
are
just
put
it
in
here
anyways,
and
this
is
the
way
we're
instrumenting.
C
I
don't
know
if
that's
a
choice
that
I
would
make
as
a
vendor.
I
think
splunk's
certainly
welcome
to
do
it,
but
if
you
are,
I
would
still
recommend
that
you
provide
your
own
implementations
of
those
options.
Then
you
know
have
functional
options
for
splunk
http.
That
can
then
internally
invoke
the
hotel,
hdb
options.
B
I
haven't
gotten
to
the
time
to
write
that,
but
that
was
going
to
be
my
observation.
If
you
are
actually
going
to
wrap
this
entirely,
you
should
wrap
it
entirely
and
have
its
own
presented
interface
that
maybe,
under
the
hood,
just
calls
the
hotel
http
options
but
they're
still
your
abstraction,
not
our
abstraction,
because
we
may
start
changing,
especially
the
underlying
implementation
in
the
config
and
whatnot.
F
On
the
subject
of
exporting
the
option
types,
I
know
that
when
I
first
started
using
functional
options,
I
always
made
the
option:
type,
private
or
sorry
unexported
and
then
ran
into
that
problem
of
cases
where
callers
wanted
to
to
build
them
up
programmatically.
So
they
because
there's
some
options.
You
know
where
you
either
supply
it
or
you
don't
you
can't
like
pass
a
boolean
value
to
it,
let's
say
and
if
anthony,
I
think.
One
of
the
ways
that
we
first
met
was
over
a
pr
like
that
right.
F
Remember
that,
where
we
kind
of
change
it
to
like
an
enable
disabled
boolean
rather
than
presence
or
absence
of
the
option,
but
the
whole
idea
where
you
can
declare
a
slice
of
them
and
then
programmatically
add
them
in
and
then
and
then
expand
the
slice
out
to
to
call
it
that
whole
technique
is
impossible
for
callers.
If
you
don't
export
the
option
type,
which
is
unfortunate,
that
that
difference
of
how
you
can
use
the
options
just
fine
when
the
option
type
is
not
exported.
But
then
you
can't
talk
about
collections
of
them.
D
Right
and
I
think
that
that's
a
really
important
reason
why
you
would
want
to
have
that
exported,
but
then
yeah
it's
just
it's
a
fine
line
between
that
and
then
I
think
how
how
much
do
you
want
to
expose
yeah?
I
think
that's
a
it's
a
hard
one,
I'm
interested.
I
I
like
the
idea
that,
anthony
before
to
just
like
wrapping
the
handler,
gets
rid
of
the
problem
entirely.
D
I'm
always
a
big
fan
of
engineering
away
the
problem,
but
yeah
I
I've
got
to
think
about
it,
a
little
more
but
cool
yeah.
If
anyone
else
has
opinions,
this
would
be
really
helpful
because
I
guess
I'm
using
this
as
a
precursor
for
another
one
of
the
issues
that
we
have
here,
which
we
currently
already
have
some
best
practices
documented
for
options.
D
But
if
these
kind
of
lay
us
in
a
different
direction,
we
may
want
to
update
them,
and
so
then
this
issue
right
here
would
be
something.
D
Address
in
a
different
way,
so
yeah,
if
you
have
opinions,
please
go
comment
cool.
I
see
bridges
added
logging
in
the
otop
exporter.
I
will
hand
it
over
to.
G
You
rich
yeah.
This
is
just
a
really
simple
question.
You
probably
know
the
answer
as
an
end
user
of
the
open
telemetry
for
the
library
I've
been
sending
spans
to
an
otlp
endpoint
over
which
I
have
no
control,
and
so
I'm
wondering
how
can
I
see?
How
can
I
get
it
to
just
dump
the
spans
that
I'm
sending
in
a
json
format,
so
I
can
tell
I'm
doing
it
correctly.
D
Are
you
sitting
down
there's
a
lot,
I
think
here,
okay,
we've
we've.
We
definitely
there's
an
issue
already.
We
wanted
to
add
logging
throughout
the
entire
sdk.
I
think,
as
well
as
provide
some
sort
of
interface
for
exporters
to
use
that
sort
of
logging.
It
has
been
postponed,
I
think,
till
after
rc,
just
because
it
wasn't
considered
something
like
super
like
critical,
so
also
in
the
otlp.
We
don't
have
any
any
logging
plumbed
in.
D
Currently,
I
think
in
the
jaeger
exporter,
or
maybe
it's
the
zip
code,
I
think
maybe
the
zipkin
there's
like
this
weird
thing.
I
saw
that
there
you
can
actually
provide
it
a
logger
and
it
will
already
has
logging
plugged
in
again
these
are
exporters
that
have
existed
for
a
long
time.
It's
a
long
way
to
say
like
maybe
in
the
future.
You
may
be
able
to
do
exactly
what
you're
looking
for,
but
until
then
you
would
likely
be
best
served
by
registering
a
second
span
processor
that
has
the
standard
out
exporter.
D
Spans
are
also
being
exported
through
that
way.
Unless
somebody
has
some
brilliant
ideas
that
I
haven't
thought
of.
B
B
D
Yeah,
that's
awesome,
that's
a
really
good
idea
as
well.
Usually
it's
yeah
kind
of
the
same
thing
like
you.
Kind
of
you're
gonna
have
to
diverge
at
the
span
processor
level,
but,
like
I
don't
know,
it's.
D
Loop
right,
ideally
you're
getting
the
same
data.
B
D
Cool
yeah
and
ideally
yeah
this.
This
is
something
and
then
on
top
of
that
the
open
telemetry
project
as
a
whole.
This
is
the
other
side
of
the
story.
It
wants
to
provide
logging
signals
as
well
so,
like
I
can
imagine
somewhere
there's
going
to
be
an
internal
hookup
to
that
structure
or
whatever
that
signal
structure
is
going
to
look
like
as
well.
D
So
maybe
there's
a
really
good
story
there,
and
I
think
that
might
also
been
one
of
the
reasons
we
wanted
to
wait
on
plumbing
in
the
logging
system
with
sdk
yeah.
That
makes
a
lot
of
sense,
yeah
cool.
The
last
thing
I
added,
as
I
just
remembered
during
this
talk,
it
kind
of
came
up
in
the
specification
meeting
on
tuesday
for
those
of
you
that
have
been
following
along
in
the
project
as
a
whole.
D
The
metrics
have
been
in
this
project
in
the
open,
telemetry
sig
for
a
while
the
gosig,
I'm
sorry,
the
ghosting
itself
has
been
the
proof
of
concept
for
a
lot
of
the
metrics
things
that
we've
actually
built
and
and
have
been
somewhat
ratified
into
an
experimental,
sdk
or
sdk
specification.
D
That's
all
getting
a
really
big
facelift.
It
might
be
a
way
to
say
it.
It
might
also
be
that
it's
like
you
know,
a
v2
iteration
is
actually
being
developed.
So
it's
in
the
next.
Not
this
next
hour.
I
guess
it'd
be
two
hours.
D
The
metrics
api
is
going
to
kind
of
just
talk
a
little
bit
briefly
about
like
what
we
want
to
do
in
that
transition
phase,
because
obviously
people
are
using
it
we're
using
it
in
our
contrib
library
and
and
so
like
how
we
want
to
make
that
transition.
Is
it
going
to
be
a
hard
cut?
Are
we
just
going
to
throw
things
out
and
then
say
like
this?
Is
the
last
version
that
this
experimental
you
know,
metrics
implementation
existed
and
we're
going
to
the
next
one?
D
The
long
and
short
is
there's
no
really
good
answer
here,
and
I
know
that
it's
going
to
make
people
mad,
even
though
it's
not
experimental
and
it's
been
listed
as
experimental
and
but
people
are
starting
to
rely
on
it,
and
so
I
think,
there's
going
to
be
ideas
there.
It's
also
going
to
be
brought
up
the
maintainers
meeting
next
monday,
and
hopefully
we
can
get
a
consensus
as
to
what
other
cigs
are
going
to
be
doing
and
maybe
even
better
ideas
as
to
like
what
the
best
process
is.
D
It's
definitely
something
we
want
to
weigh
the
time
to
deliver
the
new
thing
that
everyone
else
is
going
to
be
expected
to
build
versus.
Just
you
know,
making
the
path
between
the
old
thing
and
the
new
thing
somewhat
possible
without
like
burdening
the
maintainers
of
the
project
just
enormously
but
yeah.
I
just
wanted
to
bring
that
up,
because
that's
there's,
no
there's
no
definite
decisions
that
are
being
made.
D
If
you
want
to
be
a
part
of
the
conversation,
show
up
to
the
next
metrics
api
meeting
in
just
a
little
bit
or
the
maintainers
meeting
on
monday.
It
says
maintainers
meeting
everyone's
welcome,
but
you
will
see
all
of
the
maintainers
from
all
the
cigs
there.
So
if
you
have
a
question
for
all
of
us,
we're
there
but
yeah,
I
just
wanted
to
bring
that
up
and
let
everyone
know.
C
That
I
think
that
also
raises
the
potentially
interesting
question
of
what
do
we
do
with
the
metrics
implementations
that
we
have
in
contrib
and
instrumentations
in
this
transition
period?
Do
we
just
yank
them
all
out
and
say
you
know?
None
of
these
metrics
are
going
to
be
available
until
we
have
something
that's
stable,
because
I
think
that
once
traces
go
1-0
we're
going
to
want
to
get
contrib
stable
as
well
and
be
able
to
declare
stability
there.
D
Yeah,
I'm
hoping
to
have
some
direction
from
the
tc
or
from
the
the
project
as
a
whole
as
to
what
that
decision
is
going
to
be,
because
that
is
a
really
important
question.
I
know
that,
like
our
runtime
instrumentation
is
I'm
pretty
sure.
Josh
is
using
that
at
lightstep
right
now.
So,
like
I
mean
it's,
it's
definitely.
I
love
that
instrumentation
when
I
do
play
around
with
things
like
it's
a
really
good
piece
of
tooling,
so
I
I
would
like
a
solution
to
that.
D
Having
a
solution
being
like
well,
we're
just
not
gonna
offer
metrics
for
a
long
time
is
understandable.
It's
not
great.
You
know
it's
you
know
and
like
that
also
might
be.
A
really
good
solution
is
like
the
runtime,
since
it
is
only
a
metrics
package.
D
Just
it
doesn't.
You
know
it
goes
into
a
deprecated
status.
It
doesn't
get
updated
because
the
metrics
pipeline
is
not
going
to
get
updated
or
it's
just
going
to
get
pinned
at
a
version
and
then
all
the
ones
that
are
mixed.
I
then
it
becomes
a
little
more
complex
just
like
maybe
we
just
pull
out
that
from
there
yeah.
I
think
these
are
really
good
questions.
I
definitely
don't
want
to
make
a
decision
on
in
vacuum,
let
alone
too
suddenly
without
getting
some
feedback.
So
yeah
good
point.
D
Well,
cool
yeah!
I
definitely
will
try
to
make
the
metrics
sig
meeting.
I
definitely
have
some
other
things.
I
need
to
get
done
this
afternoon
as
well,
but
otherwise
I
don't
see
anything
else
on
the
agenda.
If
anybody
else
has
something
they
would
like
to
talk
about
any
great
user
stories
that
you
guys
have
come
across
in
the
past
week
or
any
sort
of
cool
experiments.
C
Been
doing
a
hack
week
last
week
decided
so
I'm
noticing
in
the
attendees
list
that
congratulations
may
be
in
order
for
steve,
looks
like
you
may
have
a
new
job
at
a
recently
public
company,
oh
yeah,.
F
We
we
got
acquired
about
six
weeks
ago
and
and
then
coinbase
went
public
yesterday
wow
we
knew
it
was
coming,
but
the
company
name
will
we
just
found
out
we're
going
to
be
called
coinbase
cloud
within
coinbase,
so
the
bison
trails
name
will
go
away
in
the
coming
months.
F
But
but
thank
you.
I
should
make
it
more
accurate
here
in
the
list.
F
But
yeah
it's
exciting,
so
our
own,
our
own,
owning
company
is,
is
a
very
large
customer
of
us,
so
it
becomes
even
more
so
now.
A
D
Awesome,
well,
I
think
if
that's
it
and
nobody
else
has
anything
else
to
have
the
agenda,
I'm
happy
to
get
back
the
next
25
minutes
and
I'm
happy
to
give
back
25
minutes
to
everyone
else.
So
yeah,
hopefully
I'll
see
y'all
later
on
and
if
not
I'll
see
you
virtually
and
hopefully
reviewing
your
prs.
So
talk
to
you
all
next
week.