►
From YouTube: 2021-04-22 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
A
C
D
Hey
there,
hello
how's
it
going
trying
out
a
new
micro,
sorry
new
camera
with
the
microphone
so
we'll
see.
If
this
goes.
D
B
Yeah
you
gotta
go
sync
up
with
aaron
he's
got
that
sweet.
I
feel
like
he
streams
or
something
like
that
set
up.
He
has
a
really
nice
microphone
set
up.
D
B
I
must
write
some
really
clean
code.
That
is
all
I'm
saying
cool.
Well,
we're
a
little
bit
past
the
hour,
I'm
looking
at
the
attendees
list.
B
I
think
we
might
have
critical
mass-
I
guess
aaron
isn't
here,
but
yeah
I'll
start
sharing,
please
be
sure
to
add
yourself
to
the
attendees
list
for
the
meeting,
and
if
you
have
anything
you
want
to
talk
about
in
the
agenda,
we
can
do
that
or
add
that
to
the
agenda
please
and
we'll
get
started
once
I
can
figure
out
the
tab,
I'm
looking
for
cool
cool
yeah
so
to
get
started.
We'll
take
a
look
at
the
rc
dock.
B
I
guess
we
can
just
start
here
for
a
high
level
overview,
making
some
progress.
The
to-do
column
went
down
it's
a
little
bit
in
fluctuation,
we're
still
adding
a
few
issues.
It
seems
like,
but
the
net
trend
for
the
past
week
is
we
lost
one
in
a
positive
direction.
That's
that's.
Really
good
in
progress
is
definitely
getting
cleared
out.
I
feel
like
one
yeah
okay,
I
guess
it
was
just
one
yeah
we're
up
to
six.
So
definitely,
we've
had
some
good
throughput.
B
This
past
week,
265
issues
done
15
to
complete
this
past
week.
Definitely
some
good
progress
here,
so
yeah,
I'm
enjoying
seeing
this.
This
is
really
positive
and
inspiring
so
yeah,
jumping
in
I'd
like
to
kind
of
just
keep
going.
Keep
on
this
momentum,
making
sure
that,
like
we
have
some
accountability
here,
so
I'd
love
to
just
kind
of
go
through
all
of
the
in
progress
again
so
right
now,
I
can
talk
a
little
bit
about
the
clarifying
the
package
demarcation
between
sdk
and
export
trace.
B
I
should
be
able
to
get
back
to
this.
The
bundler
removal
just
got
removed
yesterday
from
the
jaeger
exporter,
which
plus
like
a
bunch
of
other
cleanup
in
the
air
explorer,
I
think
all
for
the
positive.
So
it
enables
this
if
we
did
want
to
update
the
interface
there's
this
open
question,
which
I
was
kind
of
talking
about
here.
B
This
idea
that
we
couldn't
actually
do
this
before,
because
the
export
spans,
if
we
wanted
to
change
that
interface
method,
definition
to
include
passing
the
read-only
span
interface,
the
bundler
itself
got
in
the
way
because
it
needed
some
sort
of
initialized
state
to
or
state
value
to
build
some
sort
of
cue
or
some
sort
of
like
memory
registry.
B
For
for
that,
you
know,
batching
that
it
would
do
it
wasn't
a
needed
part
of
the
export,
so
we
removed
it
so
now
it
we're
open
to
allowing
this
change.
However,
this
is
kind
of
like
maybe
you
know
a
second,
you
know
want
to
take
a
second
look
at
how
we
arrived
at
this
position
having
the
read-only
spam
interface
and
if
we
could
get
away
with
an
actual
struct.
B
I
see
that
steve
commented
very
quickly
after
I
had
commented
and
I
haven't
been
able
to
respond
except
for
thinking
about
it,
but
I
think
that
in
your
answer,
actually
lies
the
solution
as
to
why
we
went
with
passing
this
run
as
an
interface
and
it's
just
being
an
abstraction
of
where
the
actual
storage
is.
It
enables
us
to
do.
B
You
know
similar
things
to
what
pablo
is
talking
about,
where
we
can
pass
the
can
no
ops
man
as
as
a
span
in
many
instances
without
actually
having,
like
you
know,
a
lot
of
memory
overhead
or
something
like
that,
and
so
I
think
that's
probably
why
we
went
through
that
idea.
B
I
don't
know
if
we
documented
that
I
think
that
I
might
have
had
a
lot
of
this
kind
of
discussion
with
johannel,
johannes
asynchronously,
so
I'll
have
to
I'll
have
to
look
into
this
again,
but
this
is
where
I'm
gonna
be
picking
up
in
this
next
week,
going
forward
just
trying
to
resolve
this
issue,
there's
a
few
more
things
outstanding
from
the
work
in
progress
that
he
had
left
here.
So
I
think
that
that's
pretty
straightforward.
I've
been
looking
at
some
of
them,
so
yeah.
I
think
that's
good.
D
By
the
way,
just
the
the
struck
technique
would
work
if
it
was
designed
with
this
intention.
In
other
words,
if
the
only
exported
methods
on
the
struct
were
the
read-only
methods,
it
would
work
fine,
but
I
suspect
I
haven't
looked
for
a
while,
but
I
suspect
that
we
have
other
exported
methods
on
that
struct
so
that
if
any
of
them
are
mutable,
we
could
not.
We
could
not
make
just
the
subset
of
the
relative
relevant
methods
available
to
callers.
B
I
don't
know
if
that's
true,
I
think
the
spam
snapshot
is
actually
very
much
one-to-one
with
the
read-only
span.
I'd
have
to
double
check
this,
though
I
think
the
span
was.
The
question
is
if
you
could
pass
the
span
as
a
read-only
interface
in
some
context,
and
I
think
you
wanted
to
do
that
because
things
like
I'd
have
to
look
again,
but
I
feel
like
that
was
the
actual
overload
and
that
one
actually
implemented
both
the
read
only
plus
the
read
write
so
yeah.
E
B
B
Cool
jumping
back
into
the
in
progress,
there's
still
the
otlp
exporter
only
for
traces.
I
don't
know
if
there's
any
update
on
this
one
brian
had
picked
this
up.
I
know
that
there
was
a
open
issue.
I
thought
this
has
all
the
reviews.
B
I
think
of
it
is
actually
there's
some
yeah
there's
some
different
ideas
of
like
the
direction
and
I
think
that
they
were
asked.
I
don't
know
if
there's
been
any
changes
since
then
yeah.
This
is
what
it
is.
This
configuration
style
needed
to
get
addressed.
It
doesn't
match
our
contributing
style
guides
anthony.
I
don't.
I
think
I
saw
you
on
the
call
or
do
you
know
what's
up
with
brian,
if
he's
still
around.
F
Yeah
he
is,
and
I
can
follow
up
with
him
on
this-
I
think
the
latter
half
of
this
hours
or
stand
up
with
them.
So
if
we
rev
up
early
I'll
touch
base
with
him
there,
otherwise
I'll
do
it
later
today,
yeah
I
I
can
follow
up
to
make
sure
that
he
does
that.
F
I
it
seems
to
be
a
common
pattern
that
when
new
contributors
come
to
the
project
and
go
to
implement
an
option,
they
implement
it
this
way,
and
then
we
have
to
ask
them
to
go
and
build
the
destruct
and
an
interface
and
typically
then
also
have
a
a
option
func
that
allows
them
to
just
wrap
a
function
because
99
of
the
time
that's
what
it
ends
up
being,
it's
just
a
function
that
manipulates
it.
F
F
I
don't
know
if
I
want
to
say
that
we
should
change
our
our
defaults
on
on
how
we
approach
options,
but
maybe
we
might
want
better
documentation
on
on
why
it's
that
way,
and
not
just
this,
you
know
a
function
as
an
option.
B
Yeah,
that's
a
really
good
point
and
we
have
robert
on
the
call
from
splunk
here
who
had
opened
up
that
issue
last
week
about
just
exporting
the
the
additional
methods
that
we
ended
up
going
with
a
different
route
on,
but
like
I
am
open
to
reevaluating
this
decision
as
well
or
at
the
very
least,
better
documenting
it
like
what
you're
talking
about.
I
have
this
issue
in
here
as
well
for
unifying
the
configuration
and
initialization
that
the
main
desire
that
I
have
in
this
ticket
is
not
necessarily
to
impose
particular.
B
I
don't
know
dogma
more
so
to
provide
uniformity,
I
think
is,
is
really
the
key.
So
I'd
love
us
to
have
this.
You
know
understood,
make
making
sure
that
there's
like
objective
reasoning
as
to
why
we're
going
this
path
and
then
making
sure
that,
if
we're
unified
unified
across
that
yeah,
I
don't
know
if
robert
you
had
anything
more.
You
wanted
to
add
to
something
like
this.
A
Basically,
I
must
confess
that
I
haven't
seen
this
code
style
style
guide,
because
I
it
was.
I
was
just
looking
at
the
a
con
trip
on
the
go
contrib
and
it
was
referenced
there,
but
just
one
and
small
happening
and
I'm
just
looking
at
this
one.
Personally,
I
made
a
little
pr
which
is
kind
of
related
to
the
stuff
which
I'm
reading
right
now
in
parallel,
so
you
suggest
exporting
this
type
option
interface
and
apply
as
exported
as
an
exported
function
person.
I
see
no
reason
why
this
apply
method
is
exported.
D
Okay,
I
wanted
to
note
that
this
this
this
prescription
came
up
obliquely
in
the
in
the
go
slack
workspace
as
a
target
of
ridicule.
Recently
I
don't
know
if
anybody
else
saw
that
no,
I
I
can
dig
it
up.
I
I
think
that
they
were
nitpicking
about
why?
Why
there's
so
much
of
it
that's
exported
and
asserting
that
it
showed
that
we
didn't
understand
something.
D
So
I
should
go
dig
it
up,
but
I
skimmed
past
it
because
I
wasn't
in
the
mood
too
hot
to
defend
something
but
I'll
go
see.
You
know
there
might
be
some
criticism
there
that
new
contributors
come
along
that
maybe
they
hold
that
opinion
and
aren't
really
ready
to
accept
the
prescription.
Here,
let
me
go
find
it.
B
Yeah
or
this
is
just
incorrect,
you
know,
I
think
if
this
was
an
attempt
to
unify
rather
than
like
you
know,
I
think
there
was
a
lot
of
different
like
inputs
that
went
into
this,
but
I
don't
know
if
it's
the
perfect
solution
either.
So
I'd
like
to
get
more
knowledge
and
understanding
and
think
through
this
through
a
few
more
times
before,
I
actually,
you
know,
went
through
and
updated
all
the
options,
but
yeah
would
that
be
helpful.
I'd
appreciate
that.
A
I
kind
of
feel
they're
a
little
over
engineered
here,
especially
that
they
are
not
encompassing
the
error,
handling
and
stuff,
like
that,
and
it's
often
harder
from
the
consumer
perspective,
to
use
a
functional
option
than
like
plain
old
config
file,
which
is
very
popular
in
the
standard
library.
But
if
you
have
already
this
discussion,
just
forget,
I
do
not
want
to
mess
here
on
the
community.
You
know
just
my
unpopular
opinion.
B
Yeah,
that's
a
good
question.
It
comes
back
to
this
idea
of
the
extensibility
of
the
api
as
we're
trying
to
build
and
trying
to
provide
you
know,
forward-facing
versioning
patterns,
and
so
there's
always
this
idea
that,
like,
if
you
wanted
to
add
something
like
if
you
want
to
add
an
argument
to
a
function,
that's
a
breaking
change
like
you're,
going
to
change
the
actual
type,
and
so
by
providing
functional
options
as
variatic
arguments,
it's
open
to
adding
you
know
new
options
in
the
future.
B
A
No
because
from
my
life
experience
functional
options,
you
have
like
this
variatic
right
right
at
the
end
and
you
can
type
many
many
things
and
the
alternative
is
just
you
have
like
this
factory
function,
something
like
a
constructor
when
you
have
this
struct,
which
has
the
config
and
often
if
you
want
the
defaults,
you
pass
nil
and
you
know
the
difference
from
the
user
perspective.
Is
that
we,
if
we
want
to
add
an
option,
we
just
set
some
create
the
config
and
add
some
fields.
A
So
if
you
add
new
features,
you
just,
for
example,
add
a
new
add
something
new
to
the
confi
extract.
Where,
in
the
functional
options
you
just
create
a
new
function
right.
B
Yeah
yeah,
I
got
you
and
there's.
I
think
that
there's
a
really
good
blog
post,
I
think
it's
dave
cheney.
B
Like
it's
somewhat
of
an
arbitrary
choice
like
if
you
have
one,
if
you
have
the
config
like
that
makes
sense,
you
have
to
maintain
the
config
is
still
comparable
or
not
comparable
going
forward.
If
you
don't
like
you
said,
if
you
don't
pass
the
config,
then
you
have
to
pass
an
explicit
middle
value
versus
the
functional
options.
You
don't
have
to
pass
anything
so
like
it's
just
it's
like
honestly,
like
I
don't
think,
there's
a
a
really
strong
reason
to
go
one
way
or
the
other.
It's
more
just
a.
B
I
guess
style
choice,
and
this
is
how
we
saw
a
lot
of
the
function.
A
lot
of
the
things
being
passed
was
just
functional
options.
We
tried
to
unify
on
that.
I
think,
was
the
idea.
Okay,.
F
And
I
think,
with
a
with
a
config
struct
as
well,
you
you're,
then
exposing
even
more
of
the
internals
of
whatever
it
is
you're
configuring,
because
the
the
functional
options
you
don't,
we
we
generally
keep
that
config
script
unexported.
I
I
think
you
know
to
make
something:
we've
got
an
interface
but
apply.
We
probably
shouldn't
export
that
either,
but
with
a
config
stroke
you
have
to
export
all
of
those
fields.
They
have
to
be
known
and
exported
types
that
the
the
end
user
can
then
insert
into
them.
F
Whereas
with
functional
options,
we
can
change
around
that.
How
we
decide
to
apply
those
options
to
the
internal
structures
of
the
package,
that's
being
configured
without
the
end
user
ever
seeing
any
of
that
and
they
still
use
the
same.
A
Option,
that's
not
that's
not
totally
true,
it's
easier
to
get
wrong,
but
you
can
still
have
you
know
unexported
fields,
and
you
know
your
you.
You
do
not
have
use
this
configs
in
the,
for
example,
in
the
fields
you
can
then
parse
them
and
create
something
in
you
know
in
the
layer
which
constructs
so
you
can
just
have
a
config
file,
which
is
an
input
which
has
similar
api
as
defined
as
the
function
options,
and
then
out
of
that
you
can
have
your
internal
internally.
You
know
not
exported
fields.
F
Then
I've
got
to
parse
that
and
reconstruct
another
another
object,
as
opposed
to
taking
an
instance
of
our
config
objects
and
ranging
over
a
slice
of
options
and
applying
them.
That's
that's
something
that
I
don't
have
to
think
about.
When
I
go
to
apply
the
functional
options
pattern.
I
just
range
over
a
slice
of
options
and
apply
them.
A
Yeah,
so
the
beauty
of
functional
options
is
encapsulating.
You
see
it
only
in
one
place,
that's
true,
but
I
think
the
beauty
is
more
for
the
guys
who
maintain
the
code,
then,
from
the
user
perspective.
That's
my
my
personal
opinion.
Basically,
when
I
was
a
lot
of
using
grpc
as
a
as
a
you
know,
user
then,
for
example
the
http
from
standard
library,
so
sometimes
the
functional
options
just
cause
me
to
write
more
code.
A
B
I
yeah
I'd
love
if
you
could
capture
some
of
these
ideas
in
the
issue
I
just
linked
in
the
chat
robert.
I
think
that
we
don't
want
to
lose
them.
I
think
we
should
probably
try
to
document
that
we've
talked
about
them.
At
least,
I
think,
is
a
good
idea.
So,
if
you
could
just
add
those,
I
think
to
the
to
the
linked
issue,
that'd
be
really
helpful.
You
want.
A
B
B
Yeah
sure
we
can
oh
well,
you
need
to
comment
first
or
you
need
to
be
a
member
of
the
hotel
org.
I
don't
know
if
you
are.
I.
G
B
B
Okay,
sorry,
I
had
a
little
rainbow
right
there,
yeah
so
yeah
I'd
love
it.
If
you
can
get
some
some
comments
going
on
that
one
or
just
go
with
the
ticket
cool,
I
want
to
keep
the
momentum
going
because
I
really
want
to
get
anthony
back
to
the
interns,
so
I
can
get
some
answers
on
some
things.
Not
really.
I
just
want
to
save
everyone's
time
as
well.
The
spec
performance
review
the
oh
explorer,
retries
gustavo.
I
think
I
see
you
on
the
call.
B
I
think
you
have
a
pr
for
this
there's
some
changes
I
requested.
I
think
that
should
resolve
it,
though
right.
B
Yeah
no
words,
I
thought
I
saw
you
have
a
few
other
things
in
here
or
a
few
other
pr's
so
sounds
all
sounds
great
cool.
Any
questions
for
me.
Any
statements
to
me.
B
B
Okay,
cool
sounds
good,
then
I
think
the
next
one
is
that
pr
we
just
looked
at
from
brian
need
some
help.
Aaron.
I
think
you
have
this
clumsy
resource
new.
You
had
some
ideas
here.
G
So
there's
been
a
couple
different
revisions,
I
think
from
my
initial
proposal.
I
could
not
see
the
the
better
one
that
we
finally
arrived
at,
but
I
think
there's
we're
actually
in
a
pretty
good
state.
Now
there
is
an
empty
x
resource
instead
of
a
raw
resource.
I
think
that
just
encap
encapsulated
the
idea
a
little
bit
better
and
the
new
resource
will
actually
have
defaults
applied
all
the
time
they're
both
used
in
the
same
way,
just
one
is
sans.
G
B
That's
almost
as
embarrassing
as
when
I
was
talking
about
the
trace
provider,
for
I
don't
know
six
nine
months
or
something
like
that,
instead
of
the
tracer
provider,
so
yeah
I've
never
made
a
mistake
in
my
life
I
swear.
G
But
but
aside
from
that,
that
change,
I
think,
I'm
a
lot
more
happy
with
where
it
is
and
its
usability
at
this
point.
B
Okay
yeah:
this
is
one
that
has
been
sitting
on
my
to-do
list
to
review.
So
there's
a
lot
of
conversation
going
on.
If
any
of
these
are
still
open
or
resolved,
can
we
make
sure
we
go
through
and
resolve
these?
I
always
like
the
idea
of
just
aggressively
resolving
them,
because
it's
really
easy
to
unresolve
it.
If
someone
thinks
that
it's
not
resolved
so
yeah
that'd
be
really
helpful,
but
yeah.
G
B
Yeah
I
mean
they
don't
go
away
right,
so
we
can
always
look
back
at
them,
but
it's
just
really
helpful
for
new
people
when
they
come
to
the
pr
to
review
to
see
like
oh,
this
discussion
has
been
resolved
like
I
don't
want
to
spend
time
reading
through
it
and
then
realize
it's
already
a
done
deal.
B
That
being
said,
I'll,
try
to
read
through
them
as
well.
I
think
that's
really
helpful.
Well
cool,
okay,
I
think
that's
everything!
That's
in
progress!
Anything
that's
been
added.
This
we're
going
to
talk
about
in
a
second.
B
Yeah
so
there's
a
batch
processor
size
will
grow
endlessly
on
error,
so
I
was
wondering
about
this
anthony.
Do
we
need
this
for
the
rc
or
is?
Is
this
just
a
really
severe
bug.
F
This
is
a
bad
bug
I
I
would
not
want
to
ship
with
this
I
mean
we
can
make
an
rc
by
saying
yeah.
I'm
sure
this
is
a
candidate
of
the
api,
but
I
wouldn't
cut
a
1.0
release,
knowing
that
this
is
out
there,
okay,
cool
and
given
that
I
think
that
the
fix
is
probably
relatively
small.
I
think
we
can
address
it
quickly.
It
should
be
a
matter
of
one
changing
an
equals
to
a
greater
than
or
equals
so
that
we
try
to
ship.
F
Even
if
we've
exceeded
the
max
max
batch
size
and
and
to
after
we
get
a
failure
when
trying
to
ship,
then
we
just
wipe
out
the
batch
and
reset
it.
I
don't
know
that
there's
any
sensible
way
for
us
to
try
to
retry
at
this
layer.
I
think
retries
have
to
happen
at
the
exporter
that
this
calls,
because
that
has
better
information
about
what
might
be
retriable.
B
If
I
remember
correctly,
that's
how
we
defined
the
metrics
interface
for
export,
so
I
don't
understand
why
we
wouldn't
do
the
same
for
the
trace,
because
it's
exactly
that
reason
like
yeah.
I
agree,
I
think,
if
the
the
bachelorette
processor
should
give
up.
I
think
that
if
you
want
like
in
the
future,
we
could
we
could
build
like
a
re-trying
span
processor
or
something
like
that
and
you
could
like
set
it
a
bunch
of.
B
I
think
it
is
in
the
specs
and
I
think
it
says
that
it
should
just
dump
it,
but
I'd
have
to
double
check.
I
know
that
it's
in
the
specs
for
the
metrics
interface
I'd
have
to
double
check
on
the
trace
side
but
yeah.
I
think,
if
that's
the
appropriate
thing.
B
F
Sure
help
on
it.
Good
first
issue
probably
can
be
applied
to
it
as
well.
I
think
the
the
fix
is
relatively
straightforward.
I
will
see
if
many
of
the
interns
yeah
help.
One
is
probably
fine.
I
will
see
if
any
of
the
interns
have
been
with
to
take
it
on.
I
know
there
are
a
couple
here:
if
anyone
wants
to
chime
in
and
claim
it,
we
can
get
that
assigned
to
you
now
otherwise
I'll
ask
others
or
we'll.
Let
someone
pick
it
up.
F
B
I
think
we
should
probably
push
back
upstream
to
the
spec
what
our
decision
is
here.
I
think
it's
probably
a
good
idea.
F
In
the
exporter
definition,
it
does
say
any
retrial
logic.
That's
required
by
the
exporter
is
the
responsibility
of
the
exporter.
The
default
sdk
should
not
implement
retry
logic,
as
the
retry
logic's
likely
to
depend
heavily
on
the
specified
protocol.
So
I
I
guess
that
would
apply
to
the
batch
bin
processor
as
well.
B
Yeah,
I
agree.
I
think
it
would
make
sense:
okay,
no
one's
speaking
up
to
claim
it
we'll
let
anthony
delegate
it
cool,
looks
good.
The
I
think
next
thing
on
the
agenda
was
past
tuesday
we
had
a
metrics
roadmap
update.
We
met
with
josh
from
lightstep
talked
a
little
bit
about
like
the
path
forward
on
the
metric
specification,
so
for
everyone
on
the
call
who
maybe
isn't
following
this
metric
specifications
going
through
a
revamp
and
a
redo,
maybe
you
might
be
the
same
api
down.
B
I
think
the
data
model
is
remaining
somewhat
consistent,
at
least
for
compatible,
but
the
api
is
likely
going
to
rename
a
lot
of
the
instruments
and
maybe
some
of
the
calling
signatures
that
they
recommend
there
and
since
go,
is
pretty
forward-facing
in
the
metrics
world.
B
B
We
only
have
a
finite
amount
of
human
resources
and
hours
of
the
day
that
we
can
actually
spend
to
help
migrate
this,
and
so
we
want
to
make
sure
that
you
know
we're
not
over
subscribing
people
to
make
this
happen,
and
so
we
talked
a
little
bit
about
some
timelines
here.
The
idea
to
start
it
off
was.
B
We
also
realized
that
the
otlp
exporter
currently
supports
both
metrics
and
traces,
and
if
that's
going
to
be
included
in
the
stable
release
of
1.0,
then
we
need
to
split
that
off,
and
so
that
is
the
one
of
the
issues
that
was
added
to
the
rc
project.
To
make
sure
that
that's
actually
done.
Josh
is
taking
that
on
he's
got
some
ideas
of
experimenting,
so,
hopefully
he's
going
to
get
started
that
he
said
he's
been
able
he's
going
to
be
able
to
commit
some
time.
B
I
think
in
a
week
and
a
half
is
what
he
was
saying.
So
look
forward
to
that.
If
you
do
have
some
dependence
on
the
metrics
library,
we
should
have
some
sort
of
path
forward,
and
maybe
bumpy
is
the
caveat.
I'm
gonna
give
you,
but
we're
trying
to
not
just
throw
away
what
is
already
existing
and
start
over
from
scratch
is
also
the
plan.
A
B
A
versioning
dock
here
have
you
read
through
this
one,
yet
no
yeah,
I
probably
read
through
this.
This
contains
a
lot
of
information.
Some
examples,
even
here
of
how
to
like
you
know,
handle
things
at
different
versions
and
handle
you
know
new
things
coming
into
existence
like
logs
and
that
kind
of
thing
so.
F
Yeah
and
there's
there's
an
issue:
that's
open
and
outstanding
that
we've
got
and
I
think
that
the
after
rc1
bucket
to
improve
our
release-
tooling,
it's
it's
in
the
after
rc
one,
because
we
think
we
can
probably
get
to
rc1.
F
We
think
we
can
get
to
rc1
with
what
we've
got,
but
as
soon
as
we
do
that,
we've
got
a
need
for
this
tooling
to
make
sure
that
we
can
manage
the
fine
grained
modules
we've
built
up
and
be
able
to
increment
their
versions
independently.
B
A
Just
maybe
one
idea:
what
do
you
think
of
adding
an
x
like
the
google,
like
you
know
like
golang
has
for
the
stuff,
which
is
you
know,
experimenter?
Are
you
already
discussing
it.
F
Having
an
experimental
path,
we
we
want
to
avoid
having
to
change
the
import
path
when
something
moves
from
experimental
to
stable,
we'll
just
rely
on
semver
and
a
major
version
of
zero
as
indicating
experimental,
okay.
A
B
Yeah,
I
definitely
recommend
it.
We've
definitely
kind
of
the
x
idea,
as
well
as
the
experimental
path
or
something
like
that
in
general.
The
other
idea
is,
it's
like
it'd,
be
really
useful
to
have
something
like
that,
and
we've
talked
about
it,
not
necessarily
just
for
this
versioning
of
stable
signals
or
something
like
that,
but
also
just
for
the
idea
that
different,
you
know,
instrumentation
implementations
or
different
ideas
that
we
maybe
want
to.
B
You
know
bring
in
eventually
so
we've
kind
of
toyed
around
with
idea
the
takeaway
that
we've
always
kind
of
come
down
to
is
just
like
well
right
now,
just
host
it
on
your
own
and
if
it
becomes
really
popular
move
it
in,
but
maybe
in
the
future.
We
also
provide
some
sort
of
additional.
You
know
hangout
area
where
we
can
put
like
users,
user
supplied
things
like
that,
so
yeah
definitely
recommend
going
reading
that
cool.
The
next
thing
I
want
to
talk
about
is
the
release.
B
I
think
anthony
said
we're
about
four
weeks
out
from
the
last
release
we
merged
the
jager
work
that
I
was
working
on.
I
have
the
two
outstanding
issues
prs
that
I
had
mentioned,
or
something
mentioned
our
anti-dimension
slack
this
morning
that
we
wanted
to
get
in
before
the
release.
I
put
some
reviews
in
so
I
don't
know
if
we
want
to
wait
for
those
to
actually
land
or,
if
we're
okay,
with
just
going
for
the
release,
which
I
could
probably
do
tomorrow,.
F
I
I
would
say,
let's
just
go
forward.
I
I
think
both
of
us
who
chimed
in
with
issues
said
these
would
be
nice
to
have,
but
not
critical.
So
I
I
think
it's
probably
more
important
to
get
a
release
out
than
to
get
these
changes
into
that
next
release.
They'll
get
into
the
one
after
that,
which
hopefully
won't
again
be
another
four
weeks.
B
Yeah
I
catch
it
well
cool.
I
will
put
a
timestamp
on
tomorrow
morning.
If
it's
not
you
know,
merged
by
then
then
I'll
start
the
release.
I
think
I
have
a
free
ish
day
tomorrow.
One
of
the
things
I
noticed
is
that,
as
I'm
sure
some
of
you
might
have
seen
the
hotel
package.
B
Have
the
latest
version
here
we're
at
0.19
and
I'm
not
too
sure?
What's
holding
this
up?
It's
never
been
delayed
before.
F
Yeah,
this
is
really
weird
the
the
sub
modules,
the
models
underneath
it
are
at
point
19.
like
if
you
go
to
trace,
that's
at
point,
19.,
really:
okay,.
B
E
A
C
B
I
saw
that
as
well,
and
I
manually
I
mean
I
mean
I
definitely
use
it.
A
lot
of
other
people
use
it
and
I
manually
use
like
a
some
database
lookup
to
see
if
that
pulled
in
the
latest
and
some
database.
There
says
that
it
has
it,
it
just
doesn't
show
it.
So
I
don't
know
what's
going
on,
I
think.
F
Part
of
the
release,
tooling,
is
a
script
to
validate
that
you
can
build
a
package
that
depends
on
all
of
the
new
modules,
that's
outside
of
the
module
right,
which
should
run
you
through
the
that's.
B
Okay,
I
think
that
that's
just
we'll
see
if
the
next
one
works
better.
Otherwise
we
might
have
to
file
an
issue.
I
think
or
something
like
that,
because
that's
a
little
that's
really
weird
that
the
trace
package
or
the
trace
module
shows
up
but
yeah
cool.
I
will
get
an
issue
out
tomorrow
morning.
That's
something
I'll
take
from
it.
The
last
thing
is
aaron.
You
have
this
open
issue
here.
If
you
want
to
talk
a
little
about
it,
so.
E
G
F
Yeah,
so
that
issue
was
created
when
this
this
issue,
that's
up
on
screen
right
now
was
fairly
early
on,
and
this
issue
then
evolved
to,
I
think,
perhaps
an
understanding
on
their
part
that
they're
running
up
to
some
limits
of
concurrent
go
routines
or
something
like
that.
So
they
have
performance
problems
in
the
redis
client
that
are
not
related
to
open,
telemetry's
api.
It's
just
they
happen
to
notice.
Then
wall
adjacent
to
open,
telemetry,
yeah.
B
I
agree,
I
think,
that's
why
we
originally
removed
it
as
well.
I
think
it
it
really.
I
think
it
was
go
112
or
113..
The
variatic
argument
use
was
like
there
was
a
heavy
memory
overload,
but
it
has
it's
gone
away,
and
so
I
think
that
what
the
benchmarks
you
did
are
duplicated
in
a
lot
of
good
blogs.
For
this
exact
same
reason,
and
so
I
think
we
could
probably
close
this.
Yes,
I
think,
if
that's
I
would
like
to
do
that.
I
will
do.
B
I
need
to
write
some
words
in
here
or
is
this
you
think
it's
ready
to
just
close.
G
I
will
go
ahead
and
put
a
little
comment
saying
after
discussion.
The
discussion
here
you
can
just
click.
Look
at
that.
B
Yeah
feel
free
to
that
sounds
great.
I
would
support
that
like
a
like
with
the
other
one.
You
can
always
reopen
an
issue.
The
hard
question
is:
if
you
want
to
lock
the
issue
right
and
that's,
I
understand
that's
a
more
technical
one,
but
you
can
always
reopen
an
issue
of
which
I
did
this
past
week
for
that
stupid
bug.
B
Don't
say
that
just
you
know:
you're
gonna
change
this
you're
inviting
disaster
there
yeah.
B
Possibly
go
wrong:
yeah!
Oh
man,
okay,
that's
it
for
the
agenda.
I
want
to
give
a
pause
here.
If
anybody
else
has
something
they
want
to
talk
about
again,
I
like
to
always
end
these
things
with.
If
anybody
has
some
wins,
some
customer
use
cases
that
they've
implemented
or
some
cool
things
they've
done
to
tell
us
back
love
to
hear
about
them.
A
F
And
thank
you
for
spending
time
thinking
about
our
api
and
ways.
It
could
be
better,
I
mean,
even
if
we
didn't
end
up
making
a
change
as
a
result
of
what
you
suggested.
We
had
the
conversation.
The
conversation
was
valuable
and
I
think
everybody
then
ends
up
with
a
better
system.
At
the
end.
A
And
also
the
like
good
point
is
that
for
the
next
week
I
got
like
an
approval
to
work
on
the
go
auto
site.
So
if
there's
any
either
approve,
you
know
anything
things
to
review.
To
take
a
look,
then
feel
free
to
ask
me.
I
don't
know
on
slack
or
anywhere
I
can
try
helping.
B
Cool
yeah,
I'm
happy
to
sync
with
you
as
well
on
some
issues.
I've
got
some
ideas.
We
can
do
that
touch
base
afterwards,
but
as
well.
If
anybody
else
has
issues
you're
on
slack
as
well
right,
you're
on
the
cncf
slack
right
cool.
B
Well,
thanks
for
the
contributions
really
appreciate
it
and
thanks
everyone
for
showing
up
to
the
meeting.
I
think
we
could
probably
close
it
at
this
point,
so
I
will
say
goodbye
and
I
will
see
you
asynchronously
and
look
forward
to
keeping
that
momentum
going
forward.
I'll
talk
to
you
later.