►
From YouTube: 2020-09-24 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
A
I'll,
probably
jump
in
really
quick
just
to
start
things
off.
If
you
can,
please
add
your
name
to
the
agenda
or
to
the
meeting
notes
as
an
attendee
and
if
you
have
anything,
add
it
to
the
agenda.
A
Yes,
cool
yeah,
so
kevin
is
jumping
in
the
kind
of
standard
thing
that
I
think
we're
trying
to
do
is
just
taking
a
look
at
the
project
boards
for
the
past
week
and
overall
definitely
some
great
progress.
A
I
think
seeing
a
lot
of
issues
getting
closed
and
related
vrs
getting
closed
related
to
our
progress
to
getting
to
the
ga
we're
also
identifying
a
few
new
things
in
that
we
actually
need
to
accomplish,
which
I
still
like
I
was
saying
kind
of
last
week-
expect
this
number
to
keep
going
up,
but
yeah.
I
think
we're
making
some
good
progress
good
to
see,
hopefully
keep
that
momentum
going
jumping
into
the
agenda
itself.
I
know.
A
Last
week
you
kind
of
talked
about
a
release,
I'm
interested
to
hear
what
your
thoughts
on
this
anthony
are.
B
Yeah
I
I
wanted
to
do
a
release.
Last
weekend
I
started
to
prepare
it
and
then
I
merged
that
force
flush,
pr
which
made
the
test
all
flaky,
and
so
I
kind
of
backed
off
from
that
because
I
I
it
couldn't
get
the
the
removal
of
that
test
in
until
people
came
along
during
the
weekend
and
reviewed
that
removal
and
then,
by
that
time
there
were
a
few
other
things.
B
I
think
that
were
lined
up
that
we
should
have
got
in,
but
we
seem
to
be
in
a
pretty
decent
spot
right
now
to
cut
a
release.
So
tonight
I
will
prepare
a
release
pr
for
the
main
repo
and
get
that
up.
A
Yeah,
okay,
cool!
If
that
sounds,
I
was
thinking
the
same
thing.
I
think
we're
at
a
good,
stable
enough
spot
in
this
in
this
process.
I
think
there's
some
some
good
stuff
that
can
come
next.
That
makes
sense
to
me
and
then
I
think
the
impetus,
as
you
know,
anthony
there's,
an
issue
in
the
contrib
repo
or
the
macro
instrumentation
actually
needs
a
new
release,
so
yeah.
I
think
this
is
all
this
all
makes
sense.
So
later
tonight
sounds
good.
I'm
gonna
catch
that.
A
Cool
sounds
good,
yeah
related
to
the
things
that
are
kind
of
still
in
flux.
There's
an
open
issue
for
this
baggage
move,
which
I
just
I
just
love
the
rabbit
hole
that
coding
projects
like
this
include.
This
was
supposed
to
be
a
part
of
a
comprehensive
strategy
to
move
the
api
out
into
this
top
level
to
make
it
more
accessible
and
direct
for
new
newcomers
and
a
good
catch
and
good
feedback
thanks
for
the
feedback
as
well.
A
Thanks
for
the
review
was
that
a
lot
of
this
movement
into
this
propagators
package.
Now
it
doesn't
have
the
context
of
being
in
the
baggage
package.
So
there's
some
naming
issues,
I'm
looking
into
trying
to
resolve
this.
I
was
realizing
that
the
specification
actually
has
a
lot.
It
has
evolved
a
lot
since
we
initially
built
out
this
part
of
the
api,
and
it
has
a
lot
of
detailed
requirements
into
actually
supporting
baggage
itself
as
like
a
an
abstract
class
or
an
abstract
data
type,
and
we
don't.
A
I
think
we
kind
of
support
that
with
the
map
type,
but
we
also
have
these
other
two
other
types
that
are
there
to
support
hooks
and
some
other
interesting
access
functions
to
it,
and
I
think
this
could
probably
use
a
general
overhaul
and
a
more
direct
approach
into
defining
a
valid
structure
and
then
that
bag
of
structure
is
then
you
know
dealt
with
in
those
propagators.
A
You
know
having
a
baggage,
propagator
and
having
a
baggage
structure
was
kind
of
my
thought
on
this.
That
being
said,
from
this
past
specification
meeting
on
tuesday,
this
baggage
api
itself
is
a
little
bit
in
flux.
Right
now,
especially,
the
propagation
scheme
is
a
little
bit
in
flux
as
to
how
we
want
to
actually
implement
it.
A
If
we're
going
to
implement
the
standard
draft
and
that
kind
of
thing,
so
I
was
kind
of
wondering,
if
maybe
I
should
just
hold
off
like
for
a
few
days
on
this
one
and
get
some
resolution
on
it,
and
so
I
was
also
kind
of
just
wondering.
If
any,
you
know,
I
was
honestly
just
trying
to
crowdsource
the
idea
as
to
like
what
we
think
the
next
steps
on
this
pr
are
going
to
be.
A
I
have
the
initial
idea
to
just
close
it
and
come
back
at
it
with
a
different
approach
and
try
to
rebuild
it
around
the
api
or
around
the
specification,
but
I
kind
of
wanted
to
hear
what
everyone
else's
thoughts
were
on
it.
B
A
Yes
close,
I,
I
probably
would
just
put
the
baggage
structs
in
the
top
level
package,
so
the
hotel
package
itself
directly,
because
that's
the
goal
is
to
move
everything
out
of
like
an
api,
so
you
would
have
an
hotel.baggage
struct
there
and
then
yeah
to
have
a
propagator
in
the
propagators
package
and
then
that
would
mutate
that
struct
directly
I
haven't
actually
implemented
it.
I
was
a
little
worried
about
dependency
cycles
there.
I
don't
know
if
that's
possible.
A
One
of
the
things
that
I
was
kind
of
thinking
is
the
only
other
place
that
touches
the
existing
underlying
data
representation
is
in
the
open
source,
open
tracing
bridge
right
now,
which
is
actually
what
I
think
the
the
crucial
reasons
why
baggage
is
historically
in
open,
telemetry
in
general
is
because
it's
brought
forward
from
open
tracing,
so
it
needs
to
be
compatible
with
that,
but
I
was
also
realizing
that,
like
there
there's
not
really,
I
think
much
use
of
baggage
outside
of
that,
so
it
was
it
was
kind
of.
A
I
was
also
thinking
of
keeping
the
underlying
implementations
taking
the
the
map
and
taking
that
putting
it
into
an
internal
package,
and
then
I
could
just
wrap
that
with
a
struct
at
the
top
level
was
what
I
was
thinking
and
then
the
implementation
in
the
bridge
wouldn't
have
to
actually
change
at
all.
That
was
my
thought.
B
B
Yeah
yeah,
so
so
then,
we've
got
just
that
baggage
that
that
expo
exported
baggage
struck
at
the
top
level
and
a
set
of
functions
for
interacting
with
it,
which
seems
more
like
what
the
spec
is
is
driving
towards.
A
I
agree
that
was
my
interpretation
as
well,
so
yeah.
I
think
I'm
going
to
go
in
that
direction.
I'll
probably
close
this
pr
out,
just
because
it'll
be
a
different
enough
change
that
I
don't
want
to
bring
a
lot
of
this
context
into
the
new
one
but
yeah.
I
think
that's
probably
the
way
to
go
cool
thanks
for
rubber
ducking
that
with
me
a
little
bit
anthony.
I
think
you
added
the
shutdown
methadone.
B
Yeah,
so
there
there
was
a
the
task.
I
think
we,
when
we
changed
a
bunch
of
the
examples
to
use
the
batch
band
processor
instead
of
the
simple
spam
processor.
We
didn't
update
it
to
actually
shut
down
the
processor
which
wasn't
a
problem
before,
because
the
simplest
fan
processor
always
just
shipped
whatever
traces
could
flow
through
it.
But
the
batch
band
processor
will
bash
things
up
and
we
need
to
shut
that
down,
which
then
kind
of
led
to
the
question
of
okay.
B
Well,
how
are
can
is
there
an
easy
way
to
ensure
that
we
expose
that
shutdown
method
so
that
people
can
call
it
rather
than
necessarily
needing
to
keep
a
copy
of
the
batchband
processor
before
you
inject
it
as
a
processor
into
your
tracer
provider?
B
And
so
I
think
the
the
idea
here
was
that
could
we
have
a
shutdown
method
on
the
tracer
provider
where
it
just
keeps?
It's
got
a
list
of
all
of
the
spam
processors
that
it
has
they've
got
shut
down
on
their
interface.
They
can
just
iterate
through
all
of
them,
shutting
them
down,
but
I
don't
think
that's
on
the
on
the
spec
for
the
tracer
provider.
B
A
Yeah,
I
think
in
general
we
could
we
could.
We
could
add
that
functionality
to
it.
I
don't
think
that
there
is.
I
haven't,
read
this
in
a
while,
but
I
don't
think
there's
an
exclusivity
to
like
what
could
actually
be
included
in
the
tracer
provider
method,
our
methods
that
are
included
there,
so
I
think
we
could
still
be
compliant
with
the
specification.
A
The
thing
is
in
the
past,
where
we've
done
this
kind
of
thing,
like
the
error
handling,
we
just
implemented
it
because
we
needed
it
and
it
turned
out
the
rest
of
the
community
also
needed
it,
and
it
was
like
months
later
when
somebody
was
like
you
know,
go's
doing
this
thing
with
aaron
we
should
probably
also
be
doing
so.
It
might
be
useful
to
try
to
include
this
at
the
spec
level.
A
That
being
said,
I
haven't
haven't
spent
enough
time,
I
think,
to
look
at
other
implementations
to
see
what
they
do
in
these
situations.
But
it's
a
good
question.
I
think,
to.
B
Ask
okay,
I
I
don't
think
this
is
something
that
would
necessarily
have
to
be
settled
before
ga
right.
This
would
be
an
additive
change.
It's
not
gonna
break
backwards,
compatibility
anywhere,
so
we
can
certainly
bring
it
up
to
the
spec
and
and
see
if
there's
an
appetite
for,
including
it
more
generally,
but
we
probably
don't
have
to
make
sure
that
it
gets
done
yesterday.
A
Yeah,
that's
a
good
point
and
with
that
in
mind,
I'm
kind
of
wondering
if
it
sounds
like
a
really
important
thing
to
add,
but,
like
you
said,
like
it's
a
backwards,
compatible
addition
to
the
interface,
I
wonder
if
it's
something
we
want
to
do
beforehand,
it
seems
like
yes
to
me
because
it
seems
so
obvious,
but
I
I
just
wanted
to
temper
our
expectations.
Giving
me
like.
I
don't
know
six
weeks
before
we
can
expect
the
spec
to
hit
a
release
candidate
trying
to
get
into
a
position.
B
B
But
I
I'm
also
kind
of
wary
of
making
an
addition
that
later
ends
up
getting
picked
up
in
the
spec
in
a
slightly
different
form,
and
then
we
have
to
either
support
both
both
signatures
or
deprecate
one
and
end
up
with
something
that,
because
it's
in
in
the
interface
now
and
we're
we're
ga,
we
can't
really
get
rid
of
it.
But
it's
not
really
proper
part
of
the
spec
going
forward.
A
Yeah,
that's
a
an
excellent
point.
That's
a
good
point!
Okay,
did
you
want
to
open
an
issue
anthony
or
did
you
want
me
to.
A
Okay,
cool
yeah
thanks.
That
sounds.
I
think
I
think
you
hit
the
right
right
tone.
That
sounds
like
the
right
idea-
cool.
I
guess,
there's
actually
nothing
else
on
the
agenda.
We
kind
of
have
some
small
attendee
lists
today
too,
as
well.
So
usually,
the
afternoon
sessions
are
a
little
bit
less
intended,
but
yeah
I'll
kind
of
just
open
it
up
in
case
anybody
else
wanted
to
jump
in
love
to
say,
hi.
To
alia,
I
see
some
new
people
on
here.
C
A
Well,
first
off
thanks:
that's
we
love
this
because
the
contributions,
yeah
cool.
C
Yeah,
hopefully,
you'll
be
seeing
sing
more
me,
I'm
trying
to
become
involved
so
it
actually.
If
there's
anything,
I
can
do
that
would
be
appropriate
for
a
newcomer.
Let
me
know,
and
I
can
help
out
where,
where
help
is
needed.
A
Yeah,
absolutely
we
definitely
welcome
the
help
and
appreciate
it
greatly.
I
think
a
good
place
to
just
kind
of
dive
in
is
just
in
the
if
you
find
an
issue,
especially
something
that's
related
for
the
the
ga
that
you
know
looks
interesting
to
you.
I
don't
actually
know
if
we
have
a
very
good
set
of
good
first
issues,
labeled
right
now,
but
generally
a
p1
or
a
higher
order,
priority
issue.
We
try
to
get
those
prioritized
first
rather
than
the
p3s,
or
something
like
that.
A
But
honestly,
if
you
find
an
issue
that
looks
interesting
to
you,
we'd
love
to
have
community
involvement,
so
the
more
of
the
merrier.
The
best
way
to
kind
of
get
involved
is
to
just
put
a
comment
in
there
saying
you
know
I'd
like
to
take
this
one,
because
you
have
to
be
a
part
of
the
open
source
reward
itself
for
us
to
assign
it
directly.
A
Unless
you
comment
on
the
issue-
and
we
can
do
that
once
you
comment
so
that
sounds
good,
also
yeah,
once
you
comment
and
once
you're
starting
to
submitting
a
pr,
we
also
recommend
you
know
just
becoming
a
part
of
their
work
and
joining
the
membership.
The
group
so
yeah
cool.
A
Cool
I'm
on,
I
see
you're
also
on
the
call
I
didn't
know.
If
you
wanted
to
jump
on
there,
that's
kind
of
trying
to
call
anybody
out.
D
Well,
yeah
I'll
just
introduce
myself,
I'm
a
man,
I'm
an
intern
for
aws
just
joined
very
recently,
so
yeah,
I'm
just
kind
of
here
absorbing
information
I'll
try
to
contribute.
I'm
still
obviously
learning
a
lot
but
yeah.
Hopefully
I
can
keep
contributing
throughout
the
term
and
yeah.
A
Well,
cool
yeah.
Likewise
welcome
to,
and
it's
great
to
have
you
yeah.
We
we
appreciate
all
the
help.
We
had
some
fantastic
contributions
from
other
aws
interns
in
the
past,
so
high.
A
Cool,
I
think,
that's
probably
it
I'm
planning
to
continue
on
work
in
that
metrics
api
refactor,
probably
with
the
baggage
stuff
being
my
primary
thing
to
focus
on
in
the
next
few
days,
but
otherwise,
just
continuing
on
with
that.
I
didn't
know.
If
there's
anything
else,
I
think
that's
one
of
the
most
pressing
things
we
can
get
the
let's
just
try
to
settle
a
little
bit
more
as
we
go
to
ga.
I
think
that's
a
important
thing
to
do.
A
Cool
well,
I
think
we
could
probably
call
it
a
short
one.
That's
actually
a
particularly
short
one
for
us,
but
yeah
people
can't
touch
on
all
the
points
and
I
don't
wanna
waste
any
more
time
than
we
have
to
from
anybody
else.
I'd
love
to
get
back
to
it
anyway,
so
cool
thanks
everyone
for
joining,
and
if
you
have
time
the
metric
stick
is
up
next
in
the
next
hour.
If
you
have
any
interest
in
open
source,
metrics
good
place
to
also
absorb
some
things
and
we'll
see
you
then.