►
From YouTube: 2020-07-30 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
B
A
B
So
we
can
probably
start
in
on
the
agenda.
If
you
have
any
points
you
wanted
to
address,
please
be
sure
to
add
them
to
the
agenda
and,
like
I
said
in
the
chat,
make
sure
you
add
yourself
to
the
attendees
list,
yeah
and
we'll
just
kind
of
jump
in
so
to
kind
of
start
it
off.
We
had
the
v010
release
go
out
officially
this
morning
and
it
was
pretty
awesome.
B
There's
been
a
lot
of
great
work
from
a
lot
of
people
that
was
included
in
that,
and
so
definitely
something
to
be
excited
about.
I
just
want
to
recognize
that
appreciated
a
lot
of
the
hard
work
that
went
into
that
still
need
to
get
out
a
contrib
release.
B
Hopefully
do
that,
let's
say
after
this
meeting,
but
I
forgot
it's
the
afternoon
meeting
so
maybe
tomorrow
morning,
and
so
I
think
that
should
be
coming
up,
which
is
good
because
I
think
there's
a
few
things
that
could
get
included
in
that
instrumentation-wise
and
that
kind
of
thing
so
yep,
that's
kind
of
on
the
plan.
I
don't
see
liz
on
the
call,
but
the
next
item
was
to
kind
of
go
over
something
that
lizzie
brought
up.
B
Let
me
see
if
I
can
share
my
screen,
though
yeah
yeah,
and
so
this
was
something
that
was
opened
ten
days
ago
at
this
point
and
the
idea
behind
it
is
there's
a
issue
also
associated
with
it.
B
That
is
that
the
key
value
array,
I'm
just
reiterating
things
that
I've
read
already.
I
don't
I'm
not
the
expert
on
it.
Liz
isn't
here
to
kind
of
talk
to
us,
so
I
kind
of
figured
we
might
as
well
just
bring
it
up,
but
it
just
not.
It
doesn't
actually
pass
a
copy
of
the
slice
slice
which
maintains
that
the
annoying
data
structure
is
mutated.
B
That
was
where
I
think
the
controversy
was
expected
to
come
in.
I
honestly
don't
care
one
way
or
the
other.
I
personally
think
that
we
should
just
kind
of
let
the
user
make
that
decision
and
let
it
pass
through,
but
my
feelings
are
not
that
strong.
So
if
there
was
strong
desire
to
have
this
disallow
multi-dimensional
raise,
I
I
I'm
okay
with
that
as
well,
but
yeah.
I
think
that
was
kind
of
the
main
point.
B
I
guess
we
could
probably
start
taking
a
look
at
this
if
there's
not
too
much
contention
here,
I
was
kind
of
hoping
this
was
going
to
be
here
to
be
able
to
speak.
B
That's
the
case
so
yeah,
maybe
that's
just
enough,
said
on
that
one.
So
moving
on,
let's
see
what
was
up
next,
oh
okay.
So
our
naming
convention,
I
think,
was
the
next
thing
I
kind
of
wanted
to
bring
up
probably.
B
Yeah,
so
currently
we
have
a
naming
scheme
that
works
really
well
for
discovery.
B
I
think
that
was
a
it's
a
smart
move
to
do
this,
where
we
have
the
full
package
name
listed,
underneath
the
the
prefix
of
the
contrib,
repo
plus
instrumentation
as
the
package,
I
think
that's
a
really
great
idea,
like
I
said,
for
discovery
purposes,
but
it's
a
horrible
idea
for
collision,
because
there's
pretty
much
guaranteed
to
be
one
other
package,
that's
going
to
get
imported
and
that's
the
package
that
we're
duplicating
the
name
of
so
that
definitely
is
not
like
the
end
of
the
world.
B
Obviously,
package
names
are
a
thing
in
the
go
spec
just
for
this
issue
to
deal
with
collision,
but
I
just
think
from
a
usability
standpoint.
I
was
wondering
if
maybe
we
can
possibly
do
better.
Some
of
the
things
I
was
kind
of
thinking
about
was
similar
to
some
of
the
test
packages.
We're
renaming
right
now
is,
we
could
add
an
hotel
suffix
to
all
of
our
instrumentation.
B
This
is,
I
think,
kind
of
a
useful
thing
because
it
would
delineate,
but
it
would
also
still
keep
the
the
naming
structure
in
a
way
that
is
recognizable
for
discovery,
but
I'm
also,
you
know,
maybe
people
don't
really
care,
that's
also
something
that's
viable,
and
then,
if
that
is
the
case,
we
wanted
to
add
a
suffixes
that
get
added
underneath
the
package
name
or
does
it
just
get
added
to
the
singular
package
name
kind
of
given
some
examples
here
I
didn't
know
if
anybody
had
any
opinions
on
that.
B
Yeah,
I
could
probably
put
this
in
an
issue-
maybe
that's
probably
a
better
place
for
this
and
then
we'll
kind
of
discuss
it.
There
probably
I'll,
recommend
to
add
the
suffix
on
the
end
and
again
like
if
anybody
has
any
strong
opinions,
I'd
love
to
hear
them,
but
yeah.
Maybe
we.
E
Do
this
asynchronously
yeah,
I
think
an
issue
in
giving
some
people
time
to
talk
about
it.
There
would
be
good.
I
I
agree
that
it's
definitely
a
problem
that
we
should
probably
address
because
we're
guaranteeing
a
conflict
here
and
I
I
don't
have
strong
opinions
either
way
on
how
we
solve
it
either.
B
Okay,
yeah
yeah
cool
all
right
I'll.
Take
the
action
item
to
create
an.
C
B
Cool
next
thing
was
all
the
instrumentation.
B
We
currently
have
a
little
bit
of
the
instrumentation
that
exists
in
the
main
repo
and
then
a
lot
of
instrumentation
is
starting
to
get
added
to
the
contrib
repo,
and
originally
that
made
sense,
because
there's
kind
of
like
some
core
libraries,
that
kind
of
made
sense
to
stick
in
the
main
repo.
But
I
don't
think
it
makes
sense
anymore
if
we
take
a
look
at
oh,
these
are
just
issues
and
such
a
hard
thing
to
do.
B
Yeah.
If
you
take
a
look
at
kind
of
the
instrumentation
that
already
exists
here,
we
have
definitely
third-party
libraries
that
exist
within
here,
especially
in
github,
there's
a
lot,
but
we
also
have
standard
library
stuff.
So
the
runtime.
This
was
a
really
cool
addition
here,
and
so
we
have
a
little
bit
of
a
mix
between
the
two
and
so
it
kind
of
makes
you
not.
It
makes
it
not
that
clear
where
the
delineation
falls
between,
where
we
want
to
put
something.
B
That's,
like
you
know,
standard
library
with
this
http
stuff
and
then
something
third
party,
which
is
also
something
third
party
in
the
main
repo,
and
I
was
originally
thinking-
maybe
just
put
all
the
standard
library
stuff
in
the
main
repo
but
then
think
through
it.
I
don't
know
why
we
have
any
instrumentation
in
the
standard
or
the
main
repo
I
feel
like.
It
could
just
also
live
in
the
control
repo,
and
that
would
be
a
centralized
point
and
then
it
wouldn't
have
any
sort
of
like
dependency
issues
or
or
bloatedness
to
the
actual
repo.
B
But
I
think
we
already
have
two
issues
tracking
the
existing
instrumentation
to
mood
all
there.
But
maybe
I
can
also
take
an
action
item
to
include
in
documentation
to
not,
you
know,
put
an
instrumentation
in
the
main
library,
but
put
it
into
the
control
repo
as
well
wondering
if
anybody
had
opinions
on.
B
B
Sorry,
my
video
screen
is
really
small,
so
somebody's
like
gesturing
to
me,
I'm
not
able
to
see
it.
I
apologize.
That's
just
computers,
you
know
they're
pretty
bad
in
general,.
E
E
I
think
there
was
a
metrics
test
helper
that
josh
was
working
on
that
that
might
help
getting
that
out
of
an
internal
package
in
the
main
repo
to
simplify
the
tests
in
the
http
handler.
So
I
think
the
only
thing
that
I
would
wait
on
to
get.
B
B
Man,
I
can't
remember
the
name
of
the
package
yeah.
I
think
it's
this
one
here,
yeah.
Let's
move
this
internal
test
hunter
into
something,
that's
yeah
exactly
yeah.
Maybe
we
should
try
to
prioritize
this.
B
B
Next
thing
was
some
of
the
feedback
that
we
got
a
little
while
ago
in
the
meeting.
One
of
the
things
was
unifying
the
start
and
options
for
the
figure
on
the
trace.
This
is
kind
of
I
think
it's
a
good
idea.
I
don't
know
if
there's
a
really
strong
desire
or
reason
why
they
should
not
be
the
same
options
passing
from
both
the
start
and
the
end.
I
I
think
that
maybe
the
idea
is
to
provide
some
sort
of
like
security
or
something,
but
I'm
not
exactly
sure.
B
If
the
instrument
is
the
one
who's
controlling
both
ends
of
that
pipeline,
then
it
doesn't
seem
like
a
problem,
so
it
didn't
make
too
much
sense
to
me
why
this
shouldn't
be
the
the
same
option.
So
I
just
wanted
to
see
if
anybody
else
had
understanding
that
was
different
than
I
do
on
that
one
before
I
wouldn't
try
to
accomplish
that
next
week.
D
Yeah,
I
guess
you're
saying
that
that
there's
no
reason
to
say
you
shouldn't
be
able
to
set
the
start
time.
In
the
end.
I
guess.
Oh
some,
probably
some
consideration
about
sampling,
but
I
don't
I
don't
buy
those
types
I
I
don't
buy
it
so
yeah.
I
think
that
that's
that's
fine.
With
the
exception
that
sampling
might
be
interfered.
B
Yeah,
that's
actually,
I
think,
an
active
question
right
now
that,
like
somebody,
wanted
to
set
a
sampling
decision
at
the
end
of
the
span
as
well,
so
I
think
that
the
spec
is
they're
also
grappling
with
this
question
so
yeah
I'll.
Keep
that
in
mind
when
I
take
a
look
at
this
because
sampling
that's
a
good
point
that
might
be
that
might
impact
that
so
yeah
yeah.
I
think
that
makes
sense
cool.
I
think
that
was
the
last
of
the
issues
that
I
had
for
the
meeting.
It
looks
like
conor.
A
Yeah
so
super
quick
one
just
because
we're
new
to
go
in
the
ecosystem
and
to
to
get
your
input
to
stay
consistent
with
other
packages
or
components
and
open
telemetry.
We're
wondering
what
your
guys's
thoughts
were
on
using
viper
to
parse
the
ammo.
It
seems
a
little
kind
of
heavy
for
our
use
case,
but
it's
used
in
the
collector
from
what
I
understand.
I
don't
know
if
you
have
any
other
recommendations
or
any
input
there.
Just
a
quick
little
question.
B
Yeah,
that's
a
great
question.
I
haven't
worked
too
much
with
viper
or
I
guess
that's
not
true.
It's
been
a
few
years
since
I
worked
with
viper,
so
I'm
not
the
most
first
on
the
best
practices
there.
I
do.
B
A
pretty
heavy
dependency
as
well.
I
think
that
what
bogdan's
saying
here
is
the
correct
approach,
like
all
of
our
exporters,
currently
have
other
their
own
modules.
It's
not
isolated,
and
then
it
just
becomes
a
question
of
whether
or
not
that's
decent
or
not.
I
think
that
if
you
isolate
it,
that's
kind
of
up
to
you.
B
D
Yeah
bogdan's
comments.
Fair.
If
you
want
this
dependency,
you
should
keep
it
to
yourself.
But
if
you
look
at
viper
it's
it's
got
it's
tremendously
heavy
and
it's
got
fcd
link.
It's
got
like
tons
of
stuff,
and
I
I
wonder
if,
if
there
probably
is
an
issue
sitting
in
the
viper
repository
saying
hey,
this
is
too
big.
Can
we
just
have
modules
so
that
I
can
just
get
yellow
support
and
not
pull
in
like
network
email
support
or,
like
you
know,
like
there's
lots
of
stuff
here.
E
Yeah
yeah,
just
being
able
to
get
emil
and
environment
variable
support
out
of
it
would
be
great
without
all
of
the
the
network
config
and
that
sort
of
stuff.
I'm
looking
at
the
mod
file
right
now.
It's
it's
huge
yeah,
that's
yeah!
The
mod
file
isn't
a
great
example
of
how
big
it
is.
Look
at
the
sound
file.
B
Yeah,
that's
just
ridiculous:
oh
man
yeah,
I
probably
wouldn't
use
it,
but
that's
I
don't
know.
I
feel
a
lot
of
people
wouldn't
have
used
our
sdk
prior
to
a
few
days
ago,
with
the
amount
of
things
that
we
included
as
well.
So
yeah.
B
E
D
B
Yeah,
that's
that's.
Actually.
My
experience
as
well
turns
out
gamble
is
pretty
hard
and
kind
of
underspecified,
but
that's
right.
B
I
this
is
exactly
the
story
that
I
went
through
as
well
like
it
started
with
go
yaml
then
I
was
like
wait,
a
minute
isn't
comments
supposed
to
be
supported
and
then
goyam
will
just
eat
some,
and
then
you
like
try
to
like
build
it's
yeah.
I
remember
this
being
a
nightmare
but
yeah,
I
think
connor.
I
think
we
in
in
the
ramblings
that
that
turned
into
gave
you
a
little
bit
of
pointers
on
direction
there
right
yeah.
D
B
That's
great
cool,
I
think
then,
moving
on
to
reg
you
put
on
the
agenda,
you
want
to
talk
a
little
bit
about
the
circle.
Ci
stuff.
C
Yeah
sure
so
I'm
just
looking
into
editing
the
config.yaml
circle
ci
to
support
the
test,
the
unit
tests
that
have
like
database
dependencies.
So
the
like
there
is
a
pretty
quick
and
easy
way
to
do
it
where
we
can
just
like
actually
add
a
flag
to
to
include
like
a
cassandra
and
a
container
during
the
testing
process.
C
But
I
think
I'm
wondering
like
is:
is
there
any?
Do
you
guys
have
any
idea
like
how
many
different
contrib
packages
are
going
to
be
needing
external
resources
like
this,
because
I
I
feel
like
that
method's,
probably
not
like
scalable?
I
guess
because
I
think
there's
only
so
many
containers
that
you
include
in
a
build
on
circle.
Ci.
C
E
Yeah,
so
I
think
that's
the
approach
that
the
jager
operator
takes
for
their
integration
tests,
and
that
seems
like
it's
probably
a
good
approach,
because
then
you
can
break
it
down
into
one
per
type
and
they
can
run
in
parallel.
C
Yeah,
I
believe
that
to
be
the
better
option
as
well.
Actually
that's
I
didn't
know
there
was
a
good
example
to
look
at.
So
it's
the
jaeger.
B
B
Yeah:
okay,
well,
awesome.
B
Yeah
anthony,
if
you
don't
mind
if,
when
you
do
find
it
just
put
it
in
the
google.
D
C
I
can
stick.
E
B
Awesome
that
looks
good,
I
think
yep,
that's
all
for
the
agenda.
Just
kind
of
open
up
the
floor
there's
a
lot
going
on
right
now.
In
this
thing
I
think
there's
probably
more
to
talk
about
here,
but
I
don't
think
I
had
anything
really
nailed
down.
So
I
just
didn't
add
to
the
agenda,
but
if
anybody
else
had
other
hot
issues
they
wanted
to
talk
about.
E
So
it
does
seem
that
most
of
that
is
because
internal
is
woefully
undercover.
Sdk
and
api
are
both
80
85.
So
it's
not
terrible,
but
some
work.
We
could
do
and
surfacing
that
with
every
pr
so
that
people
can
see.
You
know
how
much
they're
affecting
the
the
code
coverage
would
be
good.
B
Yeah,
I
completely
agree.
I
think
the
number
is
a
little
bit
arbitrary,
but
yes,
I
I
totally
agree
the
integration
should
happen.
I
put
a
comment
in
there.
I
think
the
way
that
he
was
trying
to
do
it
is
not
my
preferred
way
yeah,
but
I
I
totally
agree
as
well.
I
think
that
the
more
we
can
surface
on
that.
I
think
that
there's
just
like
a
lot
of
yeah,
I'm
super
excited
he's
actually,
including
those
things.
It's
been
really
nice
get
a
little
dusting
of
bonding.
B
It's
pretty
awesome,
cool,
yep,
yeah,
there's
also
a
few
other
pr's.
I
think
he's
added.
If
you
have
time,
go,
take
a
look.
Those
are
pretty
small.
Actually,
so
it
shouldn't
take
too
much,
but
I
think
otherwise,
like
review-wise
there's
not
actually
too
much.
Am
I
lying
about
that
yeah.
We
had
a
great
instrumentation
from
reg
get
merged
in
for
cassandra,
and
I
know
that
we
also
had
xam
had
forgetting
what
it
was
right
now.
Kafka
instrumentation
come
in
in
the
contrib
repo.
B
So
that's
pretty
awesome
again,
like
those
are
the
the
integration
that
a
lot
of
people
are
are
gonna
be
looking
for.
So
it's
awesome
that
we're
getting
a
lot
of
contributions
from
that
really
appreciate
it
yeah,
but
okay,
there's
seven
issues
open
currently
and
opens
ago.
I
don't
remember
any
of
these
being
particularly
large.
So
if
you
have
time
and
cycles,
please
go
in
and
review
them,
even
if
you're,
not
an
approver
or
a
reviewer.
Just
we
love
community
contributions,
so
yep.
B
I
would
encourage
that
otherwise,
yeah,
I
will
see
you
all
next
week.
I
don't
think
there
was
anything
else.
D
There
you
go
sorry,
were
you
announcing
the
metrics?
Oh,
I
think
yeah.
I
pressed
the
button
and
spoke
and
it
took
a
while.
Yes,
metric
sticks
in
half
an
hour,
I'm
I'm
hoping
that
we
get
bowdoin
should
be
there
and
we're
going
to
talk
more
about
otlp,
we've
merged
the
pr
that
he
had
open
and
it's
so
relevant
for
go
as
well
as
everything
else.
So
you
know
if
you're
interested,
please
please
join.