►
From YouTube: 2020-08-27 Go SIG
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
B
C
C
Well,
cool
yeah.
I
think
conor
said
that
he
was
all
done
last
week.
So,
oh
all
winding
down.
It
sounds
like
kind
of
crazy
that
you're
just
flying
by.
C
Yeah
looks
like
evan
wasn't
going
to
be
able
to
make
it,
and
I
don't
know
about
a
few
other
people.
I
imagine
josh
isn't
going
to
make
it
just
because
he's
been
extremely
busy
and
then
I
don't
know
about
anthony,
but
we
could
probably
hang
out
for
a
little
bit.
These
sometimes
can
be
kind
of
like
the
afternoon
ones,
had
an
agenda
but
not
really
useful.
If
nobody
shows
up
do
you
have
any
questions.
B
I
guess
I
wanted
to
ask
about
the
about
the
my
most
recent
pr,
the
tos
one.
I
noticed
that
the
mutual
test
integration
test
it
was
sometimes
it
would
take
more
than
30
seconds
specifically
on,
I
think,
go
arch,
3,
386
or
something
yeah.
I
wasn't
sure
how
to
resolve
that.
Unless
I
make
I
was
thinking.
Maybe
I
put
the
file
creation
in
a
separate
test,
but
I'm
not
sure
if
the
tests
will
be
like
ordered
correctly.
C
Yeah,
that's
a
a
good
question.
I
opened
a
bug
to
kind
of
take
a
look
at
that
I'm
guessing.
Maybe
you
saw
the
bug.
A
C
Am
looking
because
it
looks
like
evan
kind
of
dug
a
little
bit
into
it?
I
don't
know
I
haven't
I
haven't
dug
in
myself,
but
he
obviously
said
it's
only
a
three
to
six
platform.
Profiling
shows
90,
90,
plus
percent
of
the
time
that
the
math
big
ad
multi
vvw.
I
don't
think
that's
correct.
C
Which
is
part
of
the
crypto
ramda
number
generation,
the
ca
cert,
as
is
the
culprit,
so
that
seems
kind
of
weird.
One
thing
we
could
also
do
is
in
previous
situations.
We
have
excluded
some
tests
on
the
386
architecture,
which
it
might
be
something
we
could
do
as
a
triage
effort
here,
but
we
should
probably
dig
into
why
that's
actually
taking
so
long
to
actually
compute.
C
No.
Why
is
that
yeah?
But
that's
a
good
question.
I
don't
know
it
is
kind
of
a
it's
annoying
one
right
now,
but
I
don't
I
don't
know
of
any
particularly
good
way.
Let
me
see
if
I
can
find.
D
C
C
It
is
kind
of
weird
that
the
generation
of
a
a
large
number
taking
more
than
30
seconds
it
seems
like.
That
means
something
stuck.
C
Yeah,
that's
thank
you
for
saying
that
I
was
kind
of
thinking
that
when
I
was
reviewing
your
pr
I've
seen
that
a
lot
a
lot
of
the
times
just
to
avoid
these
kinds
of
indeterminate
errors,
people
will
do
exactly
what
you
just
said
is
for
sure
we
call
the
data
generally
test
data
and
then
you
just
put
like
certificates
or
other
any
any
like
json
files,
or
something
like
that
that
you
wanted
to
load
into
that
directory.
C
So
that's
probably
the
way
to
solve
this
is
just
statically,
generate
them
and
put
them
there.
I
remember
you
know
more
than
I
do
about
the
tests,
but
if
I
remember
correctly,
they
were,
they
could
be
probably
static,
but
I
didn't.
I
wasn't
100
positive
if
you
were
doing
some
automatic
generation
every
single
time,
so
I'm
just
going
to
leave
that
up
to
a
future
discussion.
But
if
you
bring
it
up,
that's
actually
a
good
point.
It
might
help
resolve
this
issue.
B
I
I
think
it
can
be
static.
I
was
generating
them
right.
I
was
initially
planning
on
using
the
like
the
show
command
open
ssl
to
generate
them.
I
wasn't
sure
if
that
was
available
on
the
circle
ci
system,
and
that's
why
I
went
with
the
the
go
libraries
for
generating
that,
but
it
shouldn't
be
a
problem.
If
I,
if
I
make
the
test
beforehand
and
push
that
as
part
of
the
commit,
I
don't
think
so.
Yeah.
C
It
sounds
like
yeah,
the
in
the
contrib
repo,
the
cortex
exporter,
eric
added
some
code
to
do
tls
communication
and
there's
a
lot
of
really
great
testing,
that's
associated
with
it,
but
in
the
testing
it
generates.
Certificates
and
in
the
generation
of
certificates
looks
like
on
386
architectures,
generating
big
numbers.
There
is
taking
longer
than
30
seconds
and
causing
things
to
time
out
and
then
panic.
A
Yeah,
I
guess
the
the
one
thing
I
would
just
call
out
there
is
to
make
sure
to
put
a
long
expiration
on
it
so
that
we
don't
have
to
come
back
and
regenerate
them
all
the
time
we're
gonna
forget
about
it
eventually
anyways.
But,
oh,
that's
a
really
good
point.
C
C
Yeah,
that's
a
good
point
yeah
that,
or
he
put
a
long
timeout
on
the
cert,
but
then
also
maybe
even
putting
like
docs
in
there
as
to
how
to
regenerate
them
or
how
they
were
generated
in
the
first
place
is
probably
a
useful
thing.
Yeah.
A
Yeah
having
a
script
for
the
generation
would
be
good
so
that
we
can
regenerate
them
easily
when
we
need
to
but
yeah.
I
think
it
was
reading
somewhere
that
just
recently
the
worst
things
are,
the
things
that
are
periodic
and
required,
like
expiring
certs,
make
make
the
term
either
short
enough
that
you
have
to
automate
it
or
make
it
long
enough
that
it'll
never
matter.
C
Awesome
awesome,
yeah
eric,
I'm
gonna
assign
that
issue
to
you.
C
C
C
Well,
cool!
I'm
gonna
probably
start
sharing
a
screen
at
this
point
I
mean
kind
of
go
through
the
agenda.
I
was
kind
of
waiting
for
some
people
to
show
up
thanks
to
everyone
for
joining
we
kind
of
jumped
into
one
of
the
first
questions
I
wanted
to
call
out
anthony.
I'm
glad
you
showed
up
with
kind
of
discussing
with
you
how
you
thought
the
release
went
thanks
for
doing
that.
By
the
way
I
think
it.
Everyone
was
really
antsy
to
get
that
one
out.
A
Yeah,
I
think
the
the
release
process
was
pretty
smooth
other
than
the
you
know
needing
to
to
sign
the
tags,
which
is
definitely
a
good
thing
to
do.
I
just
wasn't
quite
prepared
for
it,
so
I
got
delayed
by
about
half
hour
or
so.
While
I
was
quickly
googled.
How
do
I
set
up
a
ub
key
to
work
with
wsl.
A
C
A
Yeah
yeah,
it's
nice.
The
keys
are
generated
right
on
the
ub
key,
so
they'll
never
leave
the
key
yeah.
It's
pretty
nice
and
the
the
way
it
works
with
wsl
is
basically
pipes
that
are
set
up
between
the
gpg
agent
on
windows,
because
wsl
doesn't
have
usb
access
and
wsl.
So
it
communicates
over
a
pipe
which
is
kind
of
neat,
but
it
seems
to
work
pretty
well.
C
A
Yeah
so,
anyway,
other
than
that
the
the
instructions
were
really
good,
easy
to
follow
seemed
to
go
off
without
a
hitch.
The
contrib
release
was
a
bunch
of
changes
because
of
the
the
kv
package
renaming,
but
even
that
wasn't
that
bad
it
was
find
and
replace
right,
just
get
a
list
of
all
the
things
that
reference
that
package
and
go
through
one
by
one,
killing
them
running
pre-commit
every
time
after
until
it
actually
passed
and
that
wasn't
so
bad.
A
I
think
there
was
one
or
two
places
where
the
there
was
a
metrics
api
that
had
changed
that
required
a
little
more
thought
than
change
label
to
or
kv
to
label
and
standard
to
semcone
other
than
that
really
straightforward.
So,
hopefully
anybody
else
who's,
updating
to
0.11
also
has
a
pretty
easy
time
of
it.
C
C
Well,
cool
yeah,
I'm
glad
that
works
really
well,
I
feel
like
there's
a
lot
of
other
areas.
We
could
probably
improve
on
writing
things
down,
but
that
was
one
where
we've
got
some
existing
talks
on
call
that
was
smooth,
and
so
with
that
kind
of
moving
on
one
of
the
other
things
that
I've
been
working
on
a
little
bit
this
past
week,
we
talked
about
it
last
meeting
to
try
and
get
a
little
bit
more
visibility
into
the
project
status
and
labeling
and
just
general
progress.
C
We
had
a
few
questions
in
getter
over
the
past
week,
or
maybe
even
two
weeks
in
an
open
issue
about
asking
about
progress
and
stability
of
the
apis
and
that
kind
of
thing,
which
is
a
tough
one,
because
not
only
do
I
think
that
we
have
some
weird
clunkiness
associated
with
our
api
that
we're
looking
to
change,
but
the
specification
itself
is
having
breaking
changes
coming
in
from
the
top.
C
So
I
think
that
yeah
making
it
clear,
like
the
visibility
of
like
some
of
these
things,
is
probably
a
good
idea
and
with
that
I
added
the
priority
labels
that
the
specification,
proto
and
oteps
all
share
and
a
lot
of
the
you
know
open
telemetry
projects
with
the
ps
p1
being
the
highest
and
p3
being
the
lowest
and
p1s
being
something
that
is
going
to
break
things
but
needs
to
needs
to
be
included.
C
And
then,
with
that
I
went
through
and
tried
to
do
my
best
classifying.
I
think
we
have
67
issues
or
something
like
that
currently
and
there's
20
or
36
that
still
need
triage.
So
I
don't,
I
didn't
classify
all
of
them,
yet
some
of
them
are
really
old.
They
long
predate
me.
So
it's
it's
taken
a
little
while
kind
of
moving
through
that,
but
it's
also
been
really
helpful
because
I
was
able
to
create
a
new
project
board
with
our
ga
burndown.
C
So
it's
a
little
bit
easier
to
see
the
progress
as
we're
getting
to
ga
I
mean.
Ideally,
these
columns
are
all
empty
when
we're
at
ga,
which
is
kind
of
a
lie,
because
I
think,
there's
probably
still
going
to
be
some
more.
You
know
cards
added
here,
given
the
fact
that
the
specification
itself
isn't
at
ga,
so
once
that
actually
hits
ga
we'll
be
able
to
finalize
this,
but
it's,
I
think,
a
better,
a
better
solution
than
what
was
before,
which
was
nothing
so
yeah.
C
I
think
that's
ideal
and
included
in
that
for
very
little
cost
as
well.
I
included
the
new,
updated
the
milestone
for
rc1,
and
this
includes
anything
that
has
the
release
required
for
ga.
Pretty
much
is
just
all
tickets
and
all
that
kind
of
thing
there's
not
an
automated
action
or
anything
like
that.
It's
still
manually
done,
which
kind
of
will
go
into
the
second
part,
but
it
should
give,
I
think,
a
little
bit
better
visibility
into
our
our
status
flow.
C
This
also
has
a
very
arbitrary
november
17th
deadline,
because
that
was
pulled
out
of
thin
air
in
the
specification
a
long
time
ago.
But
it's
it's
not
real.
I'd
love
to
hit
that,
but
we'll
see
we'll
see
about
that.
C
Yeah
cool
and
then
to
kind
of
further
refine
that
the
p1
issues,
I
think,
are
kind
of
the
most
important
to
probably
address
sooner
rather
than
later,
so
I
made
a
separate
project
direct
or
specifically
for
them
it's
again
kind
of
a
little
frustrating
github
projects
are
not
essentially
like
integrated
with
any
of
these
labels.
So
I
I'm
looking
at
solutions
to
try
and
automate
some
of
the
actions
associated
with
these
meaning.
C
If
you
put
a
label
on
it
that
says
required
for
ga,
it
would
put
it
onto
the
board
or
if
it
you
know,
you
put
a
label
on
it.
C
That
says
not
you
know
after
ga,
then
it
would
take
it
out
of
the
triage
column
that
I
have
there,
but
that's
things
that
you
probably
don't
nobody
cares
about,
except
for
me
because
otherwise
I
gotta
go
in
there
or
anthony's
gotta
go
in
there
and
clean
it
up
so
yeah,
that's,
probably
something
I'm
gonna
look
at
in
the
next
week
I
looked
at
a
few
actions
that
we
can
implement.
Maybe
building
our
own
might
be
something
to
do.
This
is
also
only
done
currently
for
the
hotel
repo.
C
I
want
to
do
this
for
the
contributor
as
well.
That
was
a
little
bit
easier.
I
actually
went
through
and
was
able
to
triage
all
of
the
issues
really
quickly,
they're,
all
labeled,
with
required
for
ga
or
after
ga
and
they'll.
I
think
all
of
them
have
priorities
on
them.
A
lot
easier.
I
think
there's
just
a
lot
less
issues
and
they're
more
recent,
so
I
had
more
context
on
them.
So
yeah.
I
think
that's
idea
ideal.
I
need
to
get
back
to
finish
labeling
issues.
Anyone.
C
As
a
maintainer
or
approver
should
have
access
to
label
things
as
well
feel
free
to
add
the
release
tag,
that's
poster
pre-ga
with
some
prioritization
on
it.
If
you,
if
you
have
an
understanding
of
it,
that'd
be
ideal.
I'd
love
to
have
some
help
on
that
one
yeah,
but
that
I'm
just
going
to
pause
before.
C
Well,
cool
yeah,
I
kind
of
just
wanted
to
jump
into
some
of
the
p1
api
stuff
that
I've
kind
of
been
identifying
over
the
past
few
days.
I
was
looking
at
moving
this
api
around
mostly
just
moving
the
api
package
up
to
the
hotel
stuff,
and
I
was
realizing
there's
just
like
a
lot
of
cleanup
in
the
trace
api
that
we
have
had
slated
for
a
while
and
haven't
done
or
needs
to
be
done
and
is
now
I'm
just
kind
of
discovering,
and
one
of
them
is
this
spam
interface.
C
I
I've
noticed,
there's
like
there's
quite
a
few
different
issues
directly
related
to
that.
I
I
think
I
opened
up
all
of
these,
some
of
them
quite
a
few
months
ago,
some
of
them
more
recently.
This
one,
I
think,
is
from
a
long
time
ago.
Nope!
That's
not
that
long.
It's
only
29
days,
which
you
know
is
not
that
far
but
kind
of
just
walking
through
some
of
the
changes.
I'm
expecting
this
upcoming.
C
We
kind
of
wanted
to
walk
through
that
just
to
round
out
the
meeting
and
get
people's
opinions
on
it.
This
ad
event,
and
then
ad
event
with
timestamps,
seems
redundant.
I
wrote
up
a
pretty
long
issue
about
that.
C
That
is
here,
I'd
love
to
get
some
feedback
or
comments
or
emojis
on
the
issue
itself,
but
the
idea
is
replace
the
add
events,
the
two
existing
methods
here
with
a
single
method
and
that
method
is
accepting
of
a
name
and
then
any
sort
of
options
that
are
associated
with
it,
and
this
matches
the
specification
a
lot
closer.
The
specification
requires
a
name
and
then
attributes
and
timestamps
are
optional
events
or
optional
parameters
and,
as
everyone
on
the
column
shows
aware,
govern,
options
are
a
little
bit
tough.
C
Given
the
static
nature
of
the
type
system,
it
needs
to
actually
be
explicit,
but
we
have
some
ideas
and
we
already
have
existing
best
practices
around
options,
and
I
think
that
the
idea
that
I
had
is
just
to
unify
that
in
our
existing
options
schema
by
then,
you
could
pass
in
an
attribute
here
or
a
timestamp
here,
and
it
would
be
uniform.
This
also
opens
up
the
option
of
eventually,
if
I
think,
it'd
be
kind
of
cool.
C
If
you
wanted
to
add
like
a
context,
if
you
wanted
to
pass
a
context
with
an
event
and
do
something
cool
with
it,
currently,
these
take
a
context,
and
they
do
absolutely
nothing
with
it.
But
that
may
be
something
we
could
change
in.
The
future,
like
the
sdk
may
want
to
take
a
context
as
well
and
then
auto
annotate
things
or
get
labels
from
within
the
context
or
something
like
that.
C
But
I
think
this
api
design
allows
for
that
extensibility
a
lot
easier
than
this
one,
which
had
was
passing
a
parameter
that
isn't
used
or
has
duplicate
names,
something
like
that.
So
that
was
one
of
the
big
ones.
I
wanted
to
try
to
get
some
feedback
on.
C
A
Yeah
I
like
the
idea
of
unifying
those
just
by
moving
the
timestamp
to
options.
Batteries
are
optional
as
well
right,
they
kind
of
were
in
the
original,
but
they
were
the
only
multi-valued
attribute
there.
So
you
couldn't
have
other
options.
You'd
definitely
do
that
need
to
go
to
the
functional
options,
type
approach
that
we
have
for
for
other
things
in
terms
of
the
context
looking
at
it.
A
It's
not
every
method
here
takes
a
context,
so
I
guess
that's
not
necessarily
the
case,
but
I
think
a
lot
of
times
anything
that
that
might
interact
with
the
network
at
some
point
just
takes
a
context
at
the
beginning.
I
don't
know
if
we
would
ever
expect
these
two,
so
it
might
be
fine
to
remove
it.
C
Yeah
normally,
I
think,
of
context
to
provide
some
sort
of
values
or
deadlines
right
and
there's
only
there's
only
three
methods
here
that
take
context
and
these
two
which
I'm
trying
to
address
and
then
there's
this
one
and
all
the
all
of
this
one
is
there's
actually
a
separate
stanza
in
that
ticket
is
a
wrapper
around
niceties
around
an
error
and
then
passing
it
to
an
ad
event,
and
it
just
adds
an
error.
C
C
It
for
ad
event
yeah
exactly
yeah,
no
100,
it's.
That
makes
a
lot
of
sense.
Why
it's
there,
but
I
was
just
like:
oh
that
would
actually
clean
things
up.
In
fact,
let's
see
yeah
I
was
thinking
like
you
could
just
simplify
to
accept
the
same
options.
Even
here.
If
you
wanted
to,
you
know,
then
extend
the
record
error
and
then
you
would
have
a
nice
video,
a
nice
method
around
this.
It
was
kind
of
my
idea.
This
was
a
little
bit
extra
external.
A
Yeah
that
would
give
you
the
ability
to
add
the
attributes
as
well.
I
think
the
only
error
options
really
that
are
useful
are
around
setting
the
status
code.
If
you
wanted
to
do
that
as
well
and
I
believe
status
code
is
going
away
so
that
becomes
kind
of
pointless.
C
C
To
not
happen,
I
guess
that's
kind
of
where
I'm
going
with
that
one,
but
yeah.
A
C
Well
cool.
It
sounds
like
there's.
No
immediate
rejections,
I'm
also
just
presenting
this
for
the
first
time,
so
I
don't
expect
all
opinions
to
be
fully
formed,
but
yeah
that's
kind
of
one
of
the
big
things
I
was
looking
at.
C
D
C
Yeah
exactly,
I
think,
that's
really
important
at
this
point.
It's
not
ideal
that
we're
making
something
relatively
late
in
the
game,
but
I
I
think
that
it
needs
to
be
done
before
ga
to
try
and
provide
users
with
a
usable
experience
if
they
enjoy
it
and
then,
like
you,
said
like
a
simpler
api
and
one
that's
extensible
like
like
that
design
is,
I
think,
would
be
really
helpful
going
forward
and
building
from
it
so
yeah,
I
agree
cool
yeah.
C
The
next
thing
was
the
set
attribute
and
set
attributes.
I
think
if
this
is
a
hall
I'll
hold
over
from
there's
another
ticket
for
this,
but
I'm
pretty
sure
this.
This
method
here
is
actually
a
holdover
from
before
our
key
value
system
had
an
infer
method
or
it
used
to
be
called
an
any
method
where
we
could
infer
from
an
interface-
and
I
haven't
verified
this,
but
I'm
pretty
sure
that
this
is
just
re-implementing
that
and
I
think
it's
extraneous
and
I
think
it's
a
duplicate
of
what
could
already
be
achieved
here.
C
This
is
it
yeah.
The
specification
itself
is
a
little
vague
on
this
one
because
it
says
both
you
need
to
have
a
function
that
accepts
or
sets
attributes,
but
also
a
method
that
sets
a
single
attribute,
which
is
is
a
little
vague
because
it
seems
like
there
may
be,
requiring
two
methods
that
both
of
these
methods
are
there.
However,
I
think
that
set
attributes,
the
plural
one
is
since
it's
a
variatic,
you
can
set
a
single
attribute,
but
you
can
also
set
attributes,
so
it
kind
of
encapsulates
both
elements
of
the
specification.
C
The
person
who
read
this
was
bogged,
and
it
looks
like
if
I
was
looking
through
the
blame
a
little
bit
in
the
specification
and
he's
in
the
javascript,
and
they
only
have
a
single
set
attribute
method
there
as
well.
So
it
seems
like
the
removing
the
set
attribute
which
is
is
the
holdover
of
our
old
infer
function?
Is,
is
probably
the
better
way
to
go
and
it
kind
of
again
it
goes
back
to
that
simpler
api.
C
C
A
C
Yeah,
I
I
don't
think
I've
ever
used
that
attribute
as
well,
so
that's
kind
of
a
funny
one
but
yeah.
I
think
that
is.
There
are
two
of
the
newer
things
that
came
with
this
past
week.
I
wanted
to
address,
hopefully
get
these
done
in
the
next
week.
The
only
other
thing
was
our
end
option
and
our
start
option.
It
was
recommended
that
we
don't
have
a
difference
between
our
start
options
and
our
end
options.
C
It
originally
was
our
starter
options,
be
here
with
the
tracer.
I
think
the
idea
was
to
restrict
they
didn't.
We
didn't
want
people
setting
what
was
some
of
the
start,
options,
attributes
or
links,
or
anything
like
that
after
the
facts,
and
I
think
that
that's
fine,
I
think
that
if
you
want
to
make
a
restriction
like
that,
that's
that's
totally
cool.
C
You
can
go
ahead
and
do
that,
but
I
don't
think
you
should
be
making
that
assertion
in
the
api
and
a
lot
of
other
people
have
kind
of
argued
against
doing
this,
as
well,
mostly
for
the
fact
that
if
you
wanted
to
extend
things
or
if
you
wanted
to
start
a
span
prior
to
knowing
any
of
these
things
or
say
you
know,
you
don't
know
this
mankind
prior
to
it
actually
starting
or
you
don't
know,
attributes
that
you
wanted
to
attach
to
it.
Well,
I
guess
the
attributes
aren't
too
critical.
C
The
links
are
maybe
something
that
you
find
out
after.
I
think
you've
done
some
processing,
but
just
maybe
the
currency
patterns
of
your
software,
like
they
don't
allow
for
you
to
know
priority.
What
these
are.
You
maybe
want
to
set
those
at
the
end
time,
but
I
think
that's
a
valid
request,
so
I
don't
know
why
we
were
restricting
to
only
being
able
to
set
the
end
time
for
an
end
option.
C
That
being
said,
I
think
that
if
you
wanted
to
restrict
it,
you
could
still
do
so
in
the
implementation
like
if
you
wanted
to
write
an
sdk
and
the
sdk
just
said
no,
like
I
don't
allow,
you
have
to
know
this
stuff.
When
you
start
a
spam
like
the
api,
would
still
allow
you
to
do
that,
but
it's
the.
C
Allow
right
now,
I
don't
think
that
that's
what
we
want
designed
here
for.
C
The
way
it
also
says
the
same
thing
like
it
doesn't
have
a
restriction
that
you
can't
set
that
at
that
point
in
time.
So.
A
C
Well,
cool
yeah,
there's
also
anthony.
You
might
actually
have
a
little
more
context
on
this.
I
think
I
think
you
might
have
also
responded
to
this.
There's
a
new,
oh
shoot.
That's
the
same
issue.
C
Record
exception:
did
I
link
to
the
wrong
okay?
Well,
I
just
linked
to
the
wrong
ticket
1104
yeah
there.
It
is.
The
record
exception-
is
added
to
the
specification
just
recently,
and
so
that
is
asking
for
some
sort
of
ability
to
capture
a
stack
trace
in
a
span
event
and
exceptions
in
go,
aren't
really
a
thing,
but
the
analogous
part
is
is
kind
of
derived
that
it's
similar
more
to
a
panic
than
it
is
to
an
error,
and
so
I
was
thinking
first
off.
C
It's
a
should,
so
it's
not
an
absolute
requirement
that
we
have
this
in
the
specification,
but
I
was
kind
of
wondering
if
we
could
provide
maybe
some
sort
of
method
that
you
could
defer
on
entrance.
That
would,
if
there
is
a
panic
occurring,
add
an
annotation
to
any
open
span,
and
then
you
know
allow
the
panic
to
continue
not
getting
in
the
way
it
was
kind
of
an
idea.
It's
actually
I
put
it
as
a
p1.
This
is
probably
not
a
it's,
not
a
breaking
change.
C
A
Yeah,
it's
probably
not
a
must-have,
didn't
josh,
add
something
similar
to.
I
think
it
might
have
been
the
the
width
span
method.
That's
now
since
been
removed.
He
had
a
recover
handler
to
it.
The
added
error
information.
C
He
had
a
comment
in
there.
I
think
that
was
a
to
do
to
do
something
like
this,
but
no,
I
don't
think
it
was
ever
actually
implemented.
C
A
In
spanish,
I
suppose
is
that
in
span
end
yeah,
so
here
we
go
recovering
in
span
end.
It
checks,
if
there's
been
a
panic,
adds
an
event
with
a
time
stamp
with
all
of
the
the
information,
or
at
least
you
know,
the
error
name
and
the
the
air
type
and
then
re-panics.
C
Yeah,
that's
not
a
bad
idea.
Can
you
just
update
update
that
issue
1104,
maybe
with
a
link
to
that,
because
I
think
that
that's
that's
that's
really
yeah
yeah.
I
totally
didn't
remember
that
so
yeah.
I
appreciate.
C
It
well
cool,
I
don't
know
if
people
who
were
jumping
on
the
call
later
had
some
more
things
they
wanted
to
add
to
the
agenda,
but
that
was
pretty
much
all
the
stuff
I
wanted
to
go
through
today.
D
I
had
a
quick
question
about
the
contribute
library,
so
I
work
with
care
care.com
and
I'm
working
closely
with
single
effects,
one
of
our
that's
our
apm
product,
so
simple
effects
and
splunk
to
do
all
the
open
telemetry
for
a
new
platform,
and
so
one
of
the
things
I
noticed
in
contrib
there's
a
help
wanted
for
database
sql
and
if
anybody
was
actually
going
to
try
to
tackle
that
and
if
not,
then
that's
something
that
I
was
going
to
try
to
tackle
over
the
next
few
weeks.
C
C
It
stems
back
to
the
fact
that
there's
no
generics
currently
in
goat
and
it's
kind
of
a
problem
because
of
that
I
don't
I'd-
have
to
kind
of
look
at
the
the
open
pr,
but
there
is
a
link
to
the
previously
open
pr
and
it
involves
using
tooling
that
auto
generated
a
bunch
of
go
code
to
account
for
all
of
the
possible
combinations
of
of
calling
conventions
on
it
again.
Like
I,
I
don't
know
the
specifics.
I
have
to
open
it.
A
C
But
I
yes,
if,
if
you
are
up
to
that,
like
I
would
that'd
be
awesome,
instrumentation
that
we
really
loved,
because
it's
it's
something
I
think
was
being
put
off
mostly
because
there's
just
a
lot
of
other
api
and
sdk
issues.
But
it's
it's
important.
It's
definitely
an
important
one,
but
I
am
going
to
say
it's
it's
from
what
I've
seen
already
is
a
challenging
one,
the
existing
pr
that
was
there
it
generated.
You
know
it's
tens
of
thousands
of
lines
of
code.
I
think
it's
30
000
lines
of
code.
D
Is
this
something
where
it
can
start
like
minimal
and
then
add
features
over
time
like
we're?
Gonna
have
to
do
part
of
this.
Just
for,
for
you
know
our
platform
anyways,
but
when
it
comes
to
like
what
I
I've
used
like
an
open
tracing,
you
know,
and
personally
I
don't
feel
like
you
need
to
have
a
ton
of
tracing
inside
of
the
the
database.
D
I
feel
like
actually
adds
a
lot
of
noise
when
you,
when
you
go
into
your
apm
product,
especially
if
you
see
like
a
thousand
spans
because
you've,
you
know,
had
a
thousand
rows
right.
Things
get
clogged
up.
So
I
just
kind
of
wonder
if
there's
a
a
minimal
version
of
this,
so
that
we
can
at
least
see
the
the
basic
network
activity
know
that
we've,
you
know,
hit
another
system
and
maybe
some
of
the
basic
details
around
what
that
interaction
was.
D
Might
ask,
though,
because
I
didn't
realize
that
it
was
such
a
it's
probably
what's
been
sitting
at
the
the
end
of
that
pile
for
so
long.
I'm
glad
I
asked.
C
Yeah,
it's
been
there
for
a
little
while
I
I
feel
like
yeah.
I
haven't
looked
too
deep
into
it.
I
I
know
that
the
the
guy
we
had
working
on
it.
He
was
a
contractor
for
light
stuff
for
a
little
while
really
really
smart,
guy
kezner,
but
yeah
he
was.
C
That
was
his
solution
to
it.
I
I'm
not.
I
don't
know
enough
details
to
tell
you
if
we
can.
Okay,
I
have
a
minimal
solution
here,
but
I,
if
you
have
the
cycles
to
go
through
and
try
to
figure
that
one
out,
I
would
love
to
get
some
somebody
to
think
about
it,
just
okay
for
exactly
what
you're
pointing
out
so
that
that'd
be
awesome.
I'd
really
appreciate
it
cool
yeah,
my
thinking.
A
Is
that
as
long
as
it's
a
one-way
door,
minimal
solutions
is
probably
better
than
nothing.
You
know
if
it
doesn't
prevent
us
from
adding
in
the
future
or
doesn't
prevent
people
who
have
requirements
that
are
beyond
that
from
at
least
getting
something
out
of
it.
Then
it's
probably
good.
D
C
If
there's
I'm
trying
to
find
it
right
now,
of
course,
it's
not
coming
really
easily,
but
I'll
make.
C
Issue
when
I
do
find
it
because
they're
what
yeah
it
was,
it
was
closed
because
it
was
an
existing
attempt.
You
can
read
the
backstory
on
it
as
well
and
I'll
be
able
to
dive
deeper
into
it.
Then
I
can
give
you
an
explanation
at
this
point,
so
that
makes
sense.
Okay,
cool
thanks,
yeah,
absolutely
yeah,
thanks
for
jumping
in
on
that,
though,
even
even
if
you
don't
decide
to
go,
build
it
I'd
love
to.
If
you
just
have
some
comments,
unlike
what
you
would
suggest
in
the
future,.
C
Up
awesome:
well,
I
think
that
we
could
probably
end
it
there
thanks
everyone
for
joining
next
week,
we're
meeting
in
the
morning.
So
I'd
love
to
see
you
all
at
that
point
in
time,
but
until.