►
From YouTube: 2021-04-08 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
So
it
looks
like
we're
about
a
minute
in.
Hopefully
you
can
all
hear
me.
Cool
yeah,
awesome,
so
yeah
welcome
everyone
thanks
for
joining,
if
you
haven't
already
be
sure
to
add
your
name
to
the
attendees
section
of
the
agenda,
doc
and
we'll
probably
get
started
in
just
a
few
minutes.
Wait
for
some
people
to
come
in.
If
you
also
have
anything
you
wanted
to
talk
about
any
issues,
guidance
on
or
issues,
you
want
some
more
details
on.
Please
add
it
to
the
agenda.
A
Otherwise
it'll
probably
be
a
pretty
light
meeting
which
I'm
not
opposed
to
either
but
yeah.
I
definitely
want
to
use
the
time
to
help
people
in
the
community.
So
if
you
have
anything,
please
add
it.
A
Cool
it
looks
like
we
might
actually
have
quorum
at
this
point,
so
we
can
just
jump
into
it.
So
again
welcome
everyone.
If
you
are
just
joining,
you
know
what
you're
saying
please.
I
just
helped
this
list
I'll
start
off
by
just
reviewing
some
of
the
projects
that
we
have
open.
A
The
spec
performance
review,
which
has
been
kind
of,
I
don't
know
hanging
on
there.
It
should
be,
I
think,
officially
done
the
last
issue
for
the
zipkin
exporter.
We've
got
a
issue
into
this
specification,
repo
to
change
the
specification,
compliance
matrix
so
yeah.
We
at
this
point
have
updated
or
have
audited
the
entirety
of
the
specification,
and
we
have
some
sort
of
understanding
that,
like
with
the
remaining
issues,
we
should
have
ability
to
release
the
1.0
with
some
sort
of
confidence
that
we
are
implementing
the
1.1
specification.
A
So
yeah
that
sounds
good.
There
may
be
some
like
things
we
have
to
address
in
the
specifications
still.
I
know
one
in
particular
from
last
week
we
kind
of
talked
about,
but
yeah
so
definitely
good.
I
haven't
officially
closed
yet
just
because
this
is
hanging
waiting
for
that
related
pr.
To
close
it,
but
otherwise
yeah
that
should
be
all
done
so
yeah
that
kind
of
goes
on
to
the
actual
rc
open,
telemetry
project
board,
which
is
had
some
great
movements.
A
In
the
past
week,
eight
issues
completed
we've
also
accrued
or
accumulated
a
few
to-do
issues,
so
remaining
still
constant
at
14.
Here,
this
being,
you
know
related
to
that
closing
out
of
the
last
specification
compliance
issue
so
makes
a
lot
of
sense
and
yeah.
I
think
that
I
wanted
to
kind
of
just
touch
on
this.
A
Go
over
a
little
bit
of
the
remaining
issues
that
we
have
here,
one
of
the
things
I
was
kind
of
thinking
about,
and
I
was
interested
to
hear
what
people
on
the
call
had
in
mind
was
we
have
six
issues
in
progress
and
I'd
like
to
maybe
just
go
down
the
list
and
see
if
there
are
people
are
on
the
call
like
current
state
of
the
issues
and
if
you
need
any
help
on
getting
the
blocks,
there's
a
few
of
them
in
here
that
have
definitely
some
links,
pr's
and
maybe
there's
some
understanding
as
to
where
it
is.
A
But
why
don't?
I
kick
us
off
because
someone
suggested
it,
and
so
currently
I
have
this
issue
clarify
package
demarcation
between
sdk
and
the
sdk
export
trace
package
open.
This
has
been
open
for
quite
a
while.
It
is
a
continuation
of
another
discussion
that
came
a
long
time
ago.
We
had
some
people
working
on
the
project
that
are
no
longer
here,
but
yeah.
A
I've
taken
on
this
issue
and
recently
was
able
to
move
the
actual
sdk
export
trace
package
into
the
sdk
thanks
everyone
for
the
reviews
on
that.
The
next
steps
here
are
in
the
process.
We
want
to
try
to
eventually
not
have
the
span,
snapshot,
be
exported
and
just
be
returning.
The
read
only
span
in
all
of
the
interfaces,
as
the
specification
requires
us
to
be
doing,
which
we
are
not
doing,
and
so
we
want
to
be
doing
that
I've
I've
been
playing
around
with
how
we
want
to
actually
approach
this.
A
It's
achievable.
It
definitely
is
achievable.
I'm
trying
not
to
send
a
3
000
line.
Pr
is
kind
of
the
goal
here
and
maybe
also
provide
like
some
utility
here.
One
of
the
things
is
that
if
anybody
who's
working,
the
code
base
for
a
little
bit
knows
especially
on
the
exporter
side
span,
snapshots
use
a
lot
in
the
testing
world.
You
want
to
be
able
to
test,
like
your
exporter
interface,
that
it's
going
to
be,
transforming
things
correctly
or
receiving
things,
not
returning
an
error.
A
So
if
we
don't
have
that
to
be
exported,
I
think
there
needs
to
be
an
equivalent
and
probably
a
more
useful
form
of
the
spam
snapshot
that
would
exist
in
our
trust,
trace
test
package,
and
so
I'm
trying
to
look
at
that
and
trying
to
stage
how
I
want
to
like
set
that
up
the
best
way.
I'm
thinking
right
now,
there's
definitely
like
two
or
three
more
pr's
to
try
to
address
this
and
try
to
digestible
pieces,
but
that's
kind
of
the
goal.
A
B
A
So
the
thing
is:
is
that
it
it's
it's
not
yeah,
it
is,
and
it
isn't
the
let's
just
get
into
it
readable
spam.
That's
it
yes,
so
the
readables
fan
is
what
it
actually
needs
to
return,
and
this
is
something
that
needs
to
be.
Immutable
is
kind
of
the
idea,
and
I
think
that
is
the
the
key
concept
is
the
immutability
of
it
and
that
idea
that
doesn't
actually
change
any.
A
You
know
functional
state
of
what
was
originally
passed
to
it,
and
so
what
we
did
here
is
a
while
ago,
back
in
I
think,
november
of
last
year,
we
added
this
interface
of
this
readable
or
what
we
call
a
read-only
span
and
that
implements
this
additional
span,
interface,
type
and
yeah.
Based
on
that,
in
that
definition,
the
export
interface,
which.
A
May
not
be
here,
I'm
trying
to
think
of
where
it
I
think
it's
I
don't
know
yeah
it
just
needs
to
be
exporting
a
batch
of
these
readable
spans
is
the
idea,
and
so
we,
since
we
have
the
interface.
The
idea
is
that
we're
going
to
be
passing
in
that
span
exporter
and
since
it's
already
moved,
the
idea
was
that,
like
we
don't
actually
need
to
be
exporting.
This
span
snapshot
anymore.
You
just
be
passing
this
band.
The
readable
span,
interface
itself.
B
Okay,
so
it
doesn't
it's
not
trying
to
protect
against
things
like
somebody
down
casting
the
the
interface
to
figure
out
that
it's
underlying
a
span
snapshot
or
something
right.
It's
just
the
functions
that
consume.
We
need
to
hand
it
to
something
that
only
needs
a
readable
read-only
copy
or
we
don't
need.
A
Them
right,
that's
that's
the
correct
idea
there
and
I
think
we've
exposed
a
lot
of
things
in
the
process
of
trying
to
accomplish
just
despite
this
idea,
you
know
this
idea
of
like
we
have
a
snapshot
method
which
isn't
really
specified
anywhere,
but
that
returns
like
the
snapshot
and,
like
you
know
things
like
how
do
you
associate
the
tracer
with
it?
Well,
if
you
pass
the
read-only
span,
it
doesn't
actually
needed
to
be
associating
a
tracer
with
that
anymore.
A
So,
like
things
like
that
start
to
get
a
little
bit
clearer
in
the
process,
so
yeah,
I
think
that
that's
that's
the
goal.
I
think
you
said
it
right.
A
Cool,
if
other
people
have
more
talk
about
it,
definitely
welcome
comments
in
the
issue,
or
we
can
talk
a
little
more
here
pablo.
I
think
I
saw
you
on
the
call.
I
don't
know
if
you
wanted
to
give
an
update
as
to
where
you're
at
on
this
issue
here.
C
Sure
I
have
done
the
http
config
part
and-
and
I
it's
missing
the
jpc,
but
I
am
slow
with
the
hotel
things
this
week,
so
I'm
probably
going
to
open
this
pr
by
monday
or
tuesday
next
week,
but
there
is
nothing
blocking
me
on
this.
So
it's
great,
I
think.
C
A
Yeah
exactly
that's,
you
have
a
quick
eye
on
that
steve
by
the
way
yeah.
So
what
happened
was,
I
think,
is
there's
a
little
bit
of
like
how
do
you
actually
implement.
A
This
question
is
to
like
how
you
specify
a
protocol
and
then
just
assume
that
it's
going
to
create
a
driver
for
you
in
the
process
and
other
sigs
had
that
exact
same
problem,
and
so
what
happened,
I
think
was
the
specification
itself
has
downcasted,
and
so
currently
that
idea
of
the
exporter
protocol
is
is
now
something
that's
not
specified
as
a
required
or
even
recommended
thing,
but
rather
something
that
don't
touch
this
environment
variable
because
it
probably
is
going
to
come
in
the
future.
Is
the
idea.
B
Okay,
yeah,
I
could
sort
of
imagine
an
implementation,
but
I
was
just
wondering
if
you
were
going
to
see
it
here.
It
sounds
like
we're
deferring
it
for
now
yeah
yeah.
I
asked
because
this
need
came
up
for
me
this
week
like
what
this
this
exact
field
would
would
address
if
it
were
implemented.
So
I
was
curious
so.
B
Yeah
yeah
so
right
now,
for
example,
tyler
you
may
have
gotten
wind
of
this
in
your
in
your
regular
job
duties.
So
we
have
programs
that
we've
we've
written
and
they
hard
codes
say
I'm
using
the
grpc
otlp
driver.
You
know
I've
got
a
little
bit
of
flexibility
like
I'll.
Take
the
address
on
the
command
line
that
kind
of
stuff,
but
it
the
program
knows
it's
going
to
talk
grpc
and
then
somebody
says:
hey,
I'm!
I
accept
otlp
over
http.
B
Here's
the
you
know:
here's
the
address,
whatever
my
program
can't
do
that.
I
need
to
re,
rewrite
it
or
augment
it
to
take
additional
flags
to
swap
drivers
and
whatnot,
and
so
this
is
exactly
the
sort
of
thing
where
it
gets
into
the
item
added
to
the
agenda
so
I'll
go
too
deeply
and
do
it,
but
where
how
can
I,
as
program
author,
write
a
program
that
I
could
build
once
and
could
survive
that
kind
of
indecision
until
it's
actually
won.
A
Okay,
yeah,
I
think
it
does
it
does.
It
does
yeah
and
exactly
like
what
you
said.
As
we
tried
to
defer
that
decision,
I
have
ideas,
but
I
don't
think
they're
great.
D
A
Yeah,
that
is
definitely
a
great
solution.
Given
we
are
going
to
be
building
this
in
the
near
future,
but
yeah,
I
think
that's
I
mean
we
eventually
are
going
to
need
to
supply
something
like
this
and
it
kind
of
gets
back
to
exactly
that.
Like
the
collector
solved
this
in
some
ways,
because
at
runtime
you
can
pass
in
a
configuration
and
it
dynamically
will.
You
know
instantiate
all
these
different
receivers,
exporters,
transformers
and
these
kinds
of
things
so
like
it's
definitely
a
solvable
problem.
A
It's
just
like
it's
gonna,
it's
gonna,
take
some
mechanisms
and
a
lot
of
I
think
machinery
to
try
to
hook
this
in
and
yeah
I
haven't,
haven't
looked
too
deep
into
the
problem
space,
but
I
do
know
that
it's
going
to
be
complex,
yeah.
It
just.
B
Yeah,
because
it
could
also,
you
can
imagine
that
if
we
had
a
library
that
you
you
know,
you
constructed
like
construct,
flex,
publisher
or
whatever
it
basically
just
like
sniffs
the
environment,
to
figure
out
what
to
do.
It's
also
compiling
in
a
whole
lot
of
possibilities
into
your
program
that
some
people
might
say.
We
really
don't
want
that
extra
whatever
it
turns
out
to
be.
You
know
two
megs
worth
of
dependencies
being
baked
in.
E
The
reason
why
we
separated
out
grpc
from
everything
else
was
that
dependency
issue
right.
A
lot
of
people
were
like
hey,
I
don't
I
don't
want
to
have
grpc
dependencies.
I
don't
use
it
anywhere,
don't
give
me
all
of
that
bloat
and
to
force
them
back
into
that,
so
that
we
can
have
this
flexibility
would
be
a
regression
in
their
eyes.
I
think
yeah.
A
Yeah-
and
I
think
this
is
a
really
old
conversation,
it
seems
like
I'm
rehashing
a
lot
of
really
old
conversations,
but
this
thing,
I
think,
talked
about
the
specific
issue
in
trying
to
do
something
like
what
the
database
sql
package
does,
where
dynamically
will
load
things
based
on,
like
you
know,
particular
import
statements
and,
like
I
think
steve,
you
were
part
of
that
conversation
where,
like
you
know,
it
was
exactly
that
like
well.
A
This
is
really
complex
and
the
go
authors
tell
you
not
to
try
to
do
something
like
this
in
the
future.
So
again,
like
I
said
a
hard
problem
space
probably
enough
to
address
at
some
point.
B
Yeah
yeah
and
I
thought
about
I
thought
about
what
what
I
would
do
to
implement
it.
It's
just
a
little
bit
sad
that
then
you
imagine,
there's
500
of
these
little
private
infinite
lesions
of
this,
and
I
suppose
you
know
it's
something
we
could
publish
in
a
library
like
a
like
a
contributor
or
something
or
it
sits
above
the
sdk
and
it's
something
maybe
people
could
opt
into
if
they're
willing
to
pay
the
cost
of
the
myriad
dependencies,
it
would
pull.
A
In
I'm,
a
really
big
fan
of
that
in
general,
I
like
the
idea,
because
this
is
this-
is
really
like
a
go
esque
model
of
development
where
you
take
something,
that's
like
you
know,
a
good
idea
in
your
mind
and
you
just
publish
it
to
see
like
if
it's
a
good
idea
for
everyone
else,
and
then
you
know
maybe
make
it
more
universal
or
maybe
you
know
it's
just
a
hit
right
out
of
the
gate,
but
then
once
it
becomes
like
a
super
like
yeah
everybody
wants
this.
A
A
Well,
cool
yeah,
great
discussion,
thanks
for
the
update
on
that,
I'm
not
sure
who's
on
this
one.
E
Yes,
I
didn't
I'm
trying
to
remember
so
I
think
there
was
a
pr
for
this.
It
might
just
not
have
been
linked
as
closing
this
or
it's
still
open.
It
is
yes.
A
This
seems
weird
okay.
This
is
being
blocked
by
me,
which
I
feel.
E
On
your
feedback,
so
don't
be
too
worried.
I
I
think
it's
proceeding.
I
I
just
haven't
chimed
in
with
an
approval,
because
I'm
waiting
for
all
of
your
stuff
to
go,
but
I'm
pretty
sure
that
I've
looked
over
this
and
we'll
be
fine
with
it
once
you
are.
A
Yeah,
if
I
remember
this
correctly,
there
was
only
a
few
small
details
that,
if
they've
been
addressed,
then
this
is
pretty
good.
I've
also
think
been
talking
with
them,
asynchronously
in
generically
cleaning
up
other
parts
of
the
code
base.
That
he's
come
to
the
same
conclusion
that
I
have
you
know.
A
Things
like
the
with
collector
options
are:
don't
need
to
be
exported
and
there's
a
lot
of
cleanup
that
can
be
followed,
so
really
good
work,
and
I
I
felt
bad
for
a
second
there
that
I've
been
holding
stuff
for
10
days
but,
like
you
said
two
hours,
I
think
that
that's
that's
something
I
could
stop
but
cool
yeah.
That
looks
like
it's
almost
complete.
A
Where
are
we
at
on
this
one?
I
think
this
is
this,
I
think
is
done
as
well.
A
Yeah
I've
just
merged
this,
and
I
closed
this
because
I
think
this
superseded.
This
is
cynthia
on
the
call
I
heard
it
heard
somebody
coming.
E
A
A
This
is
drew
wright.
I
don't
know
if
drew's
on
the
call
yeah,
I'm
yo.
F
Hey,
do
you
have
an
update.
G
On
where
we're
at
on
this
one
yeah,
I
just
like
opened
a
pr
yesterday
like
anthony,
had
approved
it
on
our
ord,
and
I
just
opened
the
pr
from
here.
So
I'm
waiting
for
reviews
or
comments
from
anyone
over
here.
E
Okay,
awesome
yeah
this
one
also.
I
I
made
some
inquiries
on
the
on
the
specs
side,
because
I'm
not
sure
what
order
the
environment
overrides
or
supposed
or
divine
resource
information
is
supposed
to
override
the
the
subjects
in
the
code
or
vice
versa.
I
think
that
the
order
that
is
in
the
pr
that
drew
has
is
what
people
seem
to
think
the
spec
was
saying.
I
personally
think
it's
wrong.
I
think
environment
should
override
what's
hard-coded,
otherwise
you
lose
a
lot
of
flexibility,
but
that's
where
it's
at.
A
A
Yeah,
I
I
definitely
have
approved
multiple
pr's
at
this
point,
where
it's
the
opposite,
like
you're,
saying
where
the
environment
variable
is
overridden
by
the
you
know,
specified
configuration
options,
but
now
that
you're
saying
it
out
loud
like
it
makes
a
lot
of
sense,
like
you
have
compiled
code
that
you're
like
this
isn't
operating
the
way
I
wanted
to.
Let
me
just
change
it
at
runtime
with
these
environment
variables
that
you
would
want
those
things
to
take
precedence.
That
makes
sense
to
me
but
yeah.
I
would.
A
I
would
like
to
make
sure
that,
like
we're
not
conflicting
with
what
the
specifications
saying
that,
I
guess
is
a
good
thing:
did
we.
C
B
E
Issue,
I
think
we're
in
line
with
the
with
the
spec,
and
I
think,
there's
also
an
argument
to
be
made
that
in
this
case,
the
resources
that
would
be
overriding,
the
environment
aren't
necessarily
hard-coded
either
they
may
come
from
resource
detectors,
like
you
know,
an
ec2
resource,
detector
or
the
like,
which
may
know
better
than
the
environment.
So
it's
it's
not
a
clear-cut
case.
A
A
Yeah
you're
in
good
company
cool
awesome
drew
thanks
for
the
update
on
that
and
then
last
thing
I
typically
export
only
for
trace.
This
is
a
good
one.
A
Oh,
oh
yep
still
learning
how
to
use
the
field
internet
here.
Brian
is
on
this
one.
That's
right,
I'm
not
too
sure
where
we're
at
on
this.
E
I
think
we
oh
right
he's
got
another
pr
in
our
internal
repo
that
I
have
either
yet
to
approve,
or
we
are
still
waiting
for
something
to
get
that
going
yeah.
I
asked
for
some
changes
from
him
and
it
looks
like
he
has
updated.
E
I
I
will
take
a
look
at
that
and
get
an
approval
on
that
to
get
it
moving
forward
into
the
main
repo
cool.
H
Do
we
have
documentation
that
goes
along
with
that
complicated
behavior?
We
talked
about
last
week.
A
I
would
hope
so
that
would
be
included
in
the
pr,
but.
E
I
haven't
seen:
there's
there's
documentation
of
the
functional
options
that
are
added,
but
nothing
that
lays
out.
You
know
scenarios
and
examples
other
than
the
one
example
that
has
code
that
uses
them.
Are
you
thinking
something
more
along
the
lines
of
a
readme
that
outlines
what
you
would
do
when
that
sort.
H
Of
thing
I
was
as
a
new
user
who
is
grappling
with
open
telemetry
for
the
first
time
it
seems
every
week
it
yeah
something
something
to
explain
this,
a
little
more
more
carefully.
C
A
I
definitely
think
we
try
to
preference
using
godox,
because
that's
what
we've
been
told
is
like
that's
a
primary
source
of
information
for
people
who
are
writing
code.
I
think
this
is
a
great
spot
to
explain
what
would
happen.
You
know
based
on
that
configuration,
but
I
think
also
these,
as
anthony
pointed
out,
the
the
functional
options
could
be.
You
know
used
to
to
save
these
sort
of
things
as
well,
but
when
the
pr
gets
opened
in
our
repo
we
can.
We
can
ask
a
comment
there
should.
E
I
actually
think
we
could
probably
use
a
lot
more
documentation
in
a
lot
of
places
and
knowing
where
people
have
concerns
or
issues
can
help
us
at
least
get
started
and
saying:
okay,
maybe
this
one
here
we
can.
We
can
get
some
better
documentation
on
cool
thanks.
A
Yeah,
I
completely
agree,
there's
I
think,
after
our
rc
release
a
really
good
just
time
to
go
and
audit
all
the
documentation,
because
it's
lacking
and
there
I
think
that
there
needs
to
be
also
some
meta
standards
around
how
we
want
to
structure
our
docs.
I
definitely
have
some
opinions
there
after
having
working
in
this
a
while,
but
I
think
it's
also
really
helpful
to
communicate
those
things
so
yeah,
I
think
docs
would
be
really
helpful
and
having
a
new
user's
perspective
is
really
helpful
as
well
cool.
A
B
B
It's
interesting
to
me
that
we
have
this
hard
split
between
the
api
and
the
sdk,
but
one
of
the
first
things
you
need
to
do
when
you
write
a
program
is
commit
to
particular
uses
of
the
sdk,
so
you've
got
parts
of
your
program
that
only
use
the
api
but
they're
useless.
If
the
parts
that
talk
about
the
sdk
make
the
wrong
decision.
B
So
while
you
could
possibly
publish
libraries
that
only
use
the
api
when
it
comes
time
to
program
construction,
you
lose
all
the
flexibility.
So
it's
just
it's
it's
an
interesting
problem,
and
again
maybe
this
is
solvable
at
the
contrib
layer
or
something
if
nobody's
working
on
something
like
this.
A
Yeah,
I
think
this
might
also
slightly
relate
to
like
the
general
question
at
the
specification
level
is
to
like
the
dynamic
configuration
or
how
you
want
to
configure
an
sdk
and
yeah.
It's
it's
definitely
something.
I
think
that
we
punted
a
little
on
at
the
specification
level.
There
is
a
a
very
small
blurb.
I
think
john
watson
wrote
it
about,
like
you
know
it
at
the
very
bare
minimum.
A
If
there's
going
to
be
a
configuration
layer,
it
has
to
have
an
api,
but
like
do
we
also
want
to
support
yaml
or
json,
or
you
know
what
does
that
api
look
like,
and
how
does
that
actually
configure
the
sdk?
It's
also,
you
know
just
for
the
default
sdk,
so
that's
a
whole
other
can
of
worms.
If
you
come
in
and
say
like,
why
should
I
want
to
use
a
different
sdk,
so
yeah
yeah.
B
A
Yeah,
there's
definitely
not
anybody
in
this
sig
working
on
it
that
I
know
of.
I
definitely
know
people
thought
about
it
at
the
specification
level
and
I
think
at
that
level
it
probably
needs
to
get
addressed.
If
there's
going
to
be
any
sort
of
like
universal
statement,
what
six
should
be
supporting,
but
that's
not
to
say
that,
like
you
know
the
suggestion
you
made
when
you
look
at
something
contributing
something
that
self-hosted
that's
just
like
a
prototype
would
be
great.
You
know
it
could
validate
a
lot
of
assumptions
or
it
could.
E
A
Cool
yeah,
okay,
so
I
guess
with
that
said
like,
if
you
do
make
something,
please
bring
it
back
to
this
group
and
then
we
could
try
to
list
it
on
the
opensource.io
site,
where
we
list
all
the
things.
I
can't
remember
that
right
now,
yeah
they're,
all
just
thank
you,
yeah,
the
registration,
I'm
not.
E
E
A
Want
to
use
the
the
megaphone
of
this
project
to
get
people
to
go.
Take
a
look
at
it.
I
think,
and
then
just
have
that
organic
like
this
is
working
for
us.
So
this
isn't
working
for
us
kind
of
thing.
B
Yeah
because
I
I've
been
through
when
I
look
through
the
my
own
history
on
the
files
in
my
programs
that
I
used
to
initialize
this,
like
I
started
out
with
the
honeycomb
exporter
and
tuned
that
many
times
then
introduced
open.
Telemetry
is
an
option
now.
I've
got
multiple
branches
and
that
you
know
for
different
protocols,
and
so
it's
it's
growing
and
I
can
see
like
I
don't.
I
don't
want
to
include
all
the
vendors
in
there
necessarily
but
can
be
pretty
hairy,
maybe
I'll,
maybe
I'll,
publish
something
I
got
to
see
how
it
goes.
A
Yeah
I
mean
like
the
whole
goal
of
telling
the
tree
is
to
you
know,
remain
vendor
agnostic
and
not
have
that
vendor
lock-in
and
so
yeah
it's
dramatically
reduced
compared
to
like
writing.
You
know
your
vendor's
instrumentation
into
your
program,
but
like
there's
still
a
dependency
overhead,
if
you
do
need
to
include
you
know
this
vendor
for
this
thing,
this
fender
for
this
thing
or
this
open
source
project.
For
this
thing,
like
that's,
not
really
great
either.
A
So
I
hear
you
like
it'd,
be
really
nice
if
you
just
like
generically,
write
a
line
and
then
ad
hoc
in
configuration
or
runtime,
be
able
to
you
know,
set
things
up
right.
Okay,
it's
also
really
hard
for
a
compiled
language
like
us,
but
it's
not.
It's
not
impossible.
A
Cool,
so
I
just
want
to
go
back
to
this,
some
of
the
open
issues
that
we
have
don't
have
owners.
This
is
one
of
the
ones
that
I
kind
of
wanted
to.
E
A
Yeah,
that's
totally
fine.
I
kind
of
figured
as
much
I've
been
thinking
about
it
about
what
to
do.
I'm
not
planning
to
take
action
yet
but
yeah.
I
feel
like
I've
thought
more
about
it.
So
my
name
on
it
then
yeah.
Well,
a
lot
of
this
stuff
is
just
opened
by
me.
I've
got
this
exporter
retries.
I
know
aaron.
You
had
opened
this
one.
C
D
Specification,
so
my
reading
of
the
specification
is
that
they
must
transient
errors
must
be
retried
right
there
yeah,
but
there
are
a
number
of
things
where
we
call
out
that
we
deviate
from
the
the
specification
either
it's
not
implemented
yet
or
we
we
can
or
cannot
do
that
like.
E
That's
putting
my
putting
my
malicious
compliance
hat
on
too
it
doesn't
say
what
the
retry
strategy
has
to
be.
We
can
retry
zero
times.
Well,
we've
got
a
retry
strategy
that
that
does
exponential
back
off
and
as
jitter
just
doesn't
ever
try
again.
It's
max
is
zero.
D
Yeah,
unless
somebody
happens
to
randomly
set
a
an
environment
variable
when
they're
running
the
program.
A
Yeah,
that's
not
great.
Okay,.
E
A
It's
too
late
yeah.
I
tried
this
when
I
was
originally
writing
the
configuration
there
it's
by
the
time
that
it
goes
to
instantiate
the
file,
it's
already
initialized,
all
the
environment,
variables
that
they
can
read
it
from
that
point,
and
you
can't
reset.
I
mean
you
can
reset
it,
but
it's
only
going
to
set
reset
it
in
your
local
scope
is
what's
going
to
happen.
D
A
The
the
other
option
is
this
was
originally
written
at
the
specification
because
there's
some
really
smart
engineers
over
in
the
collector,
which,
if
anybody's
working
the
collector
they've
known
that
pretty
quickly
is
they
wrote
their
own.
They
just
wrote
their
own
exponential
back
off
algorithm
and
they
just
said
like
we're.
Gonna
just
do
this
and
we
could
do
the
same
or
copy
it
or
just
something
like
that.
I
think
it's
also
something
we
try
to
do.
D
I
think
yes,
and
no
like
one
of
the
fundamental
problems,
is
that
you
know
http
once
it's
disconnected.
It's
like
the
transactions
are
kind
of
like
one
shots
and
they're
disconnected,
whereas
there's
a
sentient
connection
stream
manager
in
as
part
of
grpc.
D
So
like
you
can
have
a
connection
and
sometimes
it
gets
disconnected,
but
the
next
time
you
send
a
message
over
the
grpc
link.
It
will
actually
reconnect
silently
underneath
the
hood
for
you.
So
it's
yeah
it's
more
of
a
managed
connection,
and
that
makes
things
trickier.
But
I
mean
tyler
is
right.
There
is
a
retry
algorithm
block
in
the
grpc
code,
they're
in
the
client
code
in
the
collector
we
could
copy
that,
which
is,
I
think,
what
the
561
references
or
1603
one
of
those
one
of
those
references.
A
A
D
So
like
that
is
an
option.
It's
a
messy
option,
because
it's
not
very
clean.
A
Yeah,
but
we
could
do,
and
it
definitely
has
potential
for
puns
which
I'm
never
a
fan
of,
but
I've
written
this
algorithm.
I
think
three
times
and
I'm
not
sure
I
got
it
right
any
of
the
times.
So
there's
always
like
really
hard
corner
cases.
A
A
I
will
keep
it
as
an
open
issue,
because
I
don't
have
the
time
to
commit
to
it
right
now.
D
A
Yeah,
I
think
we're
there
yet
but
yeah
I
hear
you.
E
Cool
yeah,
to
the
extent
that,
to
the
extent
that
it's
a
non-conformance
with
a
spec,
it's
not
something
that
would
break
backwards,
compatibility
to
fix,
so
maybe
we
do
hit
an
rc
or
even
a
1.0,
saying,
hey.
We
know,
we've
got
this
outstanding
defect,
we'll
be
able
to
fix
it
without
breaking
things,
though,.
A
Yeah,
exactly
okay,
good
thing
just
keep
in
mind.
Hopefully
we
can.
H
H
A
Okay,
move
on
to
this
issue.
I
opened
about
clumsy
resource
new
which
people
have
commented
on
and
I
have
not
responded
to.
It
sounds
like
there's
some
ideas
also
here
as
well.
I
think
again
this
just
needs
somebody
to
go
in
and
take
a
look
holistically
at
some
of
these
options.
I
think
when
I
was
looking
at
them.
Originally
they
just
look
kind
of
solution.
Oriented
like
a
solution
was
kind
of
in
mind
when
this
was
written
and
it
may
not
be
the
more
universal
case.
A
So
I
just
wanted
to
have
more
of
like
a
look
at
it.
I
think
there's
some
really
good
suggestions
here.
Again,
don't
have
the
bandwidth
to
tackle
this
right
now,
but
I
think
I
think
it's
there,
but
somebody
wants
to
dig
into
the
problem
space
if
anybody's
interested.
D
A
Well,
I
will
put
your
name
on
it.
No
expectation
on
pr
you're
welcome
to
understand
yourself
at
any
time
as
well
welcome
to
open
source
and
yeah,
but
just
if
you
could,
if
you
do
have
to
understand
yourself,
if
you
do
have
any
like
work
trying
to
capture
in
the
issue,
so
it's
it's
preserved,
cool
thanks,
erin.
This
was
an
interesting
one
that
I
opened
the
ashrae's
package.
We
exports.
A
Where
is
it,
I
think
it's
the
yeah,
it's
the
sortable
yeah.
The
set
itself
is
exported
in
a
way
that
has
a
lock
and
that
lock
is
not
a
reference
or
the
set
itself
is
not
a
reference.
So
what
you're
actually
doing
when
you're
returning
this
value
is
you're
copying
the
value
of
whatever
the
lock
is,
which
is
an
error
in
govet,
given
the
locks
not
blocking
in
any
state
from
the
original
value
anymore.
So,
ideally,
I'd
rather
not
do
this.
A
So
then,
when
people
import
this
package
and
they
use
this
function,
they
get
this
copy
locks
there,
because
they're
using
the
set
it'd
be
ideal.
I
had
some
other
ideas
and
have
solvus.
One
of
them
was
exploring
the
lockless
solution,
so
get
rid
of
the
lock
entirely,
and
I
think
that
was
kind
of
this
person's
idea
to
explore.
So
I
don't
know
what's
going
on
with
the
state
of
that,
I
don't
know
if
they're
on
the
call.
A
I'm
gonna
butcher
that
name
based
out
of
beijing,
so
I
really
doubt
they're
awake
right
now.
Yes,
but
if
you're
watching
the
video
of
this
recording
afterwards.
Definitely
if
this
is
something
you're
working
on,
please,
I
can
assign
this
to
you
as
well.
I
don't
know
if
there's
been
any
movement
on
it.
I
also
was
just
talking
about
it
yesterday.
A
So
yeah,
I
think
there's
some
good
things,
but
again
one
of
the
things
that
that
needs
to
happen
is
people
need
to
explore
it
and
it's
not
something
that
has
a
straightforward
solution.
Again:
development
implement
to
plan
to
extend
interfaces.
I
feel
like
I
might
as
well
just
assign
this
to
me.
Actually,
I
think
you
can
assign
it
to
two
people.
A
Two
people
here
we
go
because
I
feel
like
it's
up
to
us
to
figure
this
one.
E
Out
well,
and
so
I
have
we
come
around
to
the
conclusion
that
this
isn't
necessary
anymore,
at
least
that's
my
kind
of
my
understanding
about
it.
I
recall
we
were
talking
about
this
initially
in
the
context
of
how
do
we
ensure
that
the
api
has
interfaces,
that
we
can
extend
without
breaking
backwards
compatibility,
and
I
think
that
what
we
came
to
in
discussing
with
ted
and
the
spec
group
was
that
the
expectation
is
that
the
api
will
not
break
backwards.
E
Compatibility
for
callers
of
the
api,
but
for
implementers
of
the
api,
like
the
sdk
they're,
expected
to
move
in
lockstep
and
so
adding
a
method
to
an
interface.
Isn't
I
I
mean
it
would
be
a
breaking
change
if
nothing
was
done,
but
our
sdk,
the
default
sdk,
has
to
be
updated
at
the
same
time
anyways.
Otherwise,
none
of
our
ci
is
going
to
pass
well,
we
won't
be
able
to
release
that
broken
or
that
api
that
would
break
it
and
for
any
other
sdk
implementation.
A
Correct-
and
I
think
that's
all
agreed
upon,
but
the
problem
then
is
just
like
do.
We
also
want
to
use
some
sort
of
constructs
of
the
code
to
communicate
this,
and
the
last
thing
is
definitely
document.
The
decision
is
one
of
the
things
that's
actually
needed
to
close
this
issue
out.
So,
even
if
it's
just
like,
we
do
nothing
in
the
code,
we
definitely
need
to
document.
A
But
we
can
also
include
a
private
method,
which
means
they
have
to
embed
the
interface
where
we
can
provide
that
no
op
implementation,
where
they
would
have
to
embed
that
no
op
structure
as
well,
and
I
don't
think
there
was
a
clear
understanding
which
one
wanted
to
go
with
or
or
none
in
that
option.
I
think
that's
all
the
things
we
wanted
to
explore.
E
Yeah,
my
recollection
of
the
discussions,
then,
was
that
that
was
a
less
preferred
option
just
because
of
the
the
overhead
of
dealing
with
it
and
the
experience
that,
for
instance,
the
jrpc
team
had
or
was
the
protobuf
team
had
with
taking
that
bath,
and
they
said
we
wouldn't
do
this
again.
If
we
had
to
so
I
I
would
kind
of
lean
on
that
learning
experience.
E
Do
you
know
where
that's
said?
I
will
find
that
if
it's
not
already
in
that
issue,
but
I'm
pretty
sure
it
was
linked
in
one
of
our
notes
as
well,
so
I'll
take
that
up.
A
Okay,
yeah,
that
that
would
be
helpful
to
see
that,
because
I
think
what
they
were
saying
there
was
the
the
no
op
implementation
is
how
they
solve
it.
So
I'd
love
to
see
like
what
their
thoughts
on
that
one
are.
The
other
option
is
just
to
have
the
one
where
you
input
the
interface
directly
itself,
and
that
would
just
cause
panic
if
the
method's
not
actually
implemented
in
the
sdk.
A
B
But
cool
remember
there
was
maybe
it's
not
here,
but
it
must
have
been
a
related
issue.
I
posted
a
couple
of
links
to
those
the
grpc
design
discussions
about
this.
There
was
like
a
pull
request
in
an
issue
or
something
like
that.
There
was
a
pair
of
them
that
just
went
on
and
on
and
on.
I
could
probably
dig
them
up
again
if
we
can't
find
it.
A
B
And
just
to
clarify,
I
think,
we've
touched
on
this
before,
but
when
we're
worried
about
breaking
implementations.
Is
that
the
case
we're
not
worried
about
people
who
wrote
fakes
or
something
like
that?
Implementations
of
the
interfaces
like
for
their
own
testing.
A
So
this
is
where
I'm
a
little
conflicted,
because
the
open
telemetry
project
does
not
they.
They
have
said
that.
That's
not
something
like
you
just
need
to
remain
in
lockstep
and
like
in
a
you
know,
api
and
sdk.
Like
those
things
just
you
know
version
for
version,
that's
that's
fine,
but
yeah.
That
is
it's
going
to
break
those
sort
of
testing
frameworks.
That's
the
idea,
which
is
again,
I
I
think
it's
like
it
becomes
more
important
for
us
to
provide
useful
testing
frameworks
as
well
as
testing.
A
A
Cool
the
last
one
that
doesn't
have
an
owner
is
this
convenience
function.
I
added
it
to
the
rc
just
because
I,
if
we're
going
to
change
the
function,
signature
on
these
sort
of
things,
it's
going
to
be
included,
I
think
in
the
rc.
So
we
want
to
make
sure
that
that's
not
I
mean
it
needs
to
be
changed
if
it
needs
to
be
changed.
A
A
It
no
worries.
My
idea
is
that,
like
my
understanding,
is
that
like
what's
returned,
it
doesn't
actually
let
you
flush
the
the
tracer
provider,
because
it's
returned
as
an
interface.
Is
my
my
understanding,
yeah.
D
So,
in
a
couple
of
our
exporters,
we
have
a
convenience
function
that
is
like
new
pipeline
or
new
install
pipeline,
or
something
like
that,
where
it
will
take
options
configure
the
pipeline
start
start
them
up,
get
you
going
pretty
quickly
which
are
nice,
and
then
they
return
the
tracer
provider
and
the
control
yeah,
the
tracer
provider
and
a
controller.
The
controller
is,
I
believe,
okay,
but
the
tracer
provider
is
the
interface
the
tracer
provider.
Interface
only
gives
you
a
tracer,
that's
the
only
thing
you
can
do
with
it.
D
If,
instead
of
a
tracer
provider,
we
exported
the
actual
tracer
the
underlying
function,
the
sdkc.
D
Then,
when
you
have
that
in
your
startup,
you
can
actually
capture
that
and
shut
it
down
at
the
end
of
using
it.
The
use
case
I
had
was,
I
was
trying
to
catch
a
few
things.
I
clean
up
right
before
everything
was
shut
down
and
I
needed
to
flush
the
buffers
before
shutting
down,
and
the
only
way
to
do
that
was
to
actually
down
cast
it
into
the
the
case
that
I
had
provided,
which
seemed
unnecessary.
A
Yeah,
I
don't
see
why
we
can't
just
return
the
struct
in
this
situation.
Given
the
fact
this
is
already
importing
the
sdk
trace
package,
it
seems
like
you're
already,
assuming
that
you're
going
to
be
using
the
default
sdk
at
this
point.
There's
no
reason
to
have
that
abstract
backup
to
the
api,
but
I
don't
know
if
anybody
else
sees
a
reason.
Why
not
to
do
that.
E
Yeah,
this
is
in
code,
that's
already
interacting
with
the
sdk
it's
setting
up
an
exporter
right,
so
we
don't
have
to
stick
to
the
api
packages.
That's
on.
On
the
other
side,
we
want
to
grab
a
like
a
global
tracer
provider,
and
then
you
want
that
api
tracer
provider
that
only
exposes
the
tracer
yeah.
You
don't
want
some
random
instrumentation.
Shutting
down
your
export
pipeline
right
right,
right.
A
Yeah,
that
sounds
good
to
me
cool.
I
think
this
might.
D
Go
ahead
yeah!
I
don't
know
if
this
needs
to
be
in
there
for
the
rc,
but
I
can
also
take
a
swing
at
writing
a
pr
for
that,
because
I
think
that
should
be
a
really
quick
pr.
A
Yeah,
I
would
love
that
definitely
a
function.
Change
here
would
be
a
breaking
change,
so
couldn't
do
it
after
the
rc
is.
E
A
Yeah,
so
that's
a
really
important
point
so,
anytime
that
a
function
signature
is
actually
changed,
it
becomes
a
different
type,
and
so,
if
there's
something
else
that
was
actually
like
using
this
as
a
type
and
then
it
is,
you
know
accepting
that
that
type
would
not
match
the
old
value
right.
A
Yeah
where's
that
issue
yeah
yeah.
I
do
think
this
is
also
brings
it
up
once
this
is
getting
a
lot
closer
to
being
resolved.
There's
the
go
release
tool
that
catches
all
these
kinds
of
things.
We
should
probably
build
into
our
release
workflow
to
identify
this
sort
of
thing,
so
yeah.
E
So
that
that
gets
to
something
that
I
started
working
on
in
the
collector,
which
was
using
the
api
diff
library
from
the
go
release
tool
chain
to
identify
breaking
changes
in
an
api.
E
I
think
that,
had
it
had
some
issues
that
would
have
been
problematic
for
this
repo
with
its
proliferation
of
modules,
because
it
expects
you
to
to
work
from
the
top
level
of
a
module.
When
you
want
to
create
an
api
differently
package,
it
doesn't
let
you
specify
hey
just.
Let
me
compare
this
version
of
that
package
to
that
version
of
a
package,
but
I
I
think
it
is
something
that
would
be
good
to
integrate
into
our
tool
chain.
A
Yeah
and
ideally,
we
could
automate
that
as
much
as
possible,
so
it'd
be
included
in
our
ci
system,
so
anybody
who
submits
a
change
can
get
flagged,
not
necessarily
like
stopped
but
just
flagged
saying,
like
you're,
submitting
an
api
breaking
change.
This
is
not
going
to
be
released
until
the
next
major
release.
Kind
of
thing.
E
Yeah
and
and
the
the
api
diff
library,
at
least
from
a
functional
level,
does
seem
to
do
exactly
what
I
would
expect
in
terms
of
catching
the
the
things
that
we
knew
had
been
breaking
changes
since
the
last
release
of
the
collector
it
it
flagged
all
of
those.
So
if
we
can
figure
out
how
to
automate
the
invocation
of
it,
I
think
it
would
work
for
that
purpose.
A
That
is
all
I
had,
which
is
pretty
impressive.
Given
I
had
one
line
here,
it
took
pretty
much
the
entire
time
not
to
toot
my
own
horn.
Here,
I
guess
but
cool.
I
guess,
there's
something:
ideal
review
law.
A
Yeah,
exactly
this
meeting
will
continue
until
fun
is
had,
is
how
I'm
gonna
run
these
meetings
from
now
on
yeah.
I
think
that
sounds
exactly
like
what
I've
turned
this
into.
So
with
that
in
mind,
are
there
any
cool
customer
stories
or
anything
else
that
anybody
else
wanted
to
bring
up
before
we
closed
out.
E
E
A
Yeah,
I
agree:
yeah
thanks
everyone
from
all
the
contributions
to
just
becoming
part
of
the
community.
So
it's
all.
A
I'm
going
to
make
this
long
and
awkward
as
much
as
I
can
before.
Somebody
else
comes
up
with
an
idea,
but
I
think
you
all
really
want
your
four
minutes
back,
so
I
guess
I'll
end
it
there
well
cool
thanks
everyone
for
joining.
I
really
appreciate
it.
I
appreciate
everyone
humoring
me
and
going
through
overall,
these
issues
are
really
helpful
and
making
sure
that
we
have
some
plan
going
forward
and
getting
to
this
rc.