►
From YouTube: 2021-02-25 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
A
A
B
Bye
can
wait
a
few
more
minutes
see
if
anthony
is
going
to
be
able
to
join
today
and
get
started
then,
but
in
the
meantime,
as
always,
please
add
yourself
to
the
attendees
and
if
you
have
anything
you
want
to
talk
about
on
the
agenda,
please
add
it
there.
B
B
Yeah,
I
guess
I
guess
we
could
probably
get
started
at
this
point.
Hopefully
people
who
are
still
joining
can
you
catch
up?
Let
me
share
my
screen
jump
into
it.
B
Cool
so
welcome
everyone
thanks
for
joining
the
meeting,
like
I
said
just
a
little
bit
ago,
if
you
are
on
the
meeting,
please
I
just
left
to
the
attendees
list
and
if
anything
you
wanted
to
talk
about,
please
add
it
to
the
agenda
pretty
light
currently,
but
we
can
kind
of
jump
into
it.
My
goal
here
was
to
start
off
by
just
kind
of
triaging
some
issues
that
have
come
in.
If
anyone,
I
don't
know
we'll
see
if
this
works.
B
I
don't
actually
think
there's
anything
from
an
open,
telemetry
contrib,
but
these
have
come
in.
I
guess
one
of
them
came
out
a
while
ago.
I
just
slipped
by
last
week.
B
B
It
sounds
like
a
really
familiar
pair
that
I've
seen
before,
but
want
to
make
sure
that
we
add
anything
we
need
to
to
the
agenda,
I'm
sorry
to
the
milestone,
but
otherwise
this
is
metrics.
B
B
I
will
leave
that
underneath
to
triage
going
up
default.
Gls.
B
Looks
like
steve
you've
read
this:
do
you
have
any
context
on
this.
D
Yeah
it
that
this
may
have
come
out,
there's
been
a
lot
of
discussion
over
in
the
honeycomb
slack
team
recently
about
me,
included
people
fumbling
around
trying
to
get
the
the
grpc
driver
to
work
correctly,
and
I
think
that
the
the
examples
maybe
didn't
illustrate
correctly
that,
especially
when
talking
to
honeycomb,
for
instance,
you
can't
use
the
insecure
option.
You
have
to
configure
it
with
strangely
empty
client
credentials.
So
in
other
words,
it's
fine
to
tell
it
just
use
the
system
cert
pool
to
trust
the
server,
don't
send
any
client
credentials.
D
But
if
you
don't
do
that,
your
program
just
fails
and
no
error
ever
comes
back
up
out
of
the
the
driver.
It
basically
buries
the
error
and
just
says
it's
not
connected,
so
there's
a
push
to
improve
the
documentation,
and
I
think
that
I
see
him
on
the
call
right
now,
but
anthony
had
even
suggested
that
maybe
we
just
make
this
the
default
behavior.
D
But
so
I
just
commented
here
because
the
the
example
code
up
top
that's
written
is,
is
even
more
verbose
than
need
be
the
whole.
The
whole
acquisition
of
the
system,
cert
pool,
isn't
isn't
necessary.
There,
but
there
are,
you,
know
one
or
two
lines
that
need
to
be
added
in
order
to
make
it
work
in
most
cases,
I
think.
F
I
think
the
question
was
whether
grpc
had
reason
for
making
the
default
not
to
use
the
system
cert
pool
and
if
making
the
system
circle,
the
default
would
be
going
against
that.
For
some
reason
I
don't
know,
I'm
I'm
not
terribly
familiar
with
grpc
as
a
protocol,
so,
but
I
do
think
it
probably
would
be
more
convenient
for
our
users
to
be
able
to
use
the
system
circle
by
default.
That
seems
like
a
reasonable
expectation.
D
Yeah
grpc
is
peculiar
here
there
are,
so
there
are
the
it's
using
functional
style
options,
but
at
least
one
of
them
is
required.
You
either
need
to
pass
with
insecure,
or
you
know
some
flavor
of
the
whatever
it
is
with
the
with
the
credentials
or
something
like
that.
If
you
don't
supply
at
least
one
of
them,
although
I
think
they're
mutually
exclusive,
it
also
just
fails,
but
it
buries
the
error
and
you
you
won't
be
able
to
find
out.
Why.
B
Okay,
so
just
for
the
sake
of
triaging
right
now,
we
can
probably
come
back
to
this
if
we
want
to,
but
would
you
guys
say
this
is
something
that
we
need
to
get
done
before
the
rc,
or
is
this
something
that
we
could
resolve
after
the
fact.
D
D
I
know
you
know
like
I
said
it
was
a
big
waste
of
time
for
for
me,
but
so
I'd
like
I'd
like
it
to
be
fixed,
but
I
don't
think
that
it's
anything
that,
like
I
said,
will
break
anyone's
program
after
the
fact.
If
we
fix
it.
F
And
that's
part
of
why
I
say
it
would
be
good
to
have
it
fixed
before
the
rca,
because
I
would
expect
once
we
announce
the
rc,
then
there's
going
to
be
a
new
influx
of
people
coming
along
and
using
it
and
they're
probably
going
to
run
it
us
into
the
same
wall
right
so
either.
We
need
to
clearly
document
how
to
deal
with
it
or
adjust
the
default
so
that
it's
not
surprising.
A
F
Post
rc,
I
think
if
the
code
change
is
going
to
be
significantly
more
complex
than
the
documentation.
Yes,
that's
an
approach
we
could
take.
My
hope
is
that
the
code
change
is
fairly
simple
and
we
do
both
straight
up
front,
but
I
I
haven't
looked
at
it
to
see
how
complex
that
might
be.
B
Okay,
this
all
sounds
good,
should
we,
it
looks
like
there's
an
open
pr
for
this
anthony.
Did
you
you?
Oh
oh,
this
is
the
collector
okay.
Did
we
have
an
owner
for
this
or.
E
F
I
I
think
we
can
leave
it
for
now:
okay,
yeah.
We
think
that
we
should
get
an
owner
on
at
least
updating
the
documentation,
but
I
think
there
are
some
structural
things
we
have
to
get
addressed
first,
so
this
is
probably
p2.
B
B
Cool,
and
so
it
looks
like
the
last
one,
I
think
we
have
aaron
on
the
call.
A
So
I
was
adding
the
hdp
json
and
I
ran
into
this.
I
know
this
has
been
brought
up
previously
and
might
have
been
brought
up
in
the
collector
space,
but
currently
it's
using
the
gogo
protogen
instead
of
the
google,
the
big
issue
there
is
gogo,
isn't
quite
yet
planning
to
go
to
the
version
two
of
the
protobuf
or
the
grpc
api.
A
It's
a
lot
of
work.
They
don't
have
the
manpower
for
it.
My
concern
is
yes,
the
go-go
is
faster,
but
we'll
also
lose
the
future
features
of
like
reflections
like
server-side
reflections.
I
guess
that's
not
as
much
of
a
concern
here,
but
are
there
any
metrics
that
people
want
to
see
that
would
prevent
us
from
moving
from
gogo
to
just
the
basic
go.
B
That's
a
good
question.
I
think.
Oh
okay,
you
have
this
on
the
agenda
to
talk
about
yourself,
I'm
looking
to
punia
and
david
today,
I'm
expecting
they
have
more
of
an
understanding
here,
but
I
mean
obviously
like
I
know
bogdan
has
talked
about
in
the
past.
There's
like
just
a
performance
metric
for
showing,
like
you
know,
throughput.
B
Overall
latencies
for
packet
size
or
something
like
that,
but
I
I
don't
know
anything
in
particular.
I
also
don't
know
how
particularly
like
it's
that
critical
for
us.
We
don't
have
a
very
complex.
Oh
I
guess
we
do
right
because
we're
using
those
tlp
and
that's
the
whole
thing.
I
don't
know,
that's
a
good
question.
B
Yeah
go
go
here,
so
that's
a
good
point.
I
think
that
also
you're
involved
in
the
conversation
to
moving
on
to
the
the
protogen
repo
itself
would
be
ideal
and
we
could
probably
have
that
unified
in
the
discussion
there,
but
I
think
that
whatever
we
do,
there
should
probably
be
decided
by.
You
know
things
that
you're
kind
of
talking
about.
I
think
that's
really
important.
C
Yeah
ty
hi
tyler,
you
you,
you
asked
about
sort
of
what
kinds
of
performance
things
to
measure
and
I
wonder
if
we
should
be
thinking
about
performance
just
as
like
performance,
we're
measuring
not
for
the
purposes
of
deciding
on
this,
but
just
in
general,
like
what
are
the
performance
metrics
that
we
care
about
what
are
the
baselines
and
then,
whether
it's
this
change
or
some
walking
change
somewhere
else.
C
You
know
we'll
know
what
to
do.
I
I
might
be,
I
might
be
hyper,
focused
on
the
release
right
now,
but
I
guess
I'm
wondering.
Are
we
considering
doing
this.
C
B
I
don't
think
we
have
to
I,
you
know
it
it's
a
kind
of
a
blocker
for
a
lot
of
people
when
they
try
to
use
the
otlp
with
any
sort
of
like
constructs
within
our
ecosystem,
because
they're
compiled
in
two
different
projects
and
so
they're
not
compatible
and
they're,
not
overlapping,
but
that's
something
that
we
can
resolve
after
the
facts,
and
I
think
that
sounds
like
you
know
positive
direction.
I
don't
think
it's.
I
think,
that's
backwards
compatible,
given
the
fact
that
we
hide
our
compilation
of
the
otlp
and
our
internal
project.
E
B
So
I
think
that
we
could
probably
do
this
after
the
fact
is
my
understanding
aaron,
I'm
interested
what
you
think,
though,.
A
Yeah,
because
we
could
do
this-
probably
up
until
there's
a
a
stable
release
of
the
proto-go
repository
that
might
be
a
breaking
change
going
from
which
we'll
call
it
from
from
gogo
to
the
new
api
version.
Two.
A
Yeah,
sorry,
I
haven't
looked
at
this,
yet
I
just
know
yeah.
I
I
just
put
that
in
this
is
to
actually
add
the
http
json
from
the
last
meeting.
No
in
the
hotel
proto
go
there's
the
number
one
pr
for
that
right
and
I
believe
the
current
generation
is
using
just
the
go
generator.
C
C
C
It's
hard
to
get
an
old
version
of
of
pro
of
protocan
go.
B
A
A
little
overwhelming
realistically,
I
think
the
choice
here
is
sticking
with
gogo
and
that's
just
biting
the
there
is
a
there
is
a
potential
performance
gain
from
gogo?
I
don't.
I
haven't
actually
compared
the
two
but
you're
stuck
on
a
particular
api
version
versus
moving
to
the
google
supported
version,
which
is
the
new
api
which
has
new
features,
potentially
new
performance
improvements.
A
And
I'm
not
even
sure
what
we
care
about,
in
particular
with
regards
to
like
what
throughput
or
or
whatnot,
so
whether
or
not
that
change
going
from
where
we
are
now
to
the
new
stuff
would
be
even
if
it
is
like
whether
or
not
it
will
be.
A
a
performance
hit
is
essentially
what
I'm
asking.
B
Yeah,
so
that's
going
to
be
really
important
when
we
go
to
the
the
open
source
reporter
to
go
repo,
because
the
plan
in
my
mind-
and
I
haven't
confirmed
the
collective
people-
is
to
eventually
have
the
collector
also
support
this
and
they're
really
critical
on
performance.
I
know
that
tigran
specifically
is
really
critical
on
performance,
a
lot
of
other
people
in
the
project
over,
and
so
I
think
that
one
of
the
big
things,
if
I
remember
correctly,
is
there
one
of
implementation
in
go,
go
proto.
B
It
was
not
too
bad,
but
then
in
the
base.
Grpc
libraries
like
it
was,
is
not
highly
optimized
implementation,
and
I
know
that
josh
had
talked
about
writing
like
their
own
serialization
of
the
protobuf,
for
that,
like
one-off
method,
which
all
sounded
like
greek
to
me.
B
But
it
sounds
like
it's
possible
to
make
that
I
don't
know
like
if
there's
any
limitations
by
going
to
that
new
v2
api
and
grpc
library
or
not,
but
I
think
it's
I
don't
know
it's
kind
of
like
one
of
those
things
where
I
I
just
would
like
to
put
or
some
of
those
other
collector
people's
input
to
find
out
about
that.
One.
B
Okay,
cool
yeah:
maybe
we
could
also
get
t
yeah
he's
super
overloaded
right
now,
so
he's
really
good
at
this
kind
of
stuff
cool.
I
definitely
run
way
over
that
time
box
that
I
initially
set
up.
I
don't
know
if
we
have
too
much
more
okay.
We
definitely
have
some
more
stuff
to
talk
about,
but
I'm
gonna
keep
going
over
that
timeline
just
because
I
think
we
can
still
fit
in
the
rest
of
the
agenda.
There
is
one
issue
here:
otp
export
traces.
F
Anthony
yeah
yeah
yeah
this
one.
I
think
we
want
to
ensure
that
we
get
fixed
before
ga,
because
it's
currently
panicking
if
the
user
does
a
thing
that
seems
like
it
might
be
sensical,
but
probably
really
doesn't
actually
make
sense.
So
I
think
vladimir's
concern
here
is
that
if
you
want
to
only
configure
an
exporter
for
traces
he's
he's
seen,
you
know
the
split
driver,
presumably
in
the
dock
somewhere
and
he
figured.
F
I
should
just
provide
a
trace
driver
for
it
and
it'll
just
export
traces
which
in
that
case
you
actually
just
want
to
use
the
grpc
driver
directly
in
the
exporter
and
only
put
the
exporter
on
a
trace
pipeline.
But
this
is
panicking
here
and
we
shouldn't
have
it
do
that
so
either
we
should
have
the
new
split
driver
give
an
error
when
you've
got
an
incomplete,
config
or
log
errors
if
it
actually
tries
to
use
an
incomplete
config.
Something
of
that
sort.
B
It
sounds
reasonable
to
me:
do
we
have
an
assignee
that
we
can
assign
this
to?
Is
somebody
working
on
vr,
for
it.
F
Not
yet
this
just
came
up
in
the
last
day,
I
think
so.
Okay,
I
have
just
looked
at
it
to
comment
on
it.
B
This
looks
pretty
straightforward
to
be
honest
if
the
small
one,
if
someone
wanted
a
small
task
to
pick
up,
but
I
also
understand
people
love
other
things
too.
B
D
A
quick
question
which,
just
if
you're
this
question
of,
if
you're,
creating
a
split
driver
and
half
of
it's
disabled,
should
it
just
I
don't
know
like.
I
guess
I
guess.
If
you
call
new
split
driver,
you
expect
to
perceive
a
split
driver
but
almost
seems
like
it
should
just
fall
back
and
you
know
hand
you
back
the
driver,
there's
no
splitting
happening.
F
Yeah,
but
then
that
would
be
contrary
to
the
expectations
of
this
is
only
going
to
handle
traces
right
yeah.
So
I
I
think
the
the
right
thing
is
probably
just
to
complain
loudly
somewhere,
whether
that's
in
logs
or
by
returning
an
error
at
the
appropriate
spot,
so
that
someone
knows
that
they've
probably
misconfigured
it.
B
Okay,
we'll
let
that
one
sit
on
there.
It
still
doesn't
have
an
owner
in
a
week,
I'll
pick
it
up,
but
otherwise
we
can
move
on
in
the
agenda.
I
think
aaron.
We
talked
about
this
task
here
for
using
google
proto,
I'm
not
mistaken.
A
Sorry,
my
audio
is
copping
out.
Yeah
we've
covered
that
okay
cool.
B
Yeah,
I
just
completely
jumped
over
to
try
to
get
one
yeah
sorry
about
that
yeah,
so
it
definitely
seems
like
we
need
to
release.
We
have
a
pretty
decent
sized
change
log
at
this
point,
and
I
think
that
there's
some
pretty
good
things
in
there.
I
don't
know
if
anybody
else
had
anything
they
wanted
to
get
yeah,
there's
definitely
stuff
in
there.
B
A
lot
of
good
fixes
anything
else.
I
wanted
to
get
into
the
release
before
we
made
the
release.
I
was
hoping
to
get
something
like
this
updated
I've
added
some
compatibility
testing
for
our
ci
talk
a
little
bit
about
this,
the
idea
here
being
that
currently
our
ci
is
testing,
go
1,
14
and
115
against
justin,
but
two
bills
on
amd
64
servers,
but
then
it
also
runs
a
build
with
386
machine
code
as
well,
but
like
on
everything.
So
what
this
does
is
it's.
B
It
splits
out
all
the
the
testing
into
a
lint
step,
a
race
detector,
step,
a
coverage,
ci
test
step
and
then
a
compatibility
test
matrix
and
the
compatibility
test
matrix
goes
across
ubuntu
mac,
os
and
windows
builds.
It
goes
across
x8664.
Well,
actually,
no,
it's
amd64,
so
I
guess
steve
over
over.
There
is
going
to
correct
me
on
which
machine
code
classification
that
is
and
then
386
as
well.
It
doesn't
do
arm
because
github
actions
doesn't
support
arm
without
us
building
our
own
test
runners.
B
Unfortunately,
so
I
leave
that
as
a
challenge
to
the
reader,
and
by
that
I
mean
I
don't
know,
we
can
address
that.
I
think
after
the
fact,
this
did
uncover
a
lot
of
bugs
in
trying
to
get
this
pr
up
in
our
testing
suite
that
I
mean
it
was.
It
was
failing
to
compile
on
windows.
That
was
a
big
one,
so,
like
there
was
some,
I
think
we
should
probably
do
something
like
this,
and
so
it
does
include
a
lot
of
that.
B
B
Well,
actually,
no,
I
guess
six
chances
to
fail
because
we're
on
the
test
multiple
times
on
the
other
ones,
but
it's
it's
a
little
bit
more
likely
that
it's
going
to
fail
because
we're
adding
the
compatibility
test.
So
I
think
it's
more
important
that
we're
pretty
diligent
on
trying
to
resolve
any
sort
of
outstanding
bugs,
which
is
not
a
bad
thing,
but
it.
B
Even
though
it's
testing
more
it's
about
the
same
testing
time,
given
the
fact
that
windows
tests
seem
to
be
going
really
slow
for
some
reason,
so
they
take
about
seven
minutes
in
total
but
like
if
you
could
pull
those
out,
this
thing
would
be
done
in
half
the
time,
so
just
sell
its
phrases.
I
guess
one
of
the
other
goals
was
to
try
to
speed
this
up,
but
yeah.
B
And
then
I
updated
a
lot
of
the
the
make
file
to
make
it
a
little
more
easy
to
read
and
convenient.
Hopefully
I
didn't
go
too
over
the
edge
on
them,
but
yeah.
If
you
have
some
time,
I'd
love
to
get
a
review
on
that
and
we
can
get
that
out
for
their
release.
Otherwise
I
don't
know
if
anybody
else
sent
it
to
the
pr
as
they
wanted
to
get
out
for
this
release
that
we
can
get
done
today
or
today
or
tomorrow.
C
Tyler,
thank
you
for
doing
the
compatibility.
Yes,
that's
really
cool
and
I
saw
the
windows
work
going
in
as
well.
That
was
awesome.
I
did
want
to
ask,
go
116
is
out,
and
I
know
the
matrix
is
big,
but
do
we
want
to
add
it
at
some
point
and
what
sort
of
policy
do
we
want
to
have
like
for
our
treelink
version,
support
window
yeah.
B
B
At
this
point
I
kind
of
want
to
keep
it
at
14
and
not
bump
that
forward.
I
don't
I,
I
think
there
are
some
small
differences
in
15
that
are
like
additions,
that
14
doesn't
have
and
the
reason
behind
that
is
just
any
sort
of
adoption
right
now
that
we
have
for
anybody
who's
using
14.
If
we
do
switch
to
15,
we
lose
that
adoption,
and
I
think
that
we
have
like
enough
of
like
a
cohesive
strategy
there
to
not
like
have
a
really
hard
time
backwards,
compatible
supporting
14..
B
I
do
think
we
should
be
testing
16
as
well.
That's
a
good
idea.
I
just
didn't
add
it
here,
because
I
I
wanted
to
start
start
with
what
we're
doing,
rather
than
adding.
E
B
C
Totally
reasonable
and
the
other
question
is,
you
know
the
the
version
that
we
would
release.
This
would
not
be
the
rc
yet
right,
because
there's
still
there's
still
stuff
left
for
the
rc.
C
So
I'm
sorry
I
keep
asking
this,
but
how
far
do
we
think
we
are
from
the
rc?
I
know
there's
13
issues
but
just
in
terms
of
you
know
ownership
and
which
things
seem
hard
does
it
seem
like
we
would
get
to
the
rc
like.
So
I.
F
Think
that
gets
to
the
the
next
issue
on
the
agenda,
which
is
the
spec
compliance
review.
One
thing
I
wanted
to
get
done
before
this
meeting
but
didn't
was
to
create
two
issues
to
go
through
each
of
the
areas
of
this
spec
compliance
divide
those
up
and
have
people
go
through
and
ensure
that
we
are
either
conforming
with
a
spec
or,
if
we're
not.
F
We
have
issues
addressed
to
to
address
that,
and
I
know
that
there
are
you
know
just
from
the
work
I've
been
doing
with
spam
contexts
recently,
there's
some
probably
significant
changes
that
are
gonna
have
to
be
made
around
that
that
I
don't
think
we
have
issues
for
I
don't
know
if
there's
anything
else
significant
out
there,
though,
but
that's
why
we
have
to
go
through
that
exercise
of
going
through
the
spec
and
comparing
it
side
by
side
with
our
implementation
to
see
how
close
we
are,
how
far
we
are.
F
What
what's
currently
listed
here
on
the
spec
compliance
matrix
for
go,
I
think,
is
fairly
outdated.
So
we
we
just
need
to
start
from
a
blank
slate
and
go
through
each
of
these
and
say:
do
we
do
this?
Yes,
no
is
it?
Is
it
in
line
with
this
back?
Yes,
no
great.
B
Yeah
and
if
it
isn't
link
the
issue
that
is
going
to
resolve
that
you
know,
I
think
that's
the
thing
yeah
anthony
we're
talking
about
this
earlier
in
the
week,
so
I
think
that's
kind
of
a
cool
idea,
so
the
plan
is
to
create.
B
I
don't
know,
maybe
even
like
a
a
project
board
for
this,
for
just
a
bunch
of
issues
to
go
through,
and
you
know
systematically
review
each
one
of
these
things
by
reading
the
specification
making
sure
we
implement
it
and
then
updating
the
matrix
or
creating
an
issue
and
updating
the
matrix
and
updating
that
you're
saying
we
don't
actually
support
or
something
like
that
right
now,
I
think,
is
the
idea,
because
then,
at
that
point
we
knew
we
would
have
a
lot
more
confidence
with
the
fact
that
all
the
issues
that
are
in
the
rc
are
going
to
actually
be
the
implementation
of
the
specification.
C
Makes
sense
makes
sense,
is
that
so
is
that,
like
is
one
of
you
already
planning
to
do
that?
Should
we
do
that,
like
is,
should
we
have
like
another
mini
breakout
to
do
that,
or
is
someone
going
to
just
work
on
it
individually?
So.
F
I'm
going
to
create
issues
for
probably
each
of
these
high
level
areas
that
are,
you
know
the
linked
issues
that
are
linked
segments
in
the
spec
matrix,
and
then
I
would
expect
we
could
probably
distribute
them
asynchronously
through
slack
or
whatever
right.
Do
it
in
kind
of
a
kanban
style.
F
B
F
Right
I'll
get
started
on
that
this
afternoon
and
if
it
looks
like
it's
going
to
take
far
too
long,
then
I'll
yell,
okay,.
B
C
Do
we
have
some
like
when
we
create
these
issues?
You
know
the
the
ask
for
each
issue
is
verify
or
fund
verify
or
find
a
counter
example
right.
F
C
Got
it
now
I
had
this,
I
had
an
idea,
I
think,
like
vaguely
stated
previously,
and
I
wanted
to
ask
if
this
is
something
we
could
adopt
in
order
to
resolve
the
each
issue.
Could
we
say,
hey
you
need
to
write
a
you
need
to
write
a
passing
or
failing
test
that
captures,
that
line
that
line
of
the
spec
and
and
in
some
cases
you
know,
you'll
have
something
that
doesn't
compile,
so
you
could.
C
F
Think
I
like
the
idea
of
being
able
to
have
a
test
suite
that
validates
spec
compliance.
I
would
hope
that
many
of
our
tests
are
already
asserting
those
things,
so
maybe
it's
a
matter
of
selecting
which
tests
should
be
run.
To
do
that.
I
don't
know
the
best
way
to
go
about
doing
that,
though.
My
only
concern
with
with
doing
that
would
be
if
it
adds
significant
time
to
getting
through
the
compliance
and
validation.
F
That's
totally
fair,
so
I
I
don't
know
I
would
say
that's
definitely
a
nice
to
have.
I
would
love
to
have
it
and
if
you
want
to
start
exploring
what
it
would
take
to
build
up
a
framework
for
doing
that,
that
would
be
a
an
excellent
effort
I
think
to
start
undergoing.
I
just
want
to
make
sure
that
we're
not
in
doing
that
pushing
out
the
the
rc
farther
than
we
have
to.
F
A
My
concern
there
is,
it
might
get
out
of
date,
but
like
that's
where
we
can
start
building
our
domain
knowledge
of
like
this
is
the
test
that
does
that.
B
Yeah,
this
is
the
test.
That
does
that.
I
think
that's
an
interesting
point.
I
really
like
both
of
those
ideas
I
had
originally
like
wanted
to
do
some
sort
of
inventory
here,
where
you
know
you
see,
create
a
trace
provider
there'd,
be
a
link
that
would
show
that,
but
I
think
that,
like
that
from
puny's
standpoint
like
it
has
a
really
good
idea
to
build
this
into
code.
So
if
it's
in
like
the
tests,
because
then
it
says
current
and
there's
not
really
like
it
won't
compile.
B
If
that
like
gets
out
of
sync
or
something
like
that,
and
at
the
same
time
like
documenting
like
where
those
tests
are,
I
think
it's
a
really
helpful
thing
versus
the
link
to
documentation
or
something
like
that
is
guaranteed
to
be
stale
once
the
next
version
comes
out
so
yeah
these
are
really
good
suggestions.
B
I
would
love
to
maybe
do
like
a
little
proof
of
concept
of
this
to
see
just
how
long
it
would
take,
because
I
think
that's
a
really
valuable
thing
to
tackle.
C
F
Cool
one
more
thing:
psych
migration
feedback
yeah,
so
I
just
wanted
to
get
a
sense
from
people
how's.
The
slack
migration
going
when
I
added
the
github
integration.
Is
that
two
verbose?
Any
issues
with
that?
I
don't
know.
I
sometimes
worry
about
conversations
getting
lost
in
new
issue
new
pr,
but
I
think
it's
also
helpful
to
see
when
things
come
up
and
when
things
are
addressed.
C
I
like
those
issues,
so
I
I
think
if,
if
you're
so,
I've
been
I've
been
at
sick
meetings
and
so
on
for
a
couple
of
weeks,
and
so
for
me,
I
didn't
feel
intimidated
by
trying
to
start
a
conversation
with
all
the
with
all
the
github
issues
it
was.
It
was
good
to
know
it
was
good
to
kind
of
give
me
ambient
knowledge
of
what
was
going
on.
I
could
imagine
a
newcomer
being
a
bit
more
overwhelmed
and
I
guess
maybe
we
should.
C
F
I
think
you
do
the
thing
about
that
is.
If
someone
is
intimidated,
they
may
never
speak
up
unless
you
may
never
know
that
they've
been
intimidated
and
so
yeah,
that's
definitely
a
fair
point.
Okay,
I
suppose
the
thing
we
can
watch
out
for
is
a
dog
that
doesn't
bark.
If
we
don't
see
new
people
chiming
in
maybe
we.
B
B
B
Yeah,
I
see
it
both
ways.
I
like
everything
in
one
place,
and
I
also
like
it
to
not
be
cluttered
so
can't
win
them
all.
Yeah.
C
F
Yeah
I
mean
so
I
think
if
we
did
do
a
bot
channel,
a
good
compromise
would
probably
be
to
have
the
main
channel
announce
things
like
releases
and
everything
else
go
into
a
bot
channel.
B
Well,
cool,
I
think
that
might
be.
That
is
everything
from
the
agenda.
If
anybody
else
had
any
other
topics,
they
wanted
to
discuss
or
questions
about
the
project
or
anything
like
that
happy
to
answer.
D
Anthony
I
was
reviewing
your
immutable
span
context.
Pr.
I've
got
a
few
questions,
but
I
can
I
can
write
those
there.
F
Sure-
or
I
mean
I've
got
time
now,
if
you
want
to
go
over
them,
we
don't
need
to
keep
everybody
on
for
that,
but
anybody
who's
interested.
We
can
talk
about
it
now
too,.
B
So
maybe
maybe
we
could
jump
into
that,
but
the
last
question
I
wanted
to
ask
before
I
cut
it
was
if
there's
any
other
good
user
stories
that
anybody
had.
I
know
josh
had
shared
one
a
while
ago.
It
was
pretty
exciting,
but
I
don't
know
if
anybody
else
has
any
other
like
they've,
been
using
the
project
and
had
some
cool
successes.
D
I'll
say
that
apropos
something
I
brought
up
last
time,
I
did
go
and
grab
sam's
sql
instrumentation
package
and
started
using
it,
and
it
worked
straight
away.
Oh
cool,
that's
really
really
good
to
see,
makes,
makes
using
hotel
a
lot
a
lot
more
useful
for
something
that
I'm
working
on
this
xm.
B
Cool
nice
yeah
super
unstable
yeah.
We
love
it
hasn't
changed
in
three
months,
so
yeah
but
cool.
I
think,
that's
probably
all
for
the
day
I'm
gonna
drop
off,
but
yeah
anthony
and
steve.
You
guys
want
to
hang
out
and
talk
a
little
bit
more.
That
sounds
like
a
good
idea.
Everyone
else.
It
was
awesome
to
see
you
thanks
for
joining.
If
you
have
any
more
questions,
join
us
in
slack
or
secretly
in
github,
so
we'll
see.
Y'all,
then
thanks.
B
D
I
I
did
see
how
you
had
a
there's
like
a
new
span,
context
constructor
that
takes
a
config
object
and-
and
I
was
wondering
if
you
chose
that
to
introduce
that
auxiliary
struct
or
the
config
object,
because
you
didn't
want
to
lay
out
the
whatever
this
four
parameter.
The
four
constructor
parameters
in
order
yeah.
F
F
So
yeah
the
the
idea
there
was
to
basically
that
that
span
contact
config
is
the
old
span
context
right.
It's
the
exact
same
struct
with
all
of
the
fields
exported
so
every
place
that
was
initializing
a
span
context
directly
by
just
shoving
into
the
values,
change
that
to
a
span
context.
Config,
pass
that
to
the
new
span
context,
which
then
gives
you
back
the
one
that's
immutable
and
usable
going
forward.
D
I
I
was
able
to
follow
that
one
thing
that
was
harder
to
see
because
I
didn't
go
and
like
actually
look
at
this
in
my
my
editor,
where
I
could
follow
references
and
such
was
there
any
consideration
for
returning
span
contexts
by
value
so
that,
in
other
words,
if
the
caller
got
hold
of
one
and
mutated
it
it
wouldn't
matter,
it'd
just
be
mutating
his
own
copy
of
it.
I
think
that
was
the.
F
Assumption
initially,
when
it
was
done,
was
that
these
were
always
passed
by
value,
and
thus
it's
effectively
immutable
because
you
give
someone
a
by
value
copy
and
they
can
change
it,
but
they
haven't
changed
you.
I
did
actually
run
into
at
least
one
instance,
though,
where
it
was
being
a
reference
to
a
span
that
contained
a
span,
context
was
being
taken
and
then
that
span
context
within
that
span
was
being
mutated,
which
is
kind
of
working
around
that
right.
F
F
No,
it
was
within
the
the
sdk
trace
package
modifying
the
sdk
traces
span,
so
it's
probably
safe
and
I
did
end
up
changing
it
too.
You're
still
taking
a
reference
to
the
span,
but
it's
replacing
the
entire
span
context
with
a
new
derived
context
that
has
that
field
updated.
Okay,
so
I
think
that
pattern
is
still
useful.
I
just
wanted
to
ensure
that
it
wasn't
something
that
could
accidentally
be
done
where
it
wasn't
intended
and
the
way
things
had
been.
It
certainly
could
be.
Okay,.
D
Yeah
I
mean
I
could
see,
I
think,
or
was
some
like
39
files
hit
in
your
in
your
patch,
so
it
was
a
little
hard
at
first
to
to
figure
out
like
where
is
where's
the
sort
of
root
of
this
change.
You
know
I
finally
yeah
so.
F
D
That
snow,
blinding
effect
of
github
review-
I
just
went
up
searching
for
you,
know,
type
span,
context,
struct,
and
then
I
got
to
the
right
place
on
the
page,
but
even
looking
at
the
file
name
list,
we
have
so
many
as
it
comes
up
elsewhere.
D
We
have
so
many
packages
and
names
that
get
repeated
at
different
scopes
that
it's
kind
of
hard
to
see
like
there
there
it
is
so
I
was
able
to
find
it
and
see
what
you've
done
there,
but
then
figuring
out
the
fallout
and
all
the
places
and
the
rest
of
the
code
that
you
know
how
are
they
dealing
with
it
before
was
I
didn't
get
enough
time
yet
to
go
through
that
yeah.
F
So
basically,
what
I
did
was
I
made
the
initial
change
of
turning
the
span
context
to
the
span,
context,
config
and
creating
that
new
span
context
method,
and
then
I
went
through
and
found
every
place
that
you
tried
to
run
the
tests.
It
would
fail
good
all
right.
How
do
I
fix
that
test
and
then
I
fail
somewhere
else.
How
do
I
fix
that
test
and
occasionally,
then,
I
would
run
into
some
situations
like
where
it
wasn't
constructing
an
entire
span
context
as
a
whole
with
all
of
the
fields
in
it.
F
D
D
Yeah,
so
I
could
see
if,
if
it
was
common
enough,
where
people
were
looking
to
say
that
you
know
I
want,
I
want
the
context
with
one
field
changed
or
something
there
is
that
that
sort
of
clone
with
overlay
style
interface,
where
you
know
like,
if
there's
sensible,
zero
values
for
all
the
fields
you
could.
You
can
imagine
somebody
submitting
a
partially
populated
span
context.
D
E
F
F
And,
to
the
extent
that
things
aren't
references
so
that
you
can't
use
nil
to
distinguish
that
becomes
difficult.
So
I
think,
having
just
a
slightly
larger
surface
area
of
all
of
those
with
functions
that
derive
from
a
prior
span
is
sufficient
and
you
can
chain
those
if
you
need
to
make
a
couple
different
mutations.
E
D
Yeah,
so
just
it
looks
like
we've
got
span
context,
configs
are
inputs
and
all
outputs
are
through
methods
that
are
returning
copies.
So
there's
no
way
to
change
the
span
context.
Once
you
have
one
in
hand
right.
D
F
Much
more
like
the
the
go
context,
context
where
you
can
create
a
new
one
and
you
can
derive
from
an
existing
one,
but
you
can't
change
one
you've
already
got
yeah
got
it.
D
Okay,
that's
that's
nice
yeah.
F
Looks
good
well
yeah.
I
just
need
to
go.
Add
some
tests
for
those
new
methods
that
were
created.
Then
I'm
going
to
flip
that
over
to
ready
to
review
so
I'll,
probably
have
that
up
for
review
today.
F
F
It's
it's
one
of
those
things
that
ends
up
touching
a
whole
lot
of
places,
and
I
think
if
we
get
it
right,
it
isn't
a
huge
impact,
but
I
just
I
would
like
to
have
as
many
eyes
as
on
it
as
possible
to
to
make
sure
that
I
didn't
miss
anything
in
terms
of
you
know
different
ways
we
could
have
handled
it.
Yeah
it's
it
seems
like
you've
got
the
same
feedback
from
both
you
and
bogdan,
which
seems
straightforward.
Do
we
need
these
derivation
methods?