►
From YouTube: 2020-08-13 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
Hey
everyone
looks
like
some
people
are
starting
to
put
their
names
on
the
google
doc
for
the
meeting,
we'll
probably
start
in
a
few
minutes,
still
waiting
for
people
to
trickle
in
but
be
sure
to
follow
up.
And
if
you
have
any
additional
items
to
add
to
the
agenda,
please
do
so
and
probably
get
started
just
a
little.
A
A
A
Cool,
can
everyone
see
my
screen?
A
Yep
awesome
cool,
yes,
just
jumping
right
in
kind
of
want
to
start
out
with
a
shout
out,
there's
a
lot
of
prs
that
definitely
required
a
lot
of
attention
from
a
lot
of
people,
but
I
think
it
was
really
worth
it.
We
were
able
to
do
a
lot
of
movement
of
packaging
and
modules
and
things
and
brought
our
total
direct
dependencies
down
14
to
2,
including
removing
all
the
grpc
stuff
from
the
made
api,
which
is
really
awesome.
There
was
a
positive
reaction
in
the
linked
issue,
so
yeah.
A
Definitely
I
think
it
was
a
positive
boot
and
time
well
spent.
So
I
just
wanted
to
like
call
out.
I
always
appreciate
some
sort
of
user
giving
us
some
sort
of
validation
that
we're
doing
the
right
thing.
So
I
thought
it
was
really
cool.
I
want
to
make
sure
everyone
else
understood
that
it
was
appreciated
by
users.
So
congratulations
to
everyone
on
the
call,
yeah
and
then
kind
of
moving
on
with
that.
I
don't
know
if
liz
is
on
the
call.
B
I
added
this
words
and
she
opened
the
issue.
Oh
I
figured
this
might
be
a
good
place
to
talk
about
it.
Yeah.
A
That's
yeah
excellent
idea,
so
the
idea
is,
it's
gonna
open
up
the
issue,
the
wanted
to
do
a
release
in
the
contrib,
mostly
just
this
idea
that
we
moved
a
lot
of
instrumentation
over
there,
the
net
http
and
the
grpc
stuff
and
the
http
test
stuff
as
well,
and
the
idea
was
doing
a
point
release
here
so
that
migrations
can
happen
prior
to
just
a
hard
cut
in
the
instrument
or
in
the
hotel
projects.
So
seemed
like
a
really
good
idea.
A
Liz
pointed
out
that
she
was
able
to
use
a
point
release
as
well,
but
that's.
I
think
that
overall
is
a
great
idea,
there's
a
link
to
pr
to
actually
do
the
release
and
I'm
glad
you're
on
anthony,
because
I
wanted
to
kind
of
dig
into
this.
There's
a
request
in
some
of
these.
A
In
a
lot
of
our
go
mods,
we
do
this
replace
just
for
background
for
people
where
we
take
any
sort
of
contrib
package
or
contribute
module
and
replace
it
with.
What's
currently
in
the
repository,
that's
already
been
checked
out,
and
that
means
that
all
of
the
instrumentation
is
not
being
or
it's
not
referencing
the
released
version,
but
is
instead
referencing
the
local
copy
of
the
version
and
anthony.
Maybe
you
can
talk
a
little
bit
about
this
about
the
vision
for
208
here
and
all
that.
B
Yeah,
that's
something
that
the
ridge
had
noted
on
his
pr.
I
think
the
bigo
instrumentation,
which
is
that
it's
really
only
brought
in
so
that
we
can
depend
on
things
that
are
not
yet
in
a
released
version
of
the
instrumentation,
because
replace
directives
are
ignored
by
the
go
module
system,
except
at
the
top
level
package.
They
won't
ever
really
be
used
during
building
or
anything
like
that
unless
you
were
building
that
package
directly.
B
So
I
think
it's
really
only
useful
for
the
ci
system
during
the
interim,
where
we
started
depending
on
something
that
hasn't
yet
been
released
in
a
tagged
version,
and
since
all
of
these
things
should,
with
the
exception
of
you,
know
the
bigo
and
the
net
http
instrumentation,
which
are
depending
on
the
metrics
helper,
which
wasn't
in
point
10.
I
think
all
the
rest
of
them
probably
can
have
their
their
replace
directives
removed.
A
Yeah,
I
think
that
makes
sense.
I
am
kind
of
interested
to
better
understand
the
if
it
does
break
when
you
do
a
point
release
like
this,
but
the
the
idea
is
that
if
you
put
out
something
that
is
going
to
depend
on
a
version,
that's
not
actually
already
there.
I
think
I
think
it
would
only
break
as
long
as
this
got
merged
and
before
I
or
before,
like
somebody
tagged
that
new
version,
which
is,
I
feel
like
small
enough-
that
it's
not
really
an
issue
but.
B
A
A
Well,
not
this
one
but
the
other
one,
and
so
I've
kind
of
not
given
it
too
many
thoughts,
but
I
could
probably
I
think
that
I
think
we
could
probably
do
this
release
without
having
to
tackle
this,
as
you
can't
point
it
out
just
to
be
on
the
safe
side,
but
we
should
probably
dig
in
just
decline
and
clean
this
up
in
the
future
or
make
it
clear
that
we're
not
going
to
clean
it
up
because
they
don't
do
anything
or
what
their
purpose
is.
A
I
think
is
probably
a
good
idea,
but
yeah,
I
think
that's
that's
a
useful
point
to
make,
but
yeah
is
that
sound
good,
anthony.
B
Yeah
yeah.
That
sounds
good
to
me.
I
just
think
it
was
a
question
that
was
brought
up
and
we
should
probably
make
a
decision
and
document
it
somewhere
so
that
the
next
time
the
question
comes
up.
We
have
a
place
to
plan.
Yes,.
B
Right,
so
something
that's
using
this
instrumentation
when
that
is
built,
the
replace
directive
from
this
instrumentation
will
be
ignored
because
go
modules
only
honor
a
replace
directive
from
the
module
being
built,
not
any
of
its
dependencies.
Gotcha.
Okay,.
D
We've
discussed
having
a
vanity
domain
for
a
contrib
directory.
Haven't
we.
D
Okay,
so
does
that
mean
all
the
top?
All
of
the
so
go
to
open,
telemetry
dot,
io
contrib
is
mapped
now
to
the
github
hotel.
Go
directory,
yeah.
A
D
Yep
that
was
a
little
while
ago.
I
think
you
can
see
how
much
I'm
paying
attention
all
right,
no
worries.
D
Oh
I
like
that
I
was.
I
was
hoping
that
that
was
going
to
happen.
I
I
think
I
understood
what
was
being
discussed
and
it
sounds
good.
A
Okay,
yeah.
I
agree.
I
I
think
the
last
step
regardless
just
document
whatever.
The
conclusion
is,
I
think,
is
critical
or
just
really
important.
I
think
it's
a
good
idea
cool
so
I'll
try
to
get
that
out
after
the
metrics
meeting
in
a
little
bit
but
yeah,
I
don't
think,
there's
any
other
blockers.
You
should
be
able
to
get
that
release
out
and
then
tackle
some
of
this
other
work
I'll.
A
These
things
to
the
regis
issue
as
well
to
try
to
make
sure
that's
clear
what
we
need
to
do
cool
so
moving
on
the
next
thing
I
wanted
to
ask
was
sorry.
Last
week
I
wasn't
able
to
attend,
unfortunately,
a
scheduling
conflict,
but
there
was
a
proposal
I
saw
and
right
afterwards
to
have
josh
be
replaced
with
anthony
on
this.
I
just
want
to
kind
of
touch
base
and
see
if
you
can
prioritize
that
if
that
needs
to
happen.
A
You
need
to
say
that
you're
willing
to
accept
the
responsibility-
I
guess
but
other
than
that.
I
guess
it's
more
just
just
wanted
to
make
sure
that
we're
all
on
the
same
page
and
maybe
I'll
start
putting
in
the
issues
and
that
kind
of
stuff.
Afterwards.
D
Yes,
I
am
yeah,
I
I
appreciate
this
sorry
to
interrupt.
Yes,
I
I
think
it
will
help
everybody
if
I
am
not
in
the
maintainer
role,
although
it
looks
like
I've
been
really
active
this
week.
I,
like
that's
just
coincidence,
because
of
some
deadlines
that
I've
been
placed
under
and
I
haven't
been
able
to
contribute
as
much
over
the
last
month
as
I
think
I
should,
or
that
the
project
needs.
A
Okay,
I
can
I'll
take
this
as
a
task.
A
Cool
and
with
that
I
will
keep
going
the
proposals
I
posted
last
week.
It
looks
like
anthony,
took
a
look
as
well.
I
haven't
seen
much
movement
on
a
lot
of
these,
so
I
kind
of
just
want
to
get
them
merged
because
I
think
some
of
them
are
going
to
be.
I
don't
think
some
of
them
are
definitely
going
to
be
breaking.
All
of
them
are
going
to
be
breaking
changes,
so
the
sooner
that
we
can
try
to
tackle
these,
I
think
the
better.
A
To
start
there
was
an
instrument
package.
Naming
convention
talked
about
this.
I
think,
maybe
for
two
weeks
now,
the
idea
being
that
all
of
our
instrumentation
is
guaranteed
to
collide
with
the
package
that
it's
instrumenting,
which
is
not
a
really
great
user
experience.
There's
a
few
options
that
were
added
here.
A
The
last
one
was
kind
of
the
one
that
I
saw
some
consensus
on
the
pattern
being
that
if
the
instrumentation
is
something
like
the
runtime
in
the
standard
library,
then
you
would
have
some
suffix
or
prefix,
which
we'll
get
to
in
just
a
second
of
hotel.
On
that,
similar
to
the
gorilla
background,
you
can
kind
of
see
some
examples
here.
A
It
probably
is
easier
to
just
see
the
examples
than
have
me
explain
it
because
I'll
probably
mess
it
up,
but
the
only
open
question
is
rey's
anthony
pose
instead
of
doing
prefix.
A
I'm
sorry,
which
one
did
you
say
suggest
I
tell
from
a
suffix
yeah.
So,
instead
of
doing
a
suffix
use
a
prefix
which
I
have
very
little
opinion
on.
The
reason
I
originally
proposed.
Suffix
was
mostly
just
to
follow
the
other
testing
stuff
that
we
did
where
we're
now
putting
tests
at
the
end
of
packages.
But
I
honestly
am
I
don't
care
that
that
part
is
if.
B
Yeah,
I
don't
know
how
strong
my
preference
is.
It's
just
as
a
prefix,
it
kind
of
reads
better
to
me
and
it
seems,
like
it'll,
be
a
little
more
consistent.
You
know
tell
this
hotel
that.
A
Yeah
that
makes
like
I
said
like
that,
makes
sense
to
me
as
well.
So,
but
I
really
don't
care,
is
there
anyone
else
on
the
call
who
has
a
preference.
A
Okay,
I
think
we're
gonna
go
with
prefix.
That
sounds
good
and
then
I'll
make
sure
to
blame
anthony
when
somebody
complains
about
that.
No
I'm,
just
starting
that's
a
community
choice,
don't
interpret
that.
That's
not
a
joke.
The
next
one
is
renaming
the
global
package.
A
I
think
that
there
was
not
a
really
strong
suggestion
base
for
this,
which
is
reasonable,
because
I
like
it's
unfortunate,
because
I
think
this
name
is
a
common
name
but
like
it
is
describing
the
purpose
of
this
package,
and
so
I
kind
of
think
it
should
remain
so.
I
kind
of
just
want
to
close
this
one
out
and
saying
that
we're
not
going
to
change
it,
and
I
think
the
last
comment
was
seven
days
ago.
So
I
don't
think
there's
any
strong
reasoning
here.
A
If
you
have
strong
reasoning
and
you're
on
the
call,
please
make
sure
you
add
info
to
that
I'll,
probably
close
the
package
or
close
the
issue
tomorrow.
Next
one
was
the
kb
package.
Kb
was
kind
of
a
generic
name,
and
I
was
realizing
after
josh
submitted
a
pr
for
map
included
with
the
dimensionality
reduction
stuff.
There
was
a
chance
that
we
could
just
merge
the
kb
in
the
labels
package.
A
The
labels
package
is
kind
of
the
functional
elements
of
the
kb
anyways,
so
having
them
in
a
similar
package
sounds
good
to
me
and
then
having
something
cohesively
called
labels
also
is
maybe
subtly
trying
to
hint
at
the
fact
that
the
specifications
should
also
call
something
you
know
in
a
uniform
labels
way,
but
that's
a
totally
different
meeting
entirely
but
yeah.
I
don't
know
if
anybody
had
an
opposition
to
this.
B
One
yeah,
I
think
I
have
a
slight
preference
for
labels
over
kv
if
we're
gonna
merge
them
and
pick
one,
because
it
seems
more
descriptive
of
what
it's
doing
whereas
kv
is.
B
A
Yeah,
I
think
that
another
element
of
the
labels
packages
includes
things
like
the
set
and
iterator,
so
it
kind
of
rolls
off
the
tongue,
and
it
has
the
labels
give
context
to
that.
So
it's
the
label
set
it's
the
label
iterator,
so
those
kinds
of
things
really
make
sense
so
having
something
like
a
labels
key
or
a
labels
value.
I
think,
just
like
you
said
that
kind
of
rolls
off
the
tongue
with
context
for
somebody
who's
new.
A
Cool
sorry,
somebody
else
jumping
in
there,
no
okay.
So
then
the
next
one
was
the
b3
package.
This
one
I
probably
wouldn't
get
to
for
a
little
while.
So
it's
not
as
critical
and,
of
course,
that
just
but
the
idea
was
there
was
some
there's
a
little
bit
of
confusion
in
the
confusion
and
specification
that
is
shared.
A
I
share
with
anthony
on
this
one
about
what
is
actually
specified
for
implementation
of
propagators,
but
I
think
the
fact
that
we
have
the
b3
already
means
that
we
should
keep
it
somewhere,
probably
not
in
the
main
api
is
a
good
suggestion
as
well
so
moving
it,
I
think,
to
the
contrib
and
creating
the
new
propagators
package.
A
This
also
means,
I
think,
bog
didn't
asked
for
a
grpc
binary
propagator,
but
that
I
think
was
also
there's
another
issue,
for
that
I
was,
I
think,
correctly
asked
to
be
maybe
some
help
from
the
grpc
people
and
folks,
but
it
would
fit
well
in
that
package
scheme,
I
think,
is,
is
the
point
I
was
trying
to
make
so
yeah.
I
think
that
we'll
probably
close
this
with
that
decision
as
well.
B
So
one
question
I
might
have
about
naming
for
the
propagators
package
is:
is
there
a
go
b3
package
that
we
would
have
to
slot
under
our
naming
convention,
or
would
this
deviate
from.
B
A
Yeah,
that's
a
good
question
and
that
is,
I
think
that
question
always
comes
up
when
we
talk
about
propagators
as
to
like.
What's
a
good
naming
scheme,
it
happened
as
well
with
the
w3c,
because
then
you
have
this
idea
of
trace
context,
but
is
it
w3c
trace
context?
But
then
w3c
is
like
a
standards
body
and
it's
not
really.
I
don't
know
so,
there's
a
really
tough
scoping
here.
I
don't.
I
think
it's
that's
a
tough
question.
There
isn't
a
a
a
package.
A
This
is
implementing,
there's
a
specification,
that's
implementing
and
it's
the
the
zipkin
specification
right
for
b3
and
that
is
in
another
repo.
But
there's
not
like
an
implementation
that
this
is
actually,
I
think,
directly
referencing.
So
it's
somewhat
unique.
Sorry.
A
Cool,
I
agree
with
that,
so
I
think
we'll
probably
put
a
package
number
in
here
called
this
prefix
and
then
maybe
just
b3.
I
think
it
sounds
reasonable
to
me,
but
I
guess
whoever
picks
up
the
issue
gets
to
make
that
choice.
I'm
fine
with
that
as
well
cool.
Okay.
I
think
that
was
the
most
of
the
rfcs.
I
wanted
to.
A
Open
long
enough
and
they
need
to
kind
of
get
moved,
the
next
one
was
something
that
kind
of
came
up
with
an
issue
I
saw
from
bogs
in,
but
they
kind
of
realized
that
we've
been
doing
this
in
a
few.
A
Quite
a
few
different
places
is
the
idea
that
a
lot
of
the
instrumentation
we
have
accepts
a
tracer
or
a
meter,
or
even
propagators
themselves,
as
configuration
options
for
the
instrumentation,
and
this
doesn't
make
sense,
given
the
fact
that
we
built
a
globals
package
to
handle
this
kind
of
thing,
let
alone
the
fact
that
the
design
of
having
a
tracer
be
coupled
with
instrumentation,
meaning
that
the
tracer
name
and
the
tracer
version
should
be
a
intrinsic
thing
of
the
instrumentation.
The
instrument
transportation
itself
should
define
that
it
doesn't
seem
in
line
with
this
model.
A
So
I
think
that
I
opened
this
issue
to
try
to
address
that
and
change
that
we've
seen
a
few
instrumentation
packages
go
by
that
also
identified
this,
and
instead
of
accepting
a
tracer,
they
accepted
a
trace
provider
and
I
think
that's
the
correct
approach
to
go
here.
I
also
think
that
that
might
be
an
add-on
step
that
may
not
be
a
default
necessary.
I
think
the
default
of
using
the
global
trace
provider,
the
global
trace
our
meter.
A
Or
even
the
global
propagators
is
probably
a
great
at
least
mvp
and
maybe
even
long
term,
because
I'm
not
too
sure
how
much
users
are
going
to
want
to
change.
You
know
by
instrumentation
that
the
providers
were
the
propagators,
the
propagators
I'm
not
as
sure
about,
but
that
the
providers
doesn't
seem
too
likely
to
me.
But
I.
A
At
the
bottom
of
this
to
kind
of
capture
some
of
the
propagator
versus
provider
options
as
well,
but
I
think
it
needs
to
get
added
work,
and
one
of
the
things
that
I
identified
here
was
just
updating
that
instrumentation
guidelines
that
we
already
have
that's
pretty
critical
so
that
we
stop
implementing
this
pattern,
I
think,
is,
is
pretty
useful
kind
of
the
same
thing
that
we
decided
with
the
replace
directives.
D
I'm
curious
if
you
think
that
these
plugins
should
take
providers
as
as
opposed
to
using
the
global.
D
D
This
is
a
good
issue
and
I
think
that,
like
I'm
looking
at
the
runtime
plug-in
right
now,
because
we
need
it-
and
you
know
it
takes
a
meter
or
you
know,
as
opposed
to
a
meter
provider,
and
that
does
exactly
what
you
said
we
shouldn't
be
doing,
and
I
and
I
noticed
it
so
I
feel
like
either
we
should
pass
a
meter
provider
and
it
should
name
itself
and
have
its
own
december
or
actually
that's
what
I
think
we
should
do
as
opposed
to
letting
get
used
to
global
okay
yeah.
D
Go
ahead.
Sorry
so
the
way
I
think
about
it
is
that,
like
the
the
u7
global
is
to
allow
kind
of,
as
close
as
we
can
get
to
auto
instrumentation
and
go
like,
but
these
plugins
are
kind
of
are
not
are
not
that
these
are
like
modules
that
you
can
use
in
your
instrumentation
and
you're
tracing
in
metrics
pipeline,
and
you
may
not
want
to
use
global
and
if
you
don't
want
to
use
global,
these
aren't
going
to
be
the
right
thing
for
these.
B
I
think
having
the
instrumentations
use
the
global
provider
as
a
default,
if
a
provider
isn't
given
to
them
is
a
good
compromise.
So
that
way
we
do
get
closer
to
the
hands-off
instrumentation.
You
just
you
know,
wrap
your
handler
with
this
middleware
or
something
like
that
right
and
you
don't
have
to
think
about
it
too
much.
But
if
you
do
have
a
special
use
case
and
you
want
to
change
the
provider,
you've
got
the
hook
there
to
do
it.
A
Yeah
that
all
sounds
good
to
me.
Actually
I
I
I
wrote
this
and
then
I
thought
about
it
afterwards
that,
like
yeah,
you
probably
want
to
have
some
sort
of
configuration
for
accepting
provider
just
like
you're
talking
about
josh
and
anthony,
but
I
probably
didn't
capture
that
second
thought
as
well,
so
I'm
gonna
all.
I
think
that
I
like
that
idea,
I'll
go
back
and
I'll
reword
this
issue,
but
yeah
it
needs
to
get
done
as
well.
I
think
that's
important.
A
We
want
to
have
those,
I
should
I'm
really
bad
at
writing,
and
but
yes,
the
the
decision,
as
far
as
I
understand,
is
that
we
will
recommend
that
each
instrumentation
have
a
with
provider
with
meter
with
trace
provider
or
with
metric
provider
option,
and
that
will
accept
it.
They
should
not
have
a
width,
tracer
and
a
width
meter
option,
though,
and.
D
A
Yeah,
okay,
cool
thanks
yeah!
That's
we
want
to
make
sure
that's
clear,
yeah
and
then
the
last
thing
I
noticed
was
also
that
there's
only
like
one
packet,
that
is
using
the
instrumentation
version.
We
should
probably
do
a
better
job
at
this
one.
Given
eventually,
we
need
to
build
functionality
to
try
to
disable
or
modify
telemetry
based
on
instrumentation,
so
it
should
probably
start
making
that
into
instrumentation
again.
B
B
Where
we
should
have
a
a
constant,
a
single
constant
at
the
top
level
package
that
everything
refers
to.
A
Yeah,
that's
a
that's
kind
of
I
captured
a
little
bit.
That
was
my
thought
as
well.
This
might
be
a
per
instrumentation
thing,
but
it
also
might
be
that
there
should
be
a
centralized
play
similar
to
like
the
hotel
repo,
where
there
is
a
version
like
a
version
in
like
the
top
level
module
or
something
like
that.
That
instrumentation
could
then
reference
saying
that,
like
I
was
built
with
this
nerve
version
or
something
like
that,
so
they
can
track
the
control,
replace
version.
A
I
think
that
sounds
like
a
reasonable
approach,
but
I
feel
like
maybe
some
instrumentation
wants
to
do
their
own
release
cycles
or
something
like
that.
So
actually
maybe
we
shouldn't
have
that
choice.
Maybe
there
should
be
a
unified
decision
on
what
that
should
be,
because
I
feel
like
we're
the
instrumentation
writers
or
the
curators
of
that
instrumentation.
So
maybe
it's
up
to
us
to
make
that
decision.
What
do
you?
What
do
you
think.
B
Yeah,
at
least
for
this
repo,
I
I
think
they're
they're
always
going
to
be
released
with
lockstep
versions.
Because
of
the
way
we
do
the
tagging
and
release
process.
So
we
should
probably
just
have
a
single
version
that
can
be
referenced
by
them,
and
it
might
also
be
useful
if
we
can
update
the
build
process
to
inject
that
dynamically.
When
we
build
like
out
of
a
get
tag,
you
know
they
get
commit
in.
A
Yeah,
I
I
completely
agree:
there's
probably
won't
find
it.
It's
really.
It's
a
it's
an
obscure
part
of
this
code,
but
there's.
A
Described
already
in
the
go
repo
where
there's
like
a
version-
maybe
it's
a
variable
right
now,
but
yeah
having
something
similar
in
the
contrib
repo,
where
you
can
just
kind
of
reference.
It
and
okay
yeah
I'll,
make
sure
to
update
the
issue,
to
say
that
we
want
not
per
instrument
versioning
but
as
a
collective
repository
versioning,
and
that
needs
to
be
included
in
the
instrumentation.
A
A
Yep,
okay,
everyone!
Well
thanks
for
joining
again
awesome
work
and
I'll,
see
you
all,
probably
in
the
metric
hall
or
online
just
a
bit.
Everyone.