►
From YouTube: 2021-07-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).
B
B
I
know
it
definitely,
this
is
this
is
the
reason
why
I
live
in
oregon
right
here.
So.
B
B
B
Anthony
do
you
know
if
batik
is
able
to
join
today.
B
Okay,
I'd
love
to
get
a
status
update
on
the
log
proposal,
but
yeah
he's
not
available.
That's
fine
too.
B
I'm
out
and
about
today,
yeah
nice
are
you?
Are
you
back
to
the
office
or
or
of
some
sort.
D
Oh,
I
I
work
remotely
anyway
and
nobody's
gone
back
to
the
office
yet
which
is
in
new
york
city
yeah,
but
I
was
able
to
get
out
of
the
house,
which
is
good
progress.
B
Yeah,
that's
a
it's.
Definitely
progress
for
sure.
D
B
Yeah,
did
you
see
that
open
issue
regarding
bazel?
No,
I
should
go
yeah.
I
wonder
if
he's
like,
I
it's
unresolved,
but
I
don't.
E
E
B
I
don't
know
where
it
is:
it
resolved
itself
yeah,
it's
kind
of
weird.
I
don't
did
I
close
that
today
I
was
just
looking
at
it
today.
I
will
not
fix
no
yeah
it
man.
It
was
like
a
bug
and
yeah
man.
That's
gonna
bug
me.
D
I
think
I
think
our
project
does
something
that
is
perhaps
it's
not
illegal
to
the
go
tool,
but
it's
maybe
a
little
bit
unusual,
which
is
that
we
we
share
internal
packages
across
module
boundaries
right
and
so
the
gazelle
tool
right
now
at
least
doesn't
catch
on
to
that,
and
so
you
need
to
kind
of
bend
its
arm
and
tell
it
no.
No!
It's!
Okay!
We're
going
to
generate
the
right
control
files
for
that.
B
Oh
yeah,
that
that
might
be
what
that
issue
was
about.
Then.
D
E
B
Could
have
swore-
maybe
it's
in
the
country
of
replay
or
something
I
just
can't
find
it
right
now.
Okay,
well
welcome
everyone
to
the
sig
meeting
this
week.
If
you
haven't
already,
please
add
yourself
to
attendees
list
and
I
will
figure
out
how
to
share
a
screen
and
we
can
get
started
here.
C
B
That
sounds
great.
I
don't
know
how
to
strike
through
so
I'll,
just
delete
it
and
touch
on
that
later,
cool
yeah.
I
just
keep
realizing.
We
need
some
vlogging,
so
yeah,
that's
definitely
a
music
thing,
but
cool.
E
B
Start
out
like
we
normally
do,
let's
take
a
look
at
our
project
board.
I
guess
I
put
a
little
status
update
here,
like
we've
got
a
lot
of
velocity.
I
think
this
past
week
so
showing
good
signs
we're
still
at
like
five
to
do,
and
so
I
think
we're
we're
getting
close.
B
We
probably
should
talk
about
a
release
that
was
brought
up
in
the
slack
channel
at
some
point
in
agenda,
but
I
haven't
added
that
yet
maybe
we
can
talk
about
that
at
the
end
jumping
in
here
I'd
like
to
kind
of
go
over
some
of
the
stuff,
that's
still
open,
I
think
mostly
in
progress.
These
are
all
pr's,
so
probably
all
related
to
these
things
in
open.
B
I
don't
know
if
nelson
is
going
to
be
here,
but
I
can
probably
talk
a
little
bit
about
the
stuff
that
I'm
doing.
I
know
that
this
has
an
open
pr
for
it.
I
think
it's
actually
resolvable.
B
It
just
needs
another
approval,
josh
kind
of
already
approved
it,
but
it
wasn't
a
legitimate
one.
So
I
don't
know
if
josh
would
want
to
get
the
official
stamp,
but
yeah.
B
When
I
lgtm
did
right,
yeah
you're
100
right,
I'm
just
yeah,
totally
yeah.
If,
if
people
would
like
to
review
it,
it's
kind
of
a
bigger
one,
I
could
split
this
up.
It
also
is
just
I
don't
know
if
people
want
me
to
split
this
up,
I'm
happy
to
there's
multiple
things
in
there,
but
it's
a
lot
of
cleanup,
and
so
it
just
if
you
wanted
to
split
up
just
comments
on
the
issue,
and
I
can
do
that.
B
Otherwise,
it's
nice
to
just
kind
of
push
this
one
through
there's
a
lot
of
cleanup.
That
still
needs
to
be
done.
I
think
in
the
until
pxporter,
but
yeah
don't
want
to
get
too
many
conflicts.
B
Yeah,
that's
exactly.
I
think
that
the
only
thing
that
is
net
new
is
in
the
http.
It
uses
the
exponential
back
off
package
that
we
use
in
grpc,
but
otherwise
yeah
it's
just
moving
code
around.
So
we
could
do
that
in
a
unified
way
and
then
cleaning
up
some
other
things,
but
yeah
yep.
That's
all
it's
doing
so
yeah,
that's
in
progress
still
being
reviewed.
B
I
can
talk
about
this
one
which
was
kind
of
a
follow-on
of
the
issue
that
bogdan
had
opened
up
about
removing
the
hotel
test
dependency
on
api,
which
is
done
going
through
the
hotel
test
package
itself.
I
was
talking
a
little
bit
with
bogdan
about
this
asynchronously
and
I
think
that
we
included
this
the
last
minute
before
we
did
the
release
candidate,
because
we
realized
there's
a
dependency
on
this
from
the
api
and
other
stable
packages
that
we
were
releasing.
B
But
I
don't
know
if
we
put
that
much
thought
into
a
lot
of
the
content.
That's
in
here,
and
so
I
think
bogdan
when
he
was
looking
through.
This
is
was
correctly
calling
us
out
on
some
of
the
stuff,
and
so
I
think,
there's
a
good
opportunity
to
clean
up
a
lot
of
stuff,
which
has
already
happened.
There's
been
a
whole
slew
of
pr's
that
people
have
probably
already
seen
that
are
just
like
really
good
indicators
that
we
needed
to
clean
up
some
stuff.
B
It
was
just
kind
of
sorely
needed,
but
this
is,
I
think,
the
following
thing:
that
one
of
the
things
that
bogdan
was
kind
of
pointing
on-
and
I
wanted
to
touch
on
a
little
bit
later-
is
that
the
testing
that
we
have
in
here
with
the
trace
provider
and
tracer
and
the
span
are
a
separate
code
path
from
what
the
production
use
of
the
sdk
is
and
so
like
that
presents
a
problem
which
I'll
probably
talk
a
little
more
about
later.
B
But
then
the
other
part
is
that
there's
a
lot
of
stuff
in
here.
That's
just
not
used
externally,
and
that
just
is
you
know,
it's
bloating
the
api,
so
I've
got
two
pr's
out
right
now.
That'll
remove
essentially
this
unused
trace
state
from
t
values
function
and
it's
otel's
test
harness
function,
so
that
should
progress
it
and
then
I
think
the
next
part
is
just
kind
of.
We
need
to
talk
a
little
bit
more
about
so
hopefully
later
on
in
the
agenda.
We
can
dive
into
that.
B
Okay,
I
know
I
saw
the
pr
that's
related
to
this.
This
was
another
bogdan
issue
related
to
the
implementation
details
of
the
api,
the
link
itself,
it
contained
a
dropped,
attribute
account
which
is
not
something
specified
in
the
api,
something
specified
in.
B
Actually
I
don't
even
in
the
sdk,
but
in
our
sdk
we
track
this,
and
so
the
goal
is
to
take
that
out
of
the
api
and
nelson
z,
if
you're
watching
this
on
recording
sorry,
if
I'm
butchering
your
username
has
proposed
adding
some
changes,
and
I
think
that
they're
moving
back
and
forth
a
little
bit
on
this
one,
but
the
idea
is,
we
wanted
to
essentially
move
this
link
type
or
create
a
new
link
type
in
the
sdk
and
leave
the
api's
link
there.
B
Just
you
know
this
used
to
be
in
the
api,
but
we
dropped
this
and
then
update
the
sdk
to
reference.
This
link
type,
the
reason
that
we
need
this
new
link
type
in
the
sdk.
Well,
it's
a
little
bit
unfortunate.
It's
going
to
be
a
redundant
type
across
packages.
B
The
sdk
needs
to
export
this
and
it
needs
to
export
it.
As
a
typed
structure,
I
mean,
I
guess,
there's
other
options
but
like
they're
worse
than
having
their
own
link.
So
that's
why
there's
a
new
link
there?
That
was
the
proposal.
There
is
a
pr
open
that
needs
actually.
Is
it
a
fully
fledged
pr?
Is
this
still
a
draft?
B
Okay?
It's
a
draft!
I
think
it's
ready
for
review,
but
I
didn't
want
to
click
the
button
for
somebody
so
yeah.
I
think,
if
they're,
if
you're
interested
in
this
there's
a
proposed
solution
here,
it
could
use
some
feedback
in
the
draft
stage.
I
guess,
but
I
think
it's
also
ready
for
a
full-on
review.
B
The
next
one
that's
currently
active.
Is
this
verifying
the
updates
of
the
ftlp
documentation
submarine?
I
don't
know
anthony.
Is
this
a
intern,
or
just
I
think,
wuhan
university?
Maybe
I
don't
know,
don't
think
so,
not
familiar
with
them.
Yeah!
Okay,
I
think
it's
just
a
first-time
contributor.
They
opened
up
a
pr
here.
It
needs
some
feedback
or
there's
been
some
feedback.
It
needs
some
revisions.
B
So
it's
just
a
matter
of
iterating
on
this.
It
might
be
stale
at
this
point,
so
I
think
maybe
wait
another
week
or
something
like
that
and
then
we'll
have
to
have
somebody
else
take
over
this.
It's
not
too
complex,
and
I
think
this
is
actually
a
good
one.
For
a
new
contributor
to
the
project
just
needs
some
some
love
from
the
author.
B
Okay,
so
that's
everything
in
the
in
progress
and
that's
due.
There
are
a
few
things
I
kind
of
wanted
to
talk
about.
This
came
in
yesterday
and
I
included
it
here
because
it
would
be
a
breaking
change,
but
it
is
it's
a
naming
issue.
So
obviously
it's
going
to
be
contentious
so
put
on
your
contention,
hats,
but
the
idea
here
is:
I'm
not
100.
I
follow
everything
but
from
what
I
gather
commonly
this
kind
of
goes
back
to
the
issue
that
bogged
in
it
open.
B
There's
too
many
trace
packages.
I
think
the
idea
is
that
we're
using
import
aliases,
often
and
when
you
have
tooling
like
it's
referred,
here's
go
imports
or,
if
you're
building
godox
it's
hard
to
understand
where
the
imports
are
coming
from,
meaning
that,
if
you
have,
as
in
this
example,
shows
some
code
right
here,
it's
in
your
main
package
and
you
run
the
go-
imports
function
on
it.
It
can
figure
out
the
standard
out
import.
B
B
So
I
think
the
proposal
here
is
that
we
rename
the
trace
package
in
the
sdk
package
to
sdk
trace
initially.
I
wasn't
particularly
excited
to
hear
this
just
because,
like
it's
been
so
long
and
renaming
packages,
it's
just
a
makes.
Everyone
really
unhappy.
That
being
said,
it
might
be
a
better
experience
and
if
we're
gonna
do
it,
we
needed
it
before
the
1.0.
So
I
wanted
to
bring
it
up
and
make
sure
that
everyone's
aware
about
it
and
put
your
feelings
in
here.
B
I
think,
if
there's
only
one
proposal
in
here,
I
did
ask
to
see
if
there's
like
other
identifiers,
that
we
wanted
to
actually
address
that
we
are
commonly
aliasing.
I
think
that
there
isn't.
Actually,
I
think
this
is
one
of
them
well
outside
of
the
metrics
package.
I
think
that
this
is
one
of
the
only
overlapping
terms,
so
this
might
not
be
as
contentious.
B
I
know
that
if
you
do
change
this,
we
are
going
to
have
to
change
the
trace
test
package
that
sits
under
this,
but
I
think
that's
just
kind
of.
B
D
Today,
I
I
updated
some
dependencies
some
dependencies
and
saw
several
packages
that
I
was
using
that
had
this
kind
of
stuttering
in
them,
where
I'm
down
along
the
package
path
and
keep
repeating
the
name
of
the
parent
path,
components
and
the
leaf
package
name
looks
a
little
weird.
I
haven't
seen
this
done
in
other
projects.
B
Yeah
there
you
know
there
are
things
like,
as
listed
here
like
http
utils
in
the
standard
library.
Does
this.
I
know
that
there's
testing
packages
in
the
standard
library,
where
we
based
our
testing
game
off
of
that
being
said,
I
don't
know
if
there's
like
a
three
layer
deep
prior
art
example,
kind
of
like
our
otlp
trace,
grpc
packages
or
something
like
that,
but
I
yeah,
I
think,
we're
kind
of
where
no
one
has
gone
before.
B
If
you
will
in
the
star
trek
parlance
here
and
so
yeah,
I
don't
know
if
there's
really
a
good
understanding
here
that
I
I
you
know,
I
know
our
testing
packages
were
influenced
by
some
of
the
go
contributors,
but
I
don't
have.
I
don't
have
a
really
good
answer.
There.
A
In
my
draft
api,
pr,
which
won't
be
discussed,
but
it's
a
couple
weeks
old,
I
also
experimented
with
keeping
short
import
paths
which
has
exactly
the
problem.
That's
being
complained
about
in
this
issue,
so
I
I
feel
both
sides
of
it.
I've
had
a
lot
of
problems
with
auto
imports.
I've
also-
and
I,
like
short
path
names.
I
don't
know.
B
Yeah,
I
agree,
I
feel
like
having
things
like
this.
In
the
duplicate
I
mean
it's
essentially
geometric
scaling
of
import
names
is
not
really
ideal.
Package
names
and
go
are
supposed
to
be
descriptive
of
a
you
know,
a
cohesive
set
of
tooling
that
does
a
unified
set
of
things
like
that.
B
I
don't
know
that
seems
to
not
follow
that
pattern
in
some
I
don't
know,
maybe
maybe
subjective
way,
but
at
the
same
time
like
I
was
going
to
discount
this
outright,
but
hearing
things
like
this
specifically,
you
know
that
that's
a
real
thing,
like
that's
users,
are
actually
going
to
do
this
they're
going
to
write
this
code
and
they're
going
to
copy
examples,
and
this
isn't
going
to
work
with
go
imports
and
they
have
to
go
figure
out
like
what
does
sdk
trace
actually
come
from
and
like
what
is
that
whole
thing
you
know
and,
and
so
like?
B
I
think,
that's
that's
totally
valid
in
our
docs.
We
often
reference
these
sort
of
like
common
aliases,
and
we
don't
like
it's
not
official.
B
You
know
using
the
terms
like
sdk
trace
in
the
docs
is
pretty.
You
know.
We
know
what
it
means,
but
I
think
a
new
user
might
assume
there's
a
package
called
sdk
trace
so
yeah.
I
think
that
this
is
worth
the
discussion
and
why
I
brought
it
up
here.
C
C
B
A
A
B
Keep
in
mind
in
the
conversation,
though,
this
question
keeps
coming
up,
and
so
I
think
there
are
situations
where
you
are
finding
users
and
it's
pretty
common
that
they're
finding
them
importing
these
packages.
I
mean,
I
definitely
think
importing
the
sdk
trace
package
or
the
sdk's
trace
package
is
going
to
be
done.
Anybody
who's
going
to
be
running.
The
sdk
is
going
to
be
importing
this,
but
you
know
like
that.
This
is
this,
is
the
clinch?
B
This
is
going
to
be
the
person
who
is
the
first
time
to
this
project
and
has
a
very
limited
set
of
patients
to
deal
with
like
this
kind
of
stuff
and
is
probably
going
to
get
turned
off
by
using
the
project
by
saying
like
well,
you
know
like
it
was
too
frustrating
to
set
up
because,
like
go,
import,
didn't
even
work
for
me,
which
is
maybe
not
the
most
valid
complaint,
because
you
know
you
probably
have
to
work
through
it,
but
I
think
it
like.
B
This
is
also
something
that
we
want
to
try
to
like
win
that
user
space
like
we
want
those
users
to
have
a
positive
experience
going
forward
the
long
time
users,
I
think,
are
the
ones
that
are
going
to
complain.
The
other
way
they're,
like
they've,
used
this
all
over
the
place
now
they're.
Finally
saying
like,
why
do
I
have
to
like
write
these
massive
package
names
all
the
time
or
reference,
these
massive
package
names?
B
And
I
I
think
that
the
the
latter
is
somebody
we
can
say
like
well,
you're
welcome
to
alias
to
a
shorter
one.
If
you
would
like
is
what
my
thought
is
on
that
one.
D
Really
confusing
where
you
know
I'm
doing
a
triple
take
at
the
import
path
and
I'm
looking
at
the
code
of
the
file.
Oh
man,
I
gotta
go
open
the
source
file
to
figure
out.
What's
really
going
on
there.
A
My
tooling
will
insert
the
alias
to
to
make
that
clear.
At
least
the
latest
later
versions
of
the
tooling.
A
Because,
yes,
so
it
takes
the
solution
that
anthony
described.
It
reads
the
file
when
you,
when
you
successfully,
have
an
import
and
you
save
the
file
it
like
writes
in
aliases
for
all
those
misnamed
packages,
but
the
way
the
tooling
works.
For
me
in
emacs,
like
once,
it's
kind
of
knows
the
project
I'm
working
in.
I
can
create
that
same
name
like
sdk
trace
in
a
new
file,
and
it
knows
the
sdk
trace
maps
to
the
thing
that's
been
aliased
has
to
be
traced
because
it
was
once
identified,
I
guess
yeah.
B
I
I've
experienced
the
same
thing.
I
think
as
steve
was
talking
about
where
I
go
and
I
I
write
the
import
path
that
I
want
to
use
and
then
I
go
to
try
to
use.
You
know
something
that
says:
standard
trace
and
the
package
name
is
trace
or
something
like
that
and
I'm
like
wait.
Why
is
this
not
referencing
it
correctly
or
something
like
that?
I
don't
know
I'm
obviously
not
as
cool
as
josh
and
using
people.
A
C
Yeah,
I
think
either
way
is
going
to
cause
some
churn.
The
suggestion
to
not
change
the
import
path
would
just
be
to
try
to
minimize
the
amount
of
rewriting
that
we
have
to
do
with
examples,
and
the
users
are
going
to
have
to
do
in
packages
that
are
already
importing
it.
D
Yeah
I
mean
that
is
feels
to
me
too,
like
sort
of
jamming
the
jamming
the
path
components
again
into
the
leaf
package.
Name
then
fights
against
being
able
to
reorganize
it
later
too,
which
I
understand
would
also
be
a
breaking
change
and
go.
A
different
import
path
is
strictly
a
different
package,
but
we
have
over
the
course
this
project
rearranged
the
package,
the
directory
hierarchy
many
times.
D
So
I
understand
we're
trying
to
converge
on
a
version
one
stable
here,
but
it
seems
like
it
really
seems
like
a
job
for
better
tooling,
rather
than
bending
the
package
names
to
deal
with
the
current
two
element.
B
Yeah,
I
think
there
could
be
better
tooling
if
you
have
an
import
path,
that's
different
than
the
package
name,
but
I
don't
think
that
there's
ever
going
to
be
tooling,
I
mean
I
guess
there
can
be
like
some
fuzzy
logic
going
on
here.
That's
just
going
to
guess
what
sdk
trace
is,
but
there's
no
package,
that's
actually
an
investigate,
trace
right
and
there's
no
import
path.
That
actually
has
it
ending
in
sdk
trace.
So
like
your
tooling,
is
going
to
have
to
just
kind
of
you
know.
B
D
For
using
this
sdk
trace
package
name
because
you've
had
multiple
packages
named
trace
imported
in
the
same
file.
Yes,.
B
And
I
think
like
in
this
example,
it's
hard
to
tell
because
there's,
like
you
know,
ellipses
here,
but
like
you
know,
maybe
they
also
imported.
The
api
trace
package
here
is,
I
think,
the
concern,
but
I
think
it
to
be
more
specific.
B
To
what's
going
on
here
is
that
I
think
the
new
user
came
along
and
they
found
an
example
and
that
example
solves
their
problem
and
in
the
example
there
was
a
conflict
of
the
imports
in
the
example,
it
actually
showed
instrumentation
and
it
showed
the
sdk
setup.
So
there's
like
a
conflict
of
like
the
import
packages,
but
all
they
care
about
is
one
or
the
other
right,
and
so
they
copy
just
that
part
and
they
put
it
in
their
code
and
they
go
like
well.
B
B
If
that
makes
sense,
so
I
think
that
we
could
probably
talk
this
one
into
the
grounds.
I
think
that
there's
been
a
lot
of
really
good
conversation
so
far,
so
I
kind
of
want
to
move
on,
but
I'm
gonna
probably
put
some
more
comments
in
here
later
on,
but
if
you
have
any
opinions
or
or
ideas
or
suggestions,
please
do
so
as
well.
B
I
would
like
to
have
the
conversation
resolve
the
issue
before
we
get
a
pr
opened
either
or
if
there
isn't
gonna,
be
a
pr
and
close
it
so
cool
the
other
one
is
see
we're
at
25
minutes.
I
wanted
to
double
check
I'll,
probably
give
this
five
minutes,
then
this
is
another
one
I
wanted
to
talk
about
in
this
issue.
We
talked
a
little
bit
about
this
in
the
past
for
splitting
out
the
span
configs
and
last
week.
B
I
think
we
talked
about
if
this
needs
to
be
actually
like
allocated
and
making
sure
that
this
allocation
is
valid.
Maybe
that's
just
what
it
is
yeah.
Okay,
maybe
I
won't
talk
about
this
I
forgot,
but
that
we
came
up
with
this.
Like
ghost
allocation
thing,
I
wanted
to
see
if
there
was
appetite,
because
this
would
completely
change
the
way
that
we
would
want
to
specify
our
configs
potentially.
But
I
think
that
there's
an
action
item
here
that
we
haven't
actually
taken
action
on.
B
So
I
think
we
can
move
on
from
this
sorry.
B
Cool
the
other
ones,
I
think,
have
a
pretty
good
understanding.
Maybe
this
one
needs
the
extra
five
minutes.
What
I'm
thinking
is
there
a
consensus
amongst
the
group
to
go
back
to
using
a
start
and
an
end
span
config
or
to
just
leave
the
unified
one.
B
I
don't
think
so.
I
think
oh
no,
I
take
that
back.
You
are
100
right.
We've
had
this.
Yes,
that
was
a
long
conversation.
Wasn't
it
where
we
decided
that
one.
Let's
double
check,
though,.
F
Well,
one
of
the
there
are
options
that
work
in
one
place
or
another.
There's
options
that
work
in
both
the
start
and
the
end
and
like
you
could
have
different
options:
trucks
underneath
them,
but
I
don't
know
like
that.
I
know
I've
waffled
back
and
forth
on
this
a
number
of
different
times.
I
don't
I
don't
know
if
there's
going
to
be
any
good
solution
that
that
solves
all
of
them
all
of
the
different
use
cases.
So
just
a
heads
up,
I've,
I've
treaded
this
path.
C
Before
so,
we
have
separate
option
types
for
start
and
end,
which
means
that
the
start
will
only
take
the
start,
start
options
and
end,
we'll
only
take
the
end
options
and
it's
on
start
and
end
to
use
the
config
as
appropriate
and
only
use
the
values
that
they
should
be
using
out
of
them.
I
think,
to
that
extent,
it's
probably
safe
to
use
a
combined,
config,
safe,
ish,
there's
always
the
potential
that
an
implementation
of
a
start
or
end
could
decide
to
use
some
value
that
it
shouldn't
be
using.
C
Like
you
know,
an
end
could
take
lengths,
but
there's
no
way
to
set
links
in
the
span.
Config
with
a
span
end
option,
so
I
think
it
would
be
a
an
a
mostly
internal
change
right.
It
shouldn't
affect
anything
externally,
shouldn't
impact.
It
any
other
way
that
anybody
calls
anything
or
interacts
with
anything.
It
would
change
the
sdk's
implementation
to
start
and
end
so.
F
I
think
I'm
fine
with
it
there
could
be.
I
believe
you
can
capture
yeah,
you
can
call
a
new
start.
Config
capture
a
span
config
in
which
case
in
configs
would
start
and
end
configs
would
be
different.
I
don't
know
why
you
would
do
that,
but
you
could.
B
I
mean
so
it
would
if
we
did
change
that
it
would
be
an
api
change
right
like
these
are
exported.
The
uses
of
those
is
not
expected.
You
know,
as
sdks
are
expected
to
use
them,
which
I
guess
is
something
that
we've
always
kind
of
said
is
like
that's
fine.
As
long
as
we
break
those
going
forward,
you
know
if
it's
an
sdk
responsibility
like
that's
something
we
could
change
in
the
future.
B
I
what
you
said
that
anthony
just
kind
of
like
you
know,
bogdan's
point
here
is:
is
that
it'd
be
good
to
have
separate
cafes
because
of
the
clearly
identify
which
properties
apply
to
which
operation?
I
think
that,
like
having
different
option
types
already,
does
that
you
know
like
you're,
never
going
to
take.
You
know
this
config
unless
you're
an
sdk
author
and
and
work
with
it,
you
know
only
only
people
that
are
actually
in
the
sdk
are
going
to
work
with
that,
but.
C
B
Yeah
exactly
so,
I
yeah
I'm
kind
of
on
board
with
just
closing
this
and
we
I
can
find
the
old
issues
where
we've
actually
gone
this
direction.
So
you
know
aaron
you're
in
good
company,
for
waffling
on
this
because
we've
talked
about
this.
I
think
we've
gone
back
and
forth
on
this
one.
So
yeah
you're,
not
alone,
okay,.
C
B
Don't
speak
too
loudly
he's
pretty
good
at
hearing
things
like
that
cool.
I
want
to
get
back
to
the
agenda
at
this
point
we're
halfway
through
the
hour,
and
so
I
think
we
have
some
good
discussion.
I'm
going
to
try
to
update
on
this
I'll.
Take
the
action
over
to
put
a
comment
on
this.
B
But
the
next
thing
I
wanted
to
talk
about
was
something
I
had
brought
up
a
little
bit
earlier
about
the
hotel
test
package
and
I
just
put
down
like
in
words
something
I
think
we
were
talking
about
in
the
last
sig
meeting
and
it's
just
this
underlying
instrumentation
testing
strategy
problem
and
I
y'all
can
read
it
and
I
can
just
read
it
off
to.
I
guess:
yeah
right
off
to
you
in
case.
B
You
can't
see
the
screen
right
now
to
verify
the
correct,
like
traces
and
spans
are
produced
from
instrumentation.
An
sdk
implementation
of
the
api
is
needed,
so
not
testing
the
default
sdk,
which
is,
as
far
as
I
know,
is
the
only
one
that's
used
in
production
means
that
the
instrumentation
will
not
be
tested
in
the
same
way
that
it
will
actually
be
run
in
production.
B
B
So
it's
kind
of
like
a
rock
and
a
hard
place
is
kind
of
how
I'm
seeing
this
problem,
and
this
is
something
that
bogdan
raised
as
an
issue,
because
he
was
testing
and
he
was
testing
with
the
hotel
test
and
everything
was
working
fine
and
then
he
went
to
go,
use
the
actual
sdk
in
production
and
well,
it
wasn't
production
but
like
in
a
real
world
situation,
and
it
didn't
work
or
just
worked
differently.
I
think
was
the
issue
that
he
came
up
with
and
that's
that's
really
not
good.
B
You
know
providing
some
sort
of
testing
utility
to
inspire
confidence
that
you're
going
to
work
and
that
that's
the
one
of
the
strong
points
of
using
go
in
general.
So
I
think
we
should
try
to
do
that,
but
yeah
this
like
this
idea,
then
you
have
to
take
a
dependency
on
the
sdk
is
also
not
good.
B
So
one
of
the
things
that
I
was
thinking
about
is
we
could
try
to
set
up
a
pattern
where
the
actual
integration
testing
could
be
done
in
its
own
module.
I've
been
looking
through
a
lot
of
the
go
issues
on
trying
to
split
up
testing
dependencies
in
a
module.
I
don't.
This
is
the
thing
that
bargain
was
really
confused
about,
because
in
java
your
dependencies
are
listed,
you
know
and
if
you
only
use
them
in
testing
they're
annotated
as
only
testing.
B
So
when
you
build
the
final
binary
like
it's
not
included,
and
I
think
that
when
you
build
a
final
binary
here,
it's
not
included,
but
the
problem
is
that
it
imports
it
and
a
lot
of
you
know,
people
see
that
import
and
their
package
mirrors
hosted
and
having
it
locally
is
something
that
may
cause
consternation
as
well
as,
like
other
you
know,
dependencies
down
the
chain.
They
have
to
then
import
that
as
well.
B
So
I
think
that's
a
real
concern
that
people
have
and
I
just
want
to
see
like
you
know,
I
don't
know
of
a
really
good
solution
here.
In
fact,
I
don't
know
if
there
is
going
to
be
one,
but
this
is
one
that
kind
of
came
to
mind,
and
I
don't
that
has
downsides,
but
I
was
just
wondering
what
other
people
thought
about
this.
C
Well,
one
of
the
the
things
that
I
think
it
really
complicates
is
being
able
to
have
faith
that
a
given
instrumentation
that
you
want
to
import
can't
do
anything
with
your
sdk,
like
it
can't
grab
your
tracer
provider
and
make
any
changes
to
it
or
anything
like
that,
because
it
doesn't
import
the
sdk
packages
if
it
imports
them
and
they
appear
and
it's
go
mod
and
go
some.
You
then
have
to
go
and
read
through
everything.
C
B
Right
right,
yeah
yeah,
exactly
so
what
I'm.
C
B
Yeah
I
so
I
think
that
we
can
you
know
what
people
want
to
do
in
the
wild
is
up
to
them.
You
know
I
I'm
pretty
good
at
doing
horrible
things
in
the
wild
yeah,
but
I
think
that
what
we
can
do
in
the
contributor
is
provide
a
positive
example.
B
I
think-
and
that's
that's
the
real
question
I
keep
coming
back
to
is
like
what
do
we
want
to
do
with
our
instrumentation,
because
I
definitely
don't
want
to
have
our
instrumentation
depending
on
the
sdk,
even
though
I
know
that
we're
not
going
to
be
doing
some
like
you
know,
weird
things
where
we're
reaching
into
the
sdk
to
get
things
done,
or
I
hope
we
aren't
going
to
do
that.
B
That
should
be
something
we
don't
do,
but
I
also
want
to
provide
that
confidence
that,
like
yeah,
if
you
use
our
http
instrumentation
with
our
default
sdk,
things
are
going
to
work
as
we
as
we
intend
them
to
work
for
you,
and
so
I
think
that
if
you
have
something
like
the
hotel,
http
library
and
then
there's
something
like
a
god,
this
is
horrible.
An
hotel
http
test
module
that
sits
alongside
it
or
even
even
underneath
it
and
that
imports
the
sdk
and
if
it's
its
own
module.
B
I
I
think
that,
like
you
can
do
integration
testing
there,
because
you
can
do
the
imports.
You
can
import
a
lot
of
other
things.
Users
aren't
going
to
be
directly
importing
that
unless
they,
I
don't
know
unless
they
want
to,
but
I
I
think
that's
a
good
way
to
partition
it,
given
the
tooling
that
we
have
and
the
way
the
go
ecosystem
works
is
what
my
thought
is.
B
B
Right,
that's
a
good
point
right,
so
all
we
would
be
doing
yeah.
Let's
look
at
some
actual
things
like
this.
Like
there's
an
example
here,
that's
his
own
module
right
and
this
I'm
not
mistaken
yeah.
This
pulls
in
the
sdk,
so
yeah.
I
guess,
since
we
already
kind
of
do
this,
if
we
had
some
additional
module
here
called
I
don't
know,
we
could
just
call
it
test
honestly,
because
we
really
would
never
expect
anybody
to
actually
import
this
and
that
test
right.
B
There
could
then
pull
in
the
sdk,
and
it
could
then
fully
verify
you
know
it
can
pull
in
the
sdk
plus
other
testing
apparatus
right
now,
it'd
be
really
nice
to
have
that
span
recorder
as
well
pulled
in,
and
you
know,
then
this
go
mod
would
be
you
know
very
stripped
out
and
you
would
have
a
very
lean
dependency
tree
specifically
like
all
of
the
testing
dependencies
outside
of
unit
testing
wouldn't
be
wouldn't
be
included
when
you
imported
that
instrumentation.
C
F
B
So
this
is
the
problem,
though
aaron
is
that
this
imports
hotel
test
right
and
one
of
the
things
that
bogdan
was
kind
of
pointing
out
is
like
well,
one
hotel
test
isn't
really
good,
because
it's
not
actually
importing
it's
not
using
the
sdk.
The
sdk
is
the
thing
that
people
are
going
to
be
using
in
production.
This
has
a
totally
different
implementation
of
the
tracer
provider,
the
tracer
and
the
span
here
and
you're
going
to
get
behavior
that's
unique
to
the
hotel
test.
B
That
is
maybe
not
going
to
be
uni
part
of
the
sdk
itself,
and
so
this
is
not
a
really
good
testing
strategy
here,
because
you're
going
to
run
into
issues
where
one's
positive
or
or
the
other
is
negative,
and
that's
not
a
really
good
situation.
C
F
Yeah,
I
think
I'm
in
an
agreement
other
than
the
fact
that
if
the
slim
sdk,
the
the
non-operable
sdk,
that's
in
otel
test
has
different
has
different
behavior
than
the
default
sdk.
What
do
we
get
from?
What
value
do
we
get
from
testing
against
that?
Because
that's
not
really
what's
being
used.
B
Right
and
and
that's
where
I'm
of
the
opinion
of
it,
we
should
just
get
rid
of
it.
I
mean
there's
the
no
op
tracer
provider
and
the
no
op
setup
that
like.
If
you
really
wanted
to
have
that
kind
of
setup
you
can.
You
can
even
use
that
to
wrap
testing
infrastructure.
That
is
extremely
light.
It
can
be
very
customized
but
yeah,
exactly
like
all
you're
doing
here
is
you're
validating
that
this
mux
instrumentation
works
with
the
hotel
test.
B
C
Well,
it
it
does
more
than
that,
though
right
it,
it
does
validate
that
the
hotel
or
the
the
auto
max
instrumentation
is
using
the
api
to
take
the
actions
that
this
test,
harness
is
saying,
have
been
taken
right.
Some
span
was
created
somewhere
in
this
in
this
action,
and
we
can
see
that,
and
it
has
the
attributes
that
we
expect
the
span
to
have
been
created
with
through
the
api.
So
we
we
can
test
that
hotel
mux
is
using
the
api
through
this
harness
well.
B
I
think
you're
right
like
that.
That's
a
good
point
it
is.
It
is
a
really
good
way
to
show
the
api
is
actually
being
used,
but
the
problem
comes
with,
like
the
second
part
of
that,
where
you're
saying
that
it's
using
the
api
to
produce
the
right
things,
and
that's
like
the
issue
that
bogdan
raised
was
that,
like
it
wasn't
actually
producing
you
know,
a
pass-through
span,
context
right,
but
it
should
have
been
and
so
like.
B
That's
where
you're
like
well,
it
should
be
creating
these
sorts
of
things
going
down
the
road
you're
like
well
wait.
Why
isn't
this?
This
is
a
bug
like
this
is
obviously
a
bug
like
my
instrumentation's
wrong,
it's
like
well,
actually,
it's
not
it's
the
implementation
of
an
hotel
test
that
was
wrong,
and
so
I
I
mean
like.
I
think
that
we
could.
B
You
know
we
could
say
like
we
could
do
a
really
good
job
in
keeping
hotel
tests
really
well
like
maintain
in
sync
with
the
sdk,
but
all
you're
doing
is
you're
just
adding
burden
that
like,
if
you
have
a
testing
framework,
and
you
split
the
test
to
just
use
like
an
integration
test
package,
you're
guaranteed
to
have
that
that
working
implementation
of
the
sdk
produce
the
things
that
you're
expecting
and
you
know
like.
Then
we
wrap
the
sdk
with
a
spanner
or
something
like
that.
I
think
is
you
know
how
we
could
refactor.
C
B
Yeah,
that's
that's
my
understanding,
so
anything,
that's
not
importing
the
hotel
test,
so
I
guess
this
would
be
reserved
or
would
be
kept
here
and
then
you
would
take
all
of
these
hotel
tests.
Things
and
you'd
move
them
to
an
integration,
testing,
module
of
some
sort
and
then
that
that
would
just
import
the
sdk.
B
That's
my
idea,
I
kind
of
wanted
to
put
it
forward.
I
I'm
working
a
lot
with
the
hotel
test
package,
so
I
can,
I
can
put
a
proposal
together.
B
I
can
probably
do
it
actually
in
the
contrib
and
then
like.
I
can
share
it
out
in
the
slack.
It's
like
a
draft
or
something
like
that.
Does
that
sound
reasonable?
C
B
Completely
agree,
then,
keeping
on
I've
got
this
impossible
to
track
active
span
issue
that
bogdan
also
opened.
I
talked
a
little
bit
about
this
as
well,
but
in
the
interest
of
time
this
isn't
actually
something
I
think
that
needs
to
be
addressed
for
the
rc.
So
maybe
we
kind
of
move
on
to
the
metric
stuff.
I
want
to
get
make
sure
we
have
enough
time,
which
we
don't
there's
only
15
minutes
didn't.
He
also
build
a
z
pages
implementation.
B
Yeah,
that's
why
it's
not,
I
think,
required
for
the
act.
The
rc,
although
to
be
fair,
bogdan's,
really
smart
and
he's
absolutely
right,
but
like
the
contention
there
is
that
the
pointer
is
guaranteed
to
be
unique
and
the
span
and
trace
id
are
mostly
guaranteed
to
be
unique
but
yeah.
So
that's
that
was
the
contention.
I
think
there's
a
lot
more
and
there's
some
interesting
topics
to
happen
there.
B
One
specifically
was
that
he
also
has
in
this
another
proposal
where
we
add
something
on
to
the
span
providers
that
would
essentially
track
started
and
ended
spans.
It
would
also
really
help
in
memory
optimization,
but
I,
if
you're
interested,
go,
read
this
and
then
when
it's
really,
you
know
confusing
ping
me
and
slack,
because
I
kind
of
wanted
to
keep
on
moving
and
also
apologize,
because
I
know
josh
has
been
doing
a
lot
of
really
great
work
and
needs
more
attention
and
I
think
more
time
in
this
meeting.
B
So
I
wanted
to
make
sure
we
get
some
time
here,
okay,
so
josh.
I
had
included
this
one
to
talk
about
in
the
agenda
here,
but
if
you
feel
like
these
should
take
priority,
we
can
talk
about
this
next.
A
Let's
see
if
I
can
find
josh.
Thank
you.
Actually.
I
would
prefer
to
talk
about
the
one
that
you
put
in
there
and
drop
the
rest
for
next
time,
they're
connected
in
ways
that
make
sense
to
me,
but
I
don't
want
to
try
and
bring
you
all
into
my
internal
drama
right
now.
The
first
one
is
enough.
Thank
you.
I
only
have
five
minutes.
A
I
have
to
go
to
like
an
end
of
summer
school
thing
in
in
five
minutes,
so
or
so
so
I
I
think
you
understood-
or
at
least
I
understood
your
your
your
concern.
I
am
definitely
trying
to
achieve
several
things
at
once,
so
it
may
be
confusing
why
particularly
the
order
I'm
sending
these
prs
in,
I
think
it
does
make
sense
to
try
and
isolate
these.
A
A
I
I've
given
two
labels
to
this
sort
of
a
choice
we
have
which
is
meter
as
struct
or
meter
as
interface,
and
I
I
know
that
I
was
trying
to
find
some
some
writings
on
this
topic
from
sort
of
other
people
in
the
field
or
going
team
people.
But
I
couldn't
in
the
time
I
gave
it
earlier,
but
basically
I
strongly
feel
and-
and
I
would
like
to
convince
you-
that
that
having
the
meter
be
a
struct
and
having
the
implementation
interface
be
a
lot
narrower
than
the
user.
A
Interface
is
helpful,
but
it
is
an
option
to
do
kind
of
what
you're
describing
we
could
put
together
an
api
proposal.
That
was
just
a
bunch
of
interfaces,
but
it
ends
up
being
like
a
lot
of
interfaces
like
12
or
so,
or
something
like
that
or
24
of
them,
or
like
lots
of
little
things,
and
the
reason
why
I
prefer
the
the
struct
representation
is
that
we
don't
have
to
do
that.
A
But
why
this
matters
for
us,
as
maintainers
and
of
this
code
base
itself,
is
that
global
package
and
the
global
package
has
to
not
just
implement
global
support
for
the
built-in
sdk,
but
global
for
any
sdk,
and
the
premise
of
otel
is
that
you
can
swap
in
another
sdk.
So
the
global
module
cannot
assume
that
the
sdk
is
one
of
these
sort
of
internal
apis.
It
has
to
assume
it
came
from
anywhere
in
the
world.
A
Therefore,
it
has
to
implement
the
24
types
to
wrap
around
the
interfaces,
so
we
would
end
up
creating
at
least
one
of
these
difficult
to
imitate
rep
sdks,
just
for
the
purposes
of
global
and
well
I
I
guess
it's
really
an
opinion
that
it's
simpler.
This
way,
I
don't
have
much
time,
but
I
wanted
to
say
that
much
at
least
and
I'm
happy
to
keep
discussing
this
in
the
issue.
C
B
Yeah,
I
think
that
that's
kind
of
like
you
know
we
we've
diverged
a
lot
in
the
metric
prototype
that
we
did
and
it
turned
into
this.
I
do
remember.
We
also
used
to
have
the
interface
meter
as
an
interface
pattern
as
well,
and
we
switched
away-
and
I
do
remember
the
days
where
you
had
to
go,
update
things
and
there
was
like
you
know,
a
lot
of
places
and
then
we
kept
adding
like
another
counter
or
another
gauge
or
like
all
of
the
number
types
were
also
their
own
instruments.
B
But
I
just
I
yeah
I'm
a
little
worried
that
we
have
an
api
that
is
going
to
be
the
sdk
like
that.
That's
a
public
interface
for
you,
know,
programming,
and
then
we
have
a
package,
that's
called
sdk
api,
and
so
it
just
had
like
this
weird
smell
to
me,
and
so
I'm
just
trying
to
like
understand
like
if
we
can
partition
those
sort
of.
A
Things
maybe
the
name
sdk
api
is
the
problem.
I
I
it
is
an
interface
to
the
sdk,
not
to
the
user,
but
yeah.
It
is.
I
guess
that
I
just
said
the
same
thing
again.
A
You
know
like
this
is
if
it
was
called
sdk
support
or
low-level
sdk
or
low-level
api
general
api
generic
api,
like
any
one
of
those,
it's
sort
of
like
saying,
if
you
want
the,
if
you're,
if
you're
implementing
this,
you
probably
don't
want
to
have
to
want
24
types,
and
you
should
just
implement
this
thing
with
two
methods,
and
you
can
do
that.
It's
equivalent
well,.
B
See
that's
that's
kind
of
like
what
I'm
worried
about
is
that
if
we
export
this,
what
we
have
is
is
that
you
have
from
the
input
like
if
you
want
to
write
your
own
sdk
in
your
channel.
With
this
you
can.
You
can
write
the
one
that's
in
the
metrics
package
at
the
top
of
the
project
or.
A
A
To
there
are
concrete
types
and
you
install
a
meter
provider
and
you
use
those
concrete
types.
No
one
will
ever
change
those
concrete
types
that
you
use.
We
just
changed
the
meter
provider,
okay,.
A
So
the
question
is:
do
you
how
how
do
you
implement
a
meter
provider
and
will
the
meter
provider
have
24
methods
in
it
or
underneath?
Well,
I'm
sorry,
I
I
actually
run
out
of
time,
but
I
think
at
least
we've
begun
to
discuss
this,
and
I
hope
that
the
others
here
perhaps
can
continue
to
discuss
it
without
me,
as
I
am
off
to
a
school
event.
Okay,
fun
yeah
sounds
good.
Could.
A
A
And
then
I
mean
as
then,
perhaps
we
could
also
discuss
the
next,
but
that
I
had,
which
is
about
trying
to
streamline
the
export
path
and
but
just
to
remind
everybody.
The
reason
why
I'm
trying
to
streamline
the
export
path
is
the
sort
of
incidental
I
really
wanted
to
do
to
do
was
change
meter
provider
and
because
I'm
trying
to
get
us
closer
to
the
drafts
back
and
and
right
now,
like
things
are
not
quite
right,
so
it's
all
related
to
making
it.
B
Okay,
cool
all
right,
we'll
see
you
later
josh
and
yeah
aaron
I'll
try
to
move
this
to
the
top
of
next
week's
as
well
as
I
guess
we
could
try
to
have
more
conversation
in
the
in
the
topics:
cool
garrett.
If
you're
on
the
call
yeah,
I
think
that's
right,
yeah.
I
think
you're
up
next.
G
Cool
I'll
be
real,
quick,
just
pr's
open
out
of
draft.
We
decided
that
the
force
flush
stuff
is
not.
We
don't
want
to
consider
it
blocking,
for
our
use
case,
we're
okay,
with
the
kind
of
softer
guarantee
of
spans
being
exported,
and
so
that's
open.
The
comments
on
there
are
just
about
force
stuff,
so
we're
just
okay
with
where
it's
at.
Does
that
mean
these.
G
Yes,
I
didn't
want
to
go
ahead
and
resolve
their
conversation,
but
yeah
for
all
intents
and
purposes.
Yes,
the
there's
one
blocker
there
still
for
the
cla
stuff.
The
documentation
on
our
side
is
kind
of
sparse
on
how
you
get
that
set
up,
but
I
think
I've
done
it
now
and
I've
talked
to
the
reviewer
and
how
to
take
it
open.
So
that
should
be
done
soon
as
well.
G
G
As
well,
which
one
is
that
one,
I
want
to
ask
way
about
that,
one,
because
that
one,
I
don't
really
know
what
he's
talking
about,
but
yeah
the
force
flash
part
of
it.
Yes,
that
I'll
follow
up
with
him,
but
yeah.
G
Decided
we
don't
want
to
block
on
that,
and
so
we
want
to
leave
that
issue
open
talk
about
it
later
down
the
road,
but
it's
not
like
you're
suggesting.
B
Issue,
if
I'm
reading
this.
G
Oh,
it
might
be
a
typo
in
there.
I
see,
I
see
what
he's
saying:
okay,
cool
the
only
other
thing
I
had
was
just
my
audio
cut
out
earlier.
When
we
were
talking
about
releases.
Do
we
have
rough
time
frame
on
when
when
y'all
are
thinking
about
that?
I
know
I've
been
asked
that
by
my
manager
a
few
times.
B
Yeah,
that
was
the
last
thing
we
want
to
talk
about
the
agenda.
So,
okay.
B
I
think
I
was
looking
at
a
slack
message
that
anthony
is
having,
I
think,
with
bogdan
in
the
go
channel
and
there's
a
possibility
that
we
can.
We
don't
want
to
do
a
full
other
new
release
if
it's
just
going
to
be
a
partial
step,
but
one
of
the
things
that
was
maybe
suggested
was
doing
a
release
candidate
so
dash
rc1.1
or
something
like
that
or
one
dot
a.
I
don't
know
how
to
how
you
would
version
that.
C
C
Because
it's
not
a
second
release
candidate?
It's
it's!
It's
a
change
to
release
candidate
one!
That's
not
really
a
new
release
candidate.
We
would
not
be
shipping
that
commit
if
nothing
else
came
up,
because
we
know
there's
stuff.
That's
still
going
to
change
that
was
part
of
the.
The
discussion
was
happening
with
bogdan
in
in
the
slack
channel
right.
C
We
have
outstanding
issues
that
we
know
need
to
be
fixed
before
1.0,
something
that
that
we
would
call
a
release
candidate
should
be
precisely
that
it's
a
candidate
for
release,
and
if,
if
there
are
no
issues
that
come
up
when
people
test
that
release
candidate,
we
should
be
able
to
tag
the
exact
same
commits
as
1.0.
F
B
B
Like
I
mean
to
be
honest,
aaron,
I
think
if
the
real
answer
is
like,
if
we
were
not
such
a
dependency
on
everyone,
we
wouldn't
do
a
release
at
all.
B
That
said,
the
collector
just
took
a
dependency
on
us
and
I
think,
if
they're
relying
on
some
of
the
things
that
we've
changed
in
the
interim
before
these
two
releases,
and
so
they
want
that
released
that
next
release
candidate
to
be
tomorrow,
but
we
don't
have
all
the
things
done.
Obviously
we
talked
about
the
project
board
so
yeah.
I
think
this
was
kind
of
like
a
political
like
best
of
the
worst
situations.
B
If
you
will
so
I
I
yeah,
I
don't
know,
if
there's
like
a
really,
I
mean,
I
think
everyone
on
the
call
wants
to
actually
do
release
candidate
too,
but
I
think
everyone
on
the
call
also
recognizes
we
don't
have
everything
done
for
the
next
release
candidate.
So
how
do
you
kind
of
solve
this
and
try
to
appease?
You
know
people
that
are
like
you
know
bogged
in
asking
for
this
for
the
collector
or
something
like
that
right.
F
So
I'll
be
honest,
the
the
way
I
see
release
candidates
is
very
much
how
like
the
linux
kernel
generally.
Does
it
like,
even
if
the
release
candidate,
if
you
need
something
out
there
for
people
to
test
against,
and
you
know
that
release
candidate,
it's
probably
going
to
have
another
reversion,
you
you
still
release
it
as
a
just
a
release
candidate
and
it's
okay
like
yes,
we
know
it's,
not
100
gonna
be
there,
but
if
it
needs
to
be
out
there,
why
do
we
want
to
try
and
do
this
whole
weird
mental
math?
F
B
C
No
feelings
I'll
I'll
admit
that
you
know
I.
I
have
a
particular
view
of
what
a
release
candidate
means,
and
I
I
think
that
that
may
not
be
shared
by
everybody,
so
I
would
be
perfectly
happy
to
put
it
to
a
vote
and
if
all
of
the
approvers
think
that
we
should
do
a
release
candidate
too,
instead
of
release
candidate
1.1,
which
looks
like
senber,
would
allow.
Then
let's
do
release
candidate
2,
oh
well
likely.
C
Yes,
I
just
think
it's
important
to
to
say
that
a
release
candidate,
a
new
release
candidate,
is
something
that
we
would
call
1.0.
That's
something
that's
important
to
me.
If
it's
not
important
to
anybody
else,
then
it's
not.
F
B
Okay,
I
I
I
see
aaron's
point
like
what
we're
releasing
as
a
release.
Candidate
are
potentially
other
things
that
need
to
get
evaluated
for
a
stable
release.
It's
not
the
complete
picture
yet,
but
it's
just
something
to
be
evaluated.
It's
the
anthony's
point
of
view
as
well
as,
like
you
know,
what
we
want
to
release
is
ideally
a
release
candidate
and
then
the
same
version
is
just
tagged,
as
you
know,
a
stable
version
once
that
is
evaluated,
I
honestly
don't
have
too
much
of
a
problem.
B
I
do
want
to
try
to
satisfy
our
users-
and
I,
like
you,
know,
having
the
collector,
take
a
dependency
on
this
and
they
need
things
out.
Right
now
is
a
good
forcing
function.
I
guess
I
guess
I
fall
into
that
camp.
I
don't
if
anthony's,
okay
with
the
1.1,
I'm
okay
with
that
aaron.
Are
you
willing
to
go
in
that
direction?.
E
C
See
what
the
consensus
is?
Let's
cap
it
at
make
a
decision
by
friday
and
do
a
release
on
monday.
B
Yeah
can
you
handle
the
whole,
though
I
don't
know
where
we
would
do
that
or
how
it
would
be
done.
But
if
you
have
a
plan
in
mind,
I'm
totally
good
we're
also
out
of
time.
So
I
don't
want
to
hold
up
anything
else
too
much
yeah
I'll
I'll
figure
out
some
way
to
make
that
work.
Okay,
awesome
all
right!
Thanks
everyone
for
joining,
look
forward
to
the
the
vote.
Your
info
is
needed,
but
yeah
we'll
see
you
all
next
week
and
or
virtually.