►
From YouTube: 2021-11-11 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
Yeah,
it's
yeah
active
but
yeah,
it's
good
good.
To
have
a
little
time
off.
Yeah
I
heard
I
didn't
hear.
I
saw
on
last
week's
meeting
notes.
We
got
a
an
official
announcement
of
your
new
position.
C
Nice!
Congratulations!
Man!
Oh
thank
you!
Yeah!
That's
super
exciting!
I'm
I'm
excited
to
see
you
very
actively
paid
for
working
on
this
stuff
because
you
know,
I
think,
that's
worth
it.
C
Yeah
yeah,
whenever
everyone
else
is,
I
thought
I
was
late,
but
I
guess
not.
It
is
veterans
day.
I
do
wonder
if
a
lot
of
people
have
it
off.
I
guess
good
question.
A
C
That's
really
funny
yeah.
We
had
this
monday
off,
but
we
didn't
yeah.
I
don't
know
it's.
I
appreciate
the
time
off
wherever
it
comes
right.
C
Yeah,
I'm
sure
that's
a
little
harder
when
you
have
kids
at
the
house
yeah,
because
I'm
just
like
well
kind
of
have
to
do
a
little
bit
of
slight
time
off
just
to
handle
that
yeah
yeah
yeah.
C
Well,
I
don't
know
if
anybody
else
is
gonna
show
up
or
four
minutes
into
this.
I
definitely
think
that
we
could
talk
about
some
things.
There's
some
david.
We
can
include
david
here,
but
yeah.
I
definitely
wanted
to
talk
a
little
bit
about
some
of
the
stuff,
that's
ongoing,
so
why
don't?
We
start
it
off
I'll
start
sharing
my
screen.
C
Cool
so
first
things.
First,
I
added
this
based
on
the
kind
of
the
conversation
we
were
having
this
morning
in
some
of
those
depend
upon
updates.
The
idea
of
supporting
go.
115
may
eventually
cause
us
problems,
because
we're
pinning
ourselves
so
far
back
that
it's
it's
a
tough
one
I
like
to
just
bring
it
up.
C
I
think
I've
got
some
ideas
of
how
to
approach
it,
not
necessarily
a
solution,
but
just
how
I'd
want
to
like
go
about
the
discussion,
but
I
just
wanted
to
open
up
the
floor
and
see
about
opinions
on
this
one.
A
So
though
I
I
want
to
point
out
that,
while
it
this
came
up
because
of
the
lint
ci
or
whatever
it
is,
that's
not
actually
going
to
bring
are
our
sdk
and
apis
to
require
go
116,
because
that's
only
part
of
like
our
lint
and
and
code
check-in
process.
A
So
our
yes,
we
it's
a
good
discussion
to
have,
but
it's
sort
of
only
kind
of
a
discussion.
It
just
means
you
can't
run
like
the
pre-commit
in
go
115,
because
that
requires
116.
C
Yeah
and
I
think
yeah,
I
guess
there's
kind
of
two
issues
here.
Maybe
it's
like
we're
not
really
forced
on
the
issue,
just
based
on
what
you're
saying
and
I'm
totally
on
board
for
like
if
you're
a
developer
on
this
project,
you
need
to
have
you
know
within
like
the
last
two
supported
versions
of
go.
C
I
think
that's
totally
fine
and
then
there's
the
other
host
of
problems
where,
if
you
take
a
dependency
at
open
telemetry,
then
if
we
are
continually
updating
what
our
minimum
version
is,
that's
going
to
impose
something
on
you.
I
I
don't
know
if
that's
particularly
that
much
of
a
problem,
but
I
think
it's
something
that
we
should
probably
address.
C
I
think
that
this
pr,
which
is
where
this
kind
of
came
up,
can
get
merged
as
aaron
kind
of
pointed
out
that,
like
we
can
resolve
this
by
saying,
like
our
build
version,
we
use
116
currently
or
it
would
change
in
this
pr
and
we
still
do
backwards,
compatibility
checking
with
go
115
in
our
compatible
or
yeah
compatibility
tests,
or
something
like
that.
I
think
they're
called
compatibility,
and
I
think
this
works,
but
it
does
raise
the
question
right
so
like
what
happens
when
one
of
these
dependencies.
C
A
C
Yeah,
I
wonder
how
so
that's
also
another
good
question,
so
maybe
we
could
try
to
dig
into
how
they're
going
to
release
the
generics
and
other
language
features
that
are
absolutely
desired,
because
I
agree
like
there's
a
lot
that
we
could
clean
up
if
we
had
generics,
but
it
also,
I
think,
would
break
the
api
in
many
ways
if
we
wanted
to
redesign
things
using
generics.
So
I
can
see
that
also
being
something
to
be
included
in
the
2.0
and
if
go
upstreams
it
as
a
2.0
anyways.
C
Then
maybe
there
is
a
good
time
to
have
a
partition
that
you
know
there's
so
many
questions
open
right
there
in
that
statement,
that's
really
hard
to
say,
but
I
think
that's
a
good
one.
C
I
do
think
that
if
we
did
have
to
bump
the
minimum
version
from
115
to
you
know
higher,
I
think
that
it's
not
as
dramatic
just
because
I
think
the
as
long
as
we
don't
have
it
so
that
it
goes.
You
know
from
115
to
2.0
of
go
which
doesn't
exist
currently,
because
then
there's
breaking
changes
right
so
like
well.
C
Potentially
I
mean
if
they're
following
december,
there's
going
to
be
breaking
changes,
which
I
don't
think
the
go
team
really
wants
to
do,
but
one
of
the
guarantees
that
go
does
make
is
that
their
backwards
compatibility
guarantee
for
the
you
know,
1.0
version
of
go,
and
I
think,
if
that's
strong
enough
for
us
to
say,
like
yeah,
expecting
users
of
this
project
to
say.
Okay,
if
you
want
to
upgrade,
you
know
from
open
cemetery
1.1
to
1.7.
C
I
don't
know
wherever
we're
at
when
this
happens
right,
also
making
sure
that
you
upgrade
your
version
of
go
that
you
use
is
going
to
be
a
requirement
of
that
upgrade.
I
think,
if
that's
fair,
given
it's
it's
compatibility.
Guarantees
like
you
should
be
able
to
do
that
upgrade
and
not
have
any
issues.
C
D
C
Yeah,
I
think
that's
a
good
way
to
frame
it
right.
That's
a
yeah
in
the
same
way
that
like
they
would
probably
when
they
upgraded
open
symmetry
they'd
want
to
audit
what
you
know
those
differences
came
in
and
their
security
team
has
to
audit
it
anyways
right.
Like
that's
a
that's
a
good
point,
I
think
it's
worth
making
making
a
you
know
a
saving
amount,
let's
open
it
up.
I
haven't
heard
it
from
anthony
or
evan,
either.
E
Yeah,
so
I
I
think
that
we
should
never
move
our
minimum
supportive
version
beyond
the
oldest
supported
upstream
version.
It's
like
right
now
go
upstream
supports
116
and
170..
I
wouldn't
advocate
moving
right
now
to
have
our
minimum
version
be
170
or
when
it's
118
comes
out.
We
shouldn't
say
our
minimum
version
is
18,
because
we
want
to
take
advantage
of
those
features
we
need
to.
We
need
to
give
some
time
for
for
them
to
soak
and
for
them
to
bake
and
people
to
actually
be
able
to
validate
those
releases.
E
So
by
the
time
119
comes
out
start
using
118
features
and
ease
it.
I
think
we
need
to
be
a
little
conservative
there,
but
we
we
also
can't
be
so
conservative
that
we
end
up
getting
stuck
behind.
I
think
there
was
already
a
ceramic
dependency
that
we've
had
to
skip
updates
on,
because
it
depends
on
116
now
and
with
our
minimum
version
being
115.
We
couldn't
do
that
update
so
there's
an
instrumentation
package.
That's
behind
on
independence,.
F
C
Yeah
I'd
like
to
do
more
if
we
can,
just
because
it
enables
a
wider
audience,
I
guess
with
less
user
friction,
but
I
do
think
that
we
should
set
the
bar,
and
I
think
it
should
be.
I
don't
know
lower
high
depending
on
how
you
want
to
call
it
but
like
if
there
are
language
features
that
we
really
think
would
benefit
the
projects.
That's
a
good
enough
reason
to
say,
like
our
minimum
version
is
going
to
go
up
right.
C
If
there
are
dependencies
like
we're
finding
that
are,
we
need
to
like
try
to
stay
current.
We
try
to
try
to
make
sure
they
include
all
security
updates.
That's
a
good
reason,
but
if
there
really
isn't
like
anything
like
there's,
no
reason
that
we
want
to
use
a
different
language
feature,
there's
no
dependency
that
we
have
that's
requiring
this
update.
C
We
probably
shouldn't
just
update
to
like
whatever
the
the
second
oldest
version
is
just
because
I
think
it
like
it
doesn't
really
behoove
us
right,
like
our
user
base,
is
just
shrinks
a
little
bit
for
really
no
added
benefit
other
than
we're
in
lockstep
with
upstream
go
right.
F
C
When
the
time
comes,
I
think
that
we
could
probably
spell
it
out.
I
think,
there's
I
don't
know
those
are
the
two
things
that
I
just
saw
were
like.
Those
are
the
good
reasons
you
know
if
like.
If
we
really
want
something
from
the
language,
that's
in
the
upstream,
we
should
do
that
and
if
we
really
want
you
or
our
dependencies
already
done,
that
like
we
can
just
kind
of
assume
our
dependencies
are,
are
doing
a
very
similar
policy
and
like,
if
they've,
already
updated,
we
want
to
keep
current
with
those
dependencies.
C
Then,
let's
make
sure
that
we
upgrade
at
that
point,
which
is
in
reality,
probably
just
going
to
be
like
we
keep
with.
You
know
the
last
two
minor
versions,
because
I
imagine
upstream
people
are
doing
that
is
similar
but
yeah.
I
think
those
are
the
two
that
I
can
come
up
with,
like
the
only
time
that
I
would
say,
like
don't
do.
That
is
if
no
one
has
a
good
reason.
Like
you
know,
a
good
enough
reason
is
not
because
upstream
only
supports
these
two
back.
C
I
think
that
if
upstream
only
forces
you
back
and
there's
a
security
vulnerability
and
further
back
like
yeah,
that's
another,
that's
another
really
great
reason,
but
if
it's
just
because
we
want
to
remain
in
the
same
window
as
option
go,
I
don't
know
if
that's
a
good
enough
reason.
That's
like
the
only
reason
I'm
like.
I
don't
think
that
that's
like
useful
aaron's
taking
notes.
I
appreciate
that
as
well
aaron.
One
of
the
things
also
is.
I
think
that
this
is
a
great.
C
I
wanted
to
have
a
little
bit
of
discussion
here,
but
I
think
we
should
probably
make
sure
that
this
is
captured
in
an
issue
so
that
this
conversation
can
happen.
Asynchronously.
I
think
a
large
problem
that
I'm
noticing
is
that,
like
more
people
are
excited
about
the
project
and
we
already
have
developers
and
contributors
in
other
time
zones,
I
don't
want
a
decision
to
be
made
in
this
meeting.
C
Rather,
I
just
want
to,
I
think,
we're
discussing
all
the
relevant
and
sailing
points,
but
we
should
probably
capture
this
in
an
issue
so
that
we
can
have
an
asynchronous
conversation
about
this
and
and
ultimately
define
a
policy
that
encompasses.
This
was
my
goal.
E
So
I
think
one
reason
that
I
think
might
be
a
good
reason
just
to
stick
to
the
last
two
versions
and
kind
of
mechanically
upgrade
is
that
rci
process
is
going
to
eventually
grow.
We've
already
seen
this
we've
got
three
versions
ago
that
have
required
tests
now,
which
means
there's
three
chances
for
any
test
flight
to
flake
out
there's.
You
know
the
time
that
it
takes
there.
The.
C
I
think
that's
a
fair
point.
My
my
gut
reaction
is,
I
really
wish
our
tests
were
flaky
and
I'm
hoping
to
try
to
work
to
make
that
the
case,
but
that's,
I
think,
fair.
I
think
that's
a
fair
point
like
just
in
the
overall
overhead
that
it's
going
to
add
not
only
just
in
the
flakiness.
E
Yeah,
I
I
don't
certainly
mean
to
excuse
flaky
tests
and
say
you
know,
we've
got
them,
so
we
need
to
to
go
around
them
in
other
ways.
We
should
absolutely
be
trying
to
explain
the
tests,
but
they're
also
a
reality.
They're
a
thing
that's
going
to
happen,
and
you
know,
even
if
we
fix
them
fairly
quickly
having
more
more
times
that
we
run
each
individual
test
is
more
times
that
a
flight
can
flake
out.
C
E
They
haven't
upgraded
yet
or
you
know
there
isn't
anything,
that's
forced
them
to
operate
yet
you
know
I
I've
certainly
been
in
that
situation
before
I'd
like
to
try
to
stay
up
to
date,
but
it's
it's
also.
You
know
if
you've
got
a
bunch
of
applications
and
you
need
to
go
and
update
them
all
that
can
be
effort.
E
You
just
don't
have
the
time
to
put
it,
which
is
part
of
why
I
say
we
should
be
at
least
two
behind
right,
so
also
so
that
we're
not
forcing
people
onto
leading
edge
because
there
are,
there
are
groups
who
will
signal.
E
I'm
never
gonna
take
a
a
zero
right,
I'm
going
to
wait
for
at
least
the
first
point
before
I'm
going
to
update
to
the
newest
version,
and
so,
if
you
know,
god
forbid,
we
ever
jump
to
you
know
118,
it
releases
generics
and
we
say:
oh,
we
really
want
to
nurse
we're
going
to
use
it
right
now
and
we're
gonna
go
on
dot
zero
and
you
have
to
use
118
if
you
wanna,
if
you
wanna,
use
hotel
now
that
would
be
cutting
out,
probably
a
large
chunk
of
our
potential
user
base.
E
I
think
the
average
user
is
probably
somewhere
in
the
middle
there
right
there,
they're,
probably
not
jumping
on
the
latest
version
that
they
may
or
may
not
wait
till
there's
a
point
release,
but
they
you
know
they
probably
update
as
as
they
have
the
time
and
as
they
see
need
me,
but
they're.
Also,
probably
a
bit
wary
about
falling
too
far
behind
because
go
is
a
language
where
keeping
up
to
date
has
typically
been
the
expectation,
at
least
in
my
experience.
E
C
Yeah,
I
think,
that's
fair.
I
think
I
think
that's
a
good
way
to
maybe
think
about
it
also
is
just
like
we
should
really
try
to
target.
For
that
the
whole
it's
a
pure
pro
principle,
80
20,
you
know,
try
to
hit
80
percent
of
the
user
base
and
those
outstanding
ones.
I
guess
let
them
complain
and
then
see
if
we
can,
you
know
address
it
at
that
point,
but
if
nobody's
complaining,
maybe
it's
not
worth
addressing.
I
guess
is
another
key
point.
E
Yeah,
that's
that's
another
way
of
looking
at
it
too.
Right
is,
if
nobody's
complaining,
that
we
aren't
supporting
the
latest
and
greatest
it's
not
a
problem.
We're
not.
There
nobody's
currently
complaining
that
we're
not
supporting
old
enough
versions.
So
that's
not
a
problem.
It
means
nobody's
complaining
at
all,
which
means
maybe
we're
supporting
too
much.
E
Not
about
the
versions
that
we
support,
though
right
so
so
maybe
we
probably
do
have
some
budget
to
trim.
You
know
on
either
end
and
I
don't
think
there's
anything
to
trim
on
the
new
end.
E
Sure,
but
we
used
to
support
113.
when
we
moved
from
113
to
114
to
be
here
complaints.
I
don't
think
so.
When
we
went
from
114
to
150.
Do
we
hear
complaints?
I
don't
think
so.
So
I
I
think
that
we
still
have
some
ability
to
move
our
minimum
support
aversion
to
a
newer
version
without
causing
friction.
And
if
we
start
seeing
that
when
we
do
that
we
get
complaints,
then
we
maybe
need
to
take
that
as
a
signal
to
slow
down.
But
I
don't
think
we've
seen
that
happen.
Yet
when
we've
done
that.
C
Yeah-
and
I
think
that
the
perspective
also
that
david
shared,
where
it's
like
think
about
the
language
as
itself
with
dependency,
is
another
good
one
right
like
we
continually
are
updating
our
dependencies.
You
know
like
that
is
something
we're
continually
doing,
and
so
I
yeah,
maybe
that's
just
a
good
way,
to
frame
the
policy
that
we
write.
D
Sorry
go
ahead
david.
I
I
can't
tell
if
I'm
working,
I
everyone's
frozen,
but
it
sounds
like
you
can
hear
me.
One
other
thing
to
think
about
is
that
I
would
be
a
little
bit
surprised
if
people
on
older
go
versions
were
super
up
to
date
on
their
open,
telemetry
dependency.
D
They
very
well
may
also
be
lagging
behind.
There
can
potentially
stay
on
slightly
older
versions
of
of
our
software
as
well.
That
does
still
have
support
for
over.
C
Yeah,
I
think
that's
fair.
Okay,
I
think
aaron
actually
did
a
really
good
job
keeping
notes.
So
I've
got
an
action
item
here
to
create
an
issue
aaron.
Do
you
want
to
create
that
issue
or
I'm
open
to
creating
it
as
well
or
anthony,
or
anybody
on
the
call
actually.
A
I
can
take
and
kind
of
distill
this
into
a
simple
issue.
What
do
we
want
to
get
out
of
that
issue?
Other
than
just
general
discussion
on
this.
C
Ultimately,
I
think
it
should
result
in
a
policy
being
added
to
the
project.
Defining
our
versioning
strategy
for,
for
the
go
language,
I
think
is,
is
what
I
would
say
and
making
sure
it's
documented
in
the
project.
C
You
know
I,
I
think
that
we
need
to
maybe
have
a
little
back
and
forth
in
that
issue
as
to
like
what
the
policy
needs
to
include,
but
I
think
we
kind
of
outlined
it
here.
What
we
would
want
from
our
perspective
on
the
call,
but
I
just
want
to
make
sure
that,
like
like
xam,
is
another,
you
know
good
example
and
there's
a
movie
gosh.
I
can't
remember
his
handled,
but
there's
people
in
australia
as
well
that
are
starting
to
contribute.
C
E
Cool
yeah,
I
I
agree
we
should.
We
should
have
a
policy
so
that
we
got
something
to
point
out
going
forward,
and
hopefully
we
don't
end
up
having
this
discussion
every
time.
There's
new
coverage.
C
Yeah
exactly
and
every
time
we
bump
it
right.
I
think
that,
as
we
just
said
like,
I
think
having
that
policy
is
a
really
good
thing
to
just
show
everybody
like
what
to
expect.
But
then,
like
you
know,
if
we
do
have
people
come
in
and
they
go
like.
C
You
know
reasons
that
we
don't
understand.
They're
saying
like
no,
you
still
need
to
support
this
version
because
of
I
don't
know
something
that
I
don't
know
of.
Then
we
could
have
a
discussion
about
it,
but
if
you
have
somebody
coming
in
and
just
going
like,
what's
going
on,
you
point
to
the
policy,
it's
a
lot
easier
to
say
like
this
is
what
we
do
in
the
project.
So.
C
Cool,
so
speaking
of
flaky
tests,
the
next
issue
I
had
up
is
kind
of
a
status
update
which
isn't
really
much
of
a
status
update,
because
I
haven't
been
able
to
work
too
much
in
the
project,
but
I
have
started
looking
at
taking
this
poc
thanks
aaron
for
the
reviews
on
this,
I
haven't
had
the
time
to
respond
to
them.
C
I
was
working
on
this
asynchronously
on
a
plane
and
so
there's
there's
some
some
commits
that
are
still
in
in
the
pipes,
but
I
would
like
to
get
this
out
sooner
rather
than
later,
because
this
is
addressing
some
of
these
flaky
tests,
as
well
as
admiral
behavior,
which
I
hope
is
not
there,
but
it
could
be
so
this
is
on
my
plate.
I
still
am
working
on
it.
I
might
you
know
close
this
pr
to
actually
put
in
a
valid
pr.
C
That
is,
I
think,
more
in
line
with
what
I
want
to
commit,
but
just
wanted
to.
Let
everyone
know
that
I
I
haven't
given
up
on
it.
It's
still
actively
like
my
top
of
the
list
when
I'm
not
working
on
splunk
stuff,
so
yeah.
C
That
being
said,
I
don't
know
if
everyone,
I
think,
on
the
call's
already
seen
aaron
submitted
prs
to
just
disable
the
tests
that
are
flaking
right
now
to
help
us
get
out
of
this
god-awful
state,
but
yeah
that
should
that
should.
C
My
god,
I
feel
like
sometimes
it's
always
like
one
step
forward,
two
steps
back
but
just
day
by
day,
okay,
cool,
that's
the
last
thing
on
the
official
agenda
here,
I'd
like
to
maybe
talk
a
little
bit
with
aaron
about
your
log
poc
I
saw
as
well.
I
was
briefly
looking
through
that
I
haven't
officially
made
any
review,
but
I'm
still
looking
at
it
there's.
Definitely
some
feedback
that's
coming
up
on
here.
Unfortunately,
I
don't
see
robert
on
the
call
he's
yeah.
C
On
vacation
so,
but
I
think
there's
some
really
good
discussion
here.
One
of
the
things
that
I
did
glean
from
this
and
I'd
like
to
maybe
just
people
on
the
call
their
opinions
is
the
the
coupling
between
wagar
and
this
project,
and
I
think,
one
of
the
major
things
I've
been
able
to
read
this
thread
completely
yet.
But
it's
just
that
there
is
an
idea
that
maybe
we
could
try
to
not
take
a
log,
our
dependency
and
I'm.
C
I
don't
know
how
that
would
work,
but
maybe
I'm
guessing.
I
think
that's
what
aaron's
also
saying
down
here,
that
that
might
be
kind
of
hard,
but
I
don't
know
if
anybody
else
has
any
opinions
on
that.
I
know
robert
is,
is
the
main
proponent
of
this.
A
So,
just
to
set
this
up,
if
we
do
not
want
to
take
a
log,
our
dependency
there
is,
we
forgo
probably
about
90
percent
of
what
logar
does,
because
we
can't
actually
have
an
interface
that
it
will.
It
will
will
satisfy
that
doesn't
also
include
a
definition
pointing
to
itself,
which
means
we
would
still
have
a
a
dependency
on
log
r.
A
So
this
is
the
function
that
I'm
saying
like
with
values:
it
returns
a
log
r
and
if
we
have
an
interface
as
the
return
value
that
won't
this
function
won't
satisfy
that,
because
those
are
different
function
definitions,
so
we
would
have
to
forgo
any
kind
of
level
setting
internally,
which
may
be
okay.
A
So
the
alternative
is
the
the
two
alternatives
that
I
see
is
make
our
own
interface
and
basically
re-implement
log
r,
which
there
isn't
actually
too
much
logic
behind
log
r.
It's
it's
a
fairly
small
package,
it's
mostly
connecting
the
log
r
struct
with
a
log
with
a
log
sync
interface
and
then
providing
kind
of
a
logger
api
that
you
can
use
adapters
to
get
whatever
your
current
logging
infrastructure
is.
A
The
problem
I
would
see
with
that
is,
then
we
have
to
recreate
those
adapters
as
well,
which
is
the
larger
portion
of
the
work
or
we
wrap
the
log
r
infrastructure
internally,
which
means
we
still
have
a
dependency
on
it.
Just
internally,
like
the
a
potential
user,
doesn't
see
it,
but
that
means
we
have
to
have
an
extra
wrapping
stage
layer
on
our
our
user
interface
of
we
take
a
our
version,
which
is
a
wrap
of
a
log
r,
which
is
a
wrap
of
an
actual
implementation
of
a
logger.
C
Yeah-
and
I
I
mean
it's
still
going
to
show
up
in
the
ghost
some,
if
not
to
go
mod
right,
yeah
yeah,
I
mean
I
think
this
is
a
tough
one,
because
I
I
see
the
idea
that,
like
having
a
pure,
no
dependency
api
is
ideal
for
a
lot
of
people
because
it
reduces,
I
think,
binary
size
as
well
as
overhead,
although
the
binary
size
is
kind
of
debatable.
C
The
the
problem
I
have
is
exactly
kind
of
what
you
pointed
out
is
like
there's
an
entire
team
devoted
to
working
on
this,
and
they
built
a
lot
of
really
good
connectors
that
work
for
a
lot
of
things
that
I'm
sure
a
lot
of
people
want
to
use
already,
including
other
logging,
libraries
like
zap
and
xerolog,
and
that
kind
of
stuff,
and
so
it
it
seems
like
it'd,
be
a
big
win,
because
we
could
just
leverage
that
work
and
leverage
that
team's
dedication
to
the
project
without
having
to,
like
you
said,
like
reinvent
or
even
re-wrap.
C
All
of
these
things
is,
I
think,
ideal,
which
seems
like
a
good
reason
to
take
the
dependency.
I
feel
like
that's
just
how
software
is
written,
but
I
also
see
it
the
other
side
where,
like
maybe
like
having
it,
you
know
as
thinned
out
as
possible
that
you
know
for
any
user,
especially
in
a
corporate
setting
that
has
to
get
security
audit
on
all
dependencies.
Like
maybe
that's,
you
know
more
of
a
burden
to
them
and
that's
not
something
we
want
to
do.
C
I
I
don't
know
I
I
would
lean
towards
more
of
taking
the
dependency
personally,
but
I
I
you
know,
I
don't
see
any
strong
blockers.
I
don't
know
if
everybody
else
has
any
opinions.
E
I
lean
in
that
direction
as
well.
I
think,
especially
as
long
as
we're
not
taking
a
dependency
on
a
concrete
implementation
like
zap
or
loggers
or
xero
log.
You
know,
one
of
those
bugs
that
might
have
more
need
for
review.
Blogger
is
is
very
thin.
It's
simple!
If
someone
does
need
to
review
it,
they
can
read
it
in
an
afternoon
so
yeah
I.
I
think
it
would
be
wasted.
Effort
on
our
part
to
re-implement
that
and
all
of
its
adapters.
C
Okay,
I
I
agree.
I
one
of
the
things
I
want
to
do
is
can
finish
reading
and
give
you
some
review
on
that
implementation.
Aaron.
It
looks
pretty
straightforward.
C
It
looked
like
actually
most
of
the
comments
outside
of
this
dependency
issue,
we're
just
naming,
which
is,
I
mean
it's
gonna,
take
the
longest
amount
of
time
ever,
but
I
think
that,
like
structurally,
it
looked
very
similar
to
what
I
would
do,
and
so
I'm
sure
I
can
add
to
the
new
cacophony
of
naming
issues,
but
but
otherwise
I
think
structurally.
I
think
that
was
what
I
was
envisioning
as
well.
So
maybe
we
could
talk
a
little
more
in
that
in
that
issue.
A
I
only
ask
is,
if
you
bring
up
a
naming
issue,
you
give
a
suggestion
of
some
sort.
If
this
isn't
good
enough.
C
Tell
me
what
would
be
I.
I
agree,
it's
very
strongly
about
that.
In
fact
I
might
say
give
more
than
one.
But
yes,
I
I
completely
agree:
okay,
cool,
that's
it
for
the
official
agenda,
plus
the
non-official
agenda.
If
you
haven't
added
your
name
to
the
attendees
list
as
well
already,
please
do
so
speak
to
track
anybody
else.
I'm
going
to
open
up
the
floor
and
see
if
anybody
else
has
other
issues
they
wanted
to
address.
E
I'd
like
to
propose
that
we
do
another
release
for
core
this
week.
If
we
can
like,
I
can
handle
the
mechanics
of
it.
There's
a
fix
for
force
flush,
the
in
the
batch
band
processor
that
I'd
like
to
get
shipped
because
that
has
impact
for
lambda,
and
we
want
to
be
able
to
put
our
stamp
on
the
lambda
but
to
go
lambda
instrumentation
and
say
it's
good
for
users
to
go,
and
I
think
that'll
be
the
last
thing
that
we
really
need
for
that
to
be
good.
C
Yeah
sounds
great
to
me
sounds
like
you're
volunteering,
but
if
you
need
some
help,
I'm
also
there.
E
Also,
I've
been
starting
a
prototype
of
a
mechanism
for
selecting
at
run
time,
which
exporters
to
use
through
a
registry
where
experts
can
be
registered,
and
then
I
I
think
that
it
seems
to
me
that
the
the
spec
is
really
pushing
for
all
configuration
to
happen
through
environment
variables,
and
I
think
that
may
be
the
way
I
go
initially.
E
But
I
was
wondering
what
people's
thoughts
are
on,
how
if
we
want
a
mechanism
other
than
environment
variables
or
hard-coded,
you
know
declarative
code
to
configure
exporters
and
trace
pipelines
or
metrics
pipelines.
Are
there
any
thoughts
on
how
we
ought
to
do
that.
C
I
mean
I
think
this
unfortunately
gets
back
to
like
how
do
you
want
to
how
do
like
they'll
prob
open-source?
How
do
we
configure
sdks,
because,
I
honestly
don't
think
environment
variables
are
going
to
cut
it
much
longer?
In
fact,
I
think
they're
already
well
beyond
their
capability
for
the
project
and
like
having
some
sort
of
yaml
definition.
E
Collector
has
chosen
sort
of
it's
yamo.
Is
the
the
one
well
supported
configuration
mechanism
right
now,
but
internally,
realistically,
there's
there's
a
map
of
string
to
interface,
basically
is
how
it's
represented
and
uses
map
structure
to
deserialize
into
config
structures,
so
it
could
directly
support
json
or
tunnel
or
any
other.
E
Now-
and
I
I
think
I
would
be
surprised
if
it
deviates
much
from
that
ever.
I
agree
that
having
some
sort
of
animal
structures
to
configure
an
sdk
would
be
great,
but
as
tyler
mentioned
like
it's
just
something
that
probably
needs
to
be
solved
beyond
us,
it's
not
something
that
would
be
good
to
solve
on
a
language
by
language
basis,
but
there's
nothing
at
the
spec
level.
That's
really
happened
to
solve,
for
configuration
beyond
environment
variables,.
A
So
I
have
two
points
that
I
want
to
bring
up.
First
off,
yes,
the
collector
maybe
has
solved
it
that
way,
but
there's
only
one
collector,
we
don't
have
to
write.
You
know
umpteen
different
versions
of
the
same
kind
of
thing.
A
A
If
we
can
do
that
in
a
way
that
doesn't
necessarily
like
pollute
our
api
like
the
stable
api,
I
would
appreciate
that,
but
I
think
it'd
be
a
good
idea
to
to
explore
how
we
could
do
that,
how
we
can
try
different
different
ways
for
something
like
this.
This
is
exactly
something
that
we
should
be
experimenting
on.
E
Yeah,
so
I
think
that
last
bit
there
touches
on
one
of
the
other
concerns
I
have,
which
is
you
know,
as
I
create
this
registry
for
putting
exporters
into
I'm
left
wondering
how
do
I
actually
make
use
of
that
in
an
exporter
without
jumping
it
straight
to
a
stable
api?
If
our
stable
packages
can't
take
dependencies
on
unstable
packages
which
for
good
reason,
your
policy
says
they
can't
we
can't.
We
can't
actually
make
use
of
that
until
it's
stable,
which
kind
of
gets
us
into
a
catch-22.
A
Well,
I
mean
there's
the
registry
aspect
of
it,
which
I
think
we
can
build
a
registry
aspect
of
it
and
then
there's
the
configuration
aspect
after
the
fact
right,
and
I
think
we
can
have
like
that's
where
I
think
the
the
experimentation
needs
to
be
in
right,
the.
How
do
we
configure
like?
Ideally,
what
I
would
like
to
see
in
a
configuration
is
a
first
off
it's
defined
by
the
user's
code
and
they
get
to
make
the
choice
of
hey.
A
Do
I
want
to
use
environment
variables,
or
do
I
want
to
use
a
config
file,
or
do
I
want
to
have
like
a
three-way
fallback
where
I
first
check
environment
variables
and
they
take
precedence
and
then
a
config
file?
And
you
know,
let's
let
the
user
define
that
in
a
in
a
simple
way,
but
that's
a
front
end
to
kind
of
the
registry
back
end
that
that
needs
to
be
there
so
like
we
could.
A
We
could
simplify
on
a
registry
thing,
and
this
is
going
to
be
something
that
is
very
specific
to
go
because
go
doesn't
have
like
these
auto
instrumentation
aspects
that
that
other
languages
have
like
spring.
In
java
and
other
languages
right.
E
E
Yeah
we
could
have
a
couple
release
candidate
versions
to
get
some
end
user
feedback
from
that.
That's
a
good
idea.
Yeah.
C
C
Okay,
I
think
that's
it
for
everything,
plus
the
external
unofficial
agenda.
Anybody
else
wanted
to
add
to
that.
I've
got
a
few
other
things,
but
I
think
that
they're
getting
to
the
point
of
diminishing
returns.
C
Cool,
I
haven't
any
any
user
stories
that
are
coming
in
anybody
using
up
and
down
tree
in
an
interesting
way.
E
You
know
it's
their
first
issue
in
open,
telemetry
or
one
today
was
their
first
issue
ever
so
that's
kind
of
good
to
see
that
you
know
people
are
coming
into
starting
to
use
open,
telemetry
and
starting
to
engage
with
a
solution.
Github.
C
Yeah,
that's
a
good
point
david.
I
don't.
I
know
we
looked
at
this
a
little
while
ago
after
the
main
release,
but
have
you
been
looked
at
any
of
the
statistics
of
the
package
downloads?
I
know
you
did
like
a
filter
at
some
point.
I
don't
know
if
there's
anything
oh
yeah
yeah,
I
haven't
looked
at
that.
C
Yeah,
I
I
couldn't
quite
hear
you,
I
think,
you're
looking
it
up,
but
also
your
internet
connection,
yeah,
I
my
keyboards.
I
don't
know
how
much
work.
Are
you?
Oh
okay?
I
guess
this
is
the
moment
where
you
say
talk
amongst
yourselves
for
a
little
bit,
but
let
me
figure
it
out.
I'd
like
these
moments.
Yeah.
Actually
I
don't
know
and
that
ends
I
was
kind
of
wondering
like.
Maybe
we
could
talk
about
the
upcoming
holidays.
C
I
know
that
people
are
probably
gonna
be
taking
off
some
time,
so
I'm
probably
gonna
be
going
to
slow
down
the
release.
Cadence,
I
think,
may
decrease.
I
don't
know
if
anybody
has
different
opinions
or
if
they're
gonna
be
able
to
dedicate
a
lot
of
time
over
the
holidays.
That
seems
to
never
be
the
case,
but.
A
C
C
Okay,
cool.
I
still
have
one
other
issue.
I
know
liz
hong
jones
opened
this
a
little
while
ago
it
was
around
redacting
old
package
versions.
I
had
given
a
plus
one
on
this.
I
don't
know
from
any
other
people
have
taken
a
look
at
I'm
trying
to
pull
it
up
right
now.
This
is
one
of
those
diminishing
return
issues
I
wanted
to
talk
about,
but
I
don't
know
if
other
people
have
looked
into
like
deprecating
packages.
C
These
are
things
like
we've
already
all
these
packages
that
are
associated
with
our
namespace,
that
we
no
longer
actually
support
due
to
renaming
or
due
to
just
they
were.
You
know
in
the
pre
1.0
phase,
and
so
we
don't
use
them
anymore.
It
would
be
probably
ideal
to
clean
it
up
now
that
the
module
system
allows
this
sort
of
thing.
A
It's
issue
2328.
E
I
know
in
the
collector
we've
retracted
releases
in
a
subsequent
release.
That's
I
think,
accomplished
fairly
simply
with
a
retract
directive
deprecation.
I
think
you
just
put
a
comment
on
a
subsequent
release
of
the
module
where
to
get
the
go
mod
at
the
module
directive
and
so
for
for
things
that
we've
removed
entirely.
E
C
E
You
can
retract,
which
will
cause
that
to
never
be
used
in
version
calculations
or
you
can
deprecate.
So
if
we
made
a
new
release
and
mark
it
as
deprecated
with
the
comment,
what
will
happen
is
if
someone
tries
to
use
that
module,
it
will
give
them
a
warning
saying
this
is
deprecated
and
we
can
put
a
comment
on
there
saying
what
they
should
use
instead
like
that
would
be
good
for
the
exporters
that
have
from
one
place
to
another.
C
Yeah,
that's
a
good
question.
That's
a
good
approach.
C
I
I
feel
like
this
might
be
one
of
those
times
where
we
need
to
reach
out
to
some
of
the
go
team
to
find
the
best
answer
here,
because
I
think
you're
right,
like
I
think
maybe
just
forking
from
that
particular
commit
where
we
remove
them,
might
be
the
best
option
to
then
tag
one
that
we,
you
know
branch
off
from
there,
but
I
I
don't
know
I
don't
know
what
the
ideal
case
is.
C
But
I
do
know
it's
probably
going
to
help
us
in
the
long
run.
We
do
get
issues
that
are
of
the
sort
of
what's
going
on
here.
This
doesn't
work,
this
dependency
isn't
there
and
it's
like
well
you're,
actually
using
the
wrong
module
that
doesn't
exist
anymore.
C
But
okay
anthony
do
you
know
it
sounds
like
you
have
some
experience
in
this
who
who,
in
the
collector,
was
the
one
who
was
doing
this.
E
Bogdan
was
the
one
who
had
dealt
with
the
release
where
we
had
to
retract
a
prior
version.
There
was
a
collector
release
that
was
incomplete
and
just
simply,
never
would
have
worked.
So
we
wanted
to
make
sure
nobody
tried
to
use
that
and
thus
used
retract
okay.
C
Yeah
and
the
issue
there.
I
can't
share
my
stream
for
some
reason,
but
it
links
to
a
good
walk
through
on
how
to
do
these
retractions
and
it
seems
similar
to
what
you've
done
there.
So
I
think
yeah,
the
resurrecting
parts,
the
hard
part,
I
guess
I'll,
put
a
comment
in
this
issue
for
that
effect.
C
Okay
cool.
I
seem
to
drag
this
on
as
long
as
I
possibly
can.
I
don't
know
david
if
you're
anywhere
close
to
looking
at
this
data,
or
maybe
we
just
look
at
it
asynchronously.
That
sounds
good
too.
I
I
am
I'll,
have
a
number
okay.
D
So
if
I'm
completing
this
correctly
in
the
last
day,
we
have
36
000
views
of
the
godox
that
are
not
from
punchbox.
D
Yeah,
so
it
was
about
31,
ish
thousand,
when
we
first
released.
That
was
the
one
week
yeah
when
we
first
released
and
so
we're
about
the
same
rate
right
now,.
C
Yeah,
okay,
do
you
have
like
a
graph
or
something
you
could
link
in
the
slack
channel?
I
don't
think
so.
D
C
I
see
that
makes
a
little
more
sense,
yeah
well
cool
I
mean
I
guess,
hasn't
really
dropped
off,
which
is
usually
what
you'd
expect
after
a
big
burst
like
a
big
release.
So
that's,
I
think,
positive,
I
think,
to
anthony's
point.
We
are
seeing
some
uptick
in
aaron's
point.
We
are
seeing
some
uptick
but
yeah.
C
No!
It's
just
saying:
yeah,
okay,
yeah!
I
think
with
that
we
could
probably
end
the
meeting
13
minutes
early.
That
sounds
good
thanks.
Everyone
for
joining.
If
you
have
any
other
issues,
you
wanted
to
talk
about,
definitely
hit
us
up
in
slack
or
asynchronously
in
the
issues
as
well.
But
thanks
to
everyone
and
we'll
see
you
all
next
week,
yeah.