►
From YouTube: 2022-05-26 meeting
Description
Instrumentation: Messaging
B
My
bad,
although
tristan
I'm
sure,
also
pass
people
over.
B
Yeah,
I
totally
forgot
that
we
went
back
to
this
thing
where
we
only
have
like
a
certain
number
of
invites.
B
B
Right,
okay,
I
actually
didn't
see
how
many
other
people
were
on
the
meeting,
the
other
one,
but
there's
david.
So
I
think
I
think
we
could
probably
what's
up.
A
Or
maybe
they
get
to
learn
a
little
bit
about
what
was
that
meeting?
That's.
B
Erlang
yeah,
I
mean
that's,
not
a
problem.
I
was
talking
to
tristan
a
lot
about
because
they're
also
developing
their
metrics
sdk
right
now,
so
they're
going
through
the
specification
as
well
cool,
but
we
can
jump
in
here
so
just
to
start
us
off
six
minutes
past
after
that
kerfuffle.
B
So
if
you
haven't
already,
please
add
yourself
to
kennedy's
list.
If
you
have
anything,
you
want
to
talk
about.
Add
it
to
the
agenda
for
those
watching
the
recording
this
meeting
starting
late
due
to
a
zoom
issue.
The
new
meetings
in
the
future
should
have
the
right
zoom
length,
though
so
that
should
be
it
gone
forward,
but
to
start
aaron,
you
wanted
to
talk
a
little
bit
about
the
cool
off
time
of
go
so
I'll
hand
it
over
to
you.
A
A
B
I
don't
know
if
we
should
be
doing
this
based
on
time
per
se
as
much
as
release
cadence
and
the
reason
I'm
thinking
about
this
is
just
because,
like
the
go
backwards,
compatibility
guarantee,
you
know
for
like
the
v1
guaranteed
stability
essentially
says
like
we'll
always
be
backwards
compatible,
except
that,
like
new
versions
are
going
to
have
new
features
right,
and
so
I
think
that
we
could
probably,
I
think,
fall
into
that
same
category
whereas,
like
you
know,
a
new
version
of
goat
came
out
and
we
could
say
like
okay,
we'll
do
one
more
release
that
that
that
release
will.
B
We
will
guarantee
to
be.
You
know,
compatible
with
this,
but
then,
after
that,
like,
if
you
upgrade,
you
may
need
to
upgrade,
go
after
that
and
so
like.
If
you,
if
you
can't
upgrade
go
then
maybe
this
is
the
last
version
that
you
need
to
be
sticking
with,
or
we
don't
provide
any
guarantees
of
compatibility
going
forward
for
the
older
versions
of
go.
B
You
know
that
being
said
like
I
I
don't
know,
it
seems
reasonable
to
me
like
it
seems
like
if
you
have
a
user
or
even
like
a
vendor,
has
a
customer.
That's
like
you
know,
I
need
the
security
fix.
I
need
this
feature
edition
in
these
later
versions
of
hotel.
I
think
it's
reasonable
to
say
to
them.
Well,
that's
fine!
If
you're
doing
one
upgrade,
you
may
be
doing
have
to
do
an
upgraded
go
as
well
process.
A
I'm
okay
with
it
honestly,
I
feel
my
personally
me
personally,
I
would
say
we
could
just
drop
an
ad
at
the
same
time
as
go
does
but
there's
been
there
there.
There
have
been
watchful
reservations
around
that,
so
this
is
just
hoping
to
improve
the
process.
D
I'm
perfectly
fine
with
dropping
support
for
n
minus
three
and
minus
two
and
minus
two.
Once
we
have
a
final
release,
so
I
think,
like
tyler
said
right,
say:
118
comes
out,
we
do
one
more
release
that
has
116,
doesn't
use
any
117
or
118
features
and
then
after
we,
after
our
first
release
following
a
new
go
release,
we
move
our
minimum
supported
version.
B
A
I
will
try
and
capture
it
tyler
just
so
I
can.
A
So
anthony's
position
is:
have
one
just
one
release
with
all
three
and
what
was
your
position?
Tyler
yeah.
B
Okay,
so
yeah,
that's
the
thing
it's
like
you
know,
go
118
came
out
and
what
I
think
we
should
do
with
the
new
policy
is
then,
okay,
we
have
one
more
release
and
that
that
really
still
supports
116..
Technically,
it
also
supports
118.,
and
in
that
release
it
says
like
this
is
the
last
release
that
will
support
116
and
after
that's
done,
we
just
do
the
upgrade
for
go
after
that
and
so
yeah.
Then
we
stopped
supporting
116,
and
then
we
supported
a
minimum
117..
B
B
But
I
do
think
that
our
current
policy
of
like
kind
of
track
and
go
where
we
say,
like
you,
know
the
current
plus
the
last
are
the
two
that
are
supported,
I
think,
are
good
feature
wise
yeah.
D
Cool,
obviously,
we've
always
got
the
option
to
do.
You
know
patch
releases
for
older
versions.
If
we
find
a
critical
security
issue
or
something
like
that,
I
don't
know
that
we
have
an
explicit
policy
on
doing
those,
but
if
there
are
critical
security
issues
we
don't
necessarily
have
to
force
people
to
upgrade
go
in
order
to
get
that
fixed.
If
we
can
do
a
patch
release.
B
Cool
thanks
aaron
next
up
is
the
metrics
sdk
alpha
release
status,
so
we've
made
some
pretty
good
progress.
Obviously,
there's
still
some
more
things
to
be
added,
but
this
is
saying
we're
close
to
halfway
through
the
development.
B
I
think
that
that's
a
little
bit
optimistic,
but
I'd
say
we're
definitely
more
than
a
quarter
of
the
way.
I
will
definitely
say
that
so
yeah
just
a
good
overview.
Let's
see
what
is
currently
active,
though,
on
the
project
board.
I
know
that
aaron
is
actively
working
on
the
views
portion
of
the
code.
I've
been
looking
at
the
aggregation
structure
doing
a
lot
of
reading
of
the
specifications
as
well.
I
wanted
to
pick
this
up
next.
B
A
Yeah,
I
can
kind
of
show
you
the
back
of
the
envelope
stuff
that
I've
been
doing
just
to
kind
of
hopefully
stay
somewhat
in
sync
on
how
these
might
look.
B
Yeah
it'd
be
really
helpful.
We
could
go
over
that
today.
I
think
we
have
some
time,
but
if
you
could
just
post
something
in
here
as
to
like
you
know,
like
you're
saying
like
back
of
the
envelope
like
here's,
you
know
these
10
types
or
something
like
that.
Where
that
I've
got
in
their
structure,
I
think
would
be
really
helpful.
A
I
have
what
I'm
trying
to
keep
the
one
type
to
er,
I'm
trying
to
keep
a
pipeline
of
just
a
counter
just
to
see
what
a
counter
would
look
like
and
like
what
little
bits
need
to
to
be
built
to
build
a
counter.
Yes,.
B
Okay,
yeah
no
worries,
then
so
yeah,
if
you
could,
just
if
you
want
to
post
something
in
the
issue,
I
think
that'd
be
best
so
that
we
could
communicate
like
publicly
and
asynchronously
but
yeah,
especially
if
there's
only
one
thing.
I
think
that
that's
my
my
plan
and
currently
is
still
to
look
at
the
the
example
branch
of
that
we
were
already
using
and
kind
of
just
build
from
there,
so
yeah,
if
it's
similar
to
that
or
if
it's
the
same
as
that,
don't
worry
about
it.
A
Yeah,
I
think
we've
broken
some
of
the
ex
the
underlying
assumptions
of
that
branch.
D
A
Putting
the
view
as
something
that
is
a
public
like
if
we're
going
to
use
the
view
as
a
public
thing,
then
the
aggregators,
the
way
the
aggregators
have
been
optimized
in
this.
A
They
don't
necessarily
have
the
same
underlying
assumptions
that
we
might
have
going
forward
so.
B
A
B
Okay,
yeah.
A
B
Yeah,
no,
that's
fine
I'll
I'll
schedule
something
for
tomorrow.
I
don't
know,
I
guess
I'll
check
with.
B
Okay,
well,
if
that's
the
case,
then
I'll
check
with
aaron
aaron.
I
don't
know
if
you
have
any
free
time
tomorrow,.
B
So,
oh
right,
yeah
next
week
is
memorial
day.
Okay,
so
yeah
it'll
probably
be
next
week,
the
earliest
and
I'll
I'll
think
anthony
when
or
we
can
do
like
a
grouper
chat
or
something
to
find
a
time
see
what
works
cool.
B
C
A
And
by
the
way,
anybody
who
is
watching
this,
I
am
free
to-
I
actually
really
do
appreciate,
having
like
feedback
and
bouncing
ideas
off.
So
if
anybody
wants
to
schedule
some
open
office
like
talk
about
the
metrics
and
the
form
of
it,
I
am
I'm
open
to
that.
B
I
mean
yeah,
absolutely
I'd
love
to
do
the
communication
asynchronously,
but
sometimes
just
getting
out
of
call
is
also
super
helpful.
B
B
Awesome:
okay:
I've
got
something
done
for
that,
the
pr
that
aaron
just
opened
recently.
This
is
the
one
if
you're
looking
to
do
some
reviews
for
the
metrics
api
go.
Take
a
look
at
this.
I
haven't
fully
reviewed
this
yet
so
it
just
came
out
recently.
So
just
a
heads
up,
it
exists.
B
Yeah,
I
did
have
a
question
on
this.
Maybe
maybe
it's
fine
just
to
bring
it
up
here,
so
this
descriptor
isn't
an
internal
package
all
right
and
we
have
this
function
here.
That
accepts
and
returns
this
internal
package.
But
it's
a
public
function.
A
A
Does
it
need
to
be
internal?
I
don't
think
it
needs
to
be
internal
okay,
but
that
also
does
limit
our
api,
which
is
another
concern
that
we
have.
We
have
competing
with.
B
Yeah,
I
think,
that's
fair.
I
was
looking
at
the
original
example
pr
here
and
there's
like
this
sdk
instrument
thing.
It
does
have
a
descriptor
here.
I
was
kind
of
envisioning
this
to
continue
existing,
I'm
fine
with
moving
it
there.
Okay,
I
think
that
I
would
like
to
put
that
there
and
the
number
seemed
like
it
could
actually
get
merged
into
the
sdk
instrument,
because
literally
it's
just
a
a
number
number
type,
so
there's
even
run
on
so
it
might
be
better.
B
I
think
I,
like
the
word
instrument
that
you
already
have
in
your
package
name,
but
we're
getting
into
naming
at
this
point
so
also.
I
haven't
fully
reviewed
this
yet
so
please
take
what
I'm
saying
with
a
grain
of
salt.
A
Yeah
the
internal
instrument
descriptor,
is
some
is
how
you
can
uniquely
identify
more
of
an
output
position
less
of
the
internal
instrument
description,
because
technically
you
can
mer
like
through
views.
You
would
actually
aggregate
over
a
a
merge.
Essentially
so
does
that
mean
that
it
would
better
fit
in
this
export
type
file?
It
could
honestly
like
these
all
could
be.
A
They
all
could
coexist
in
the
same
thing
like
number
and
the
output
structure
and
the
just
the
instrument
descriptor,
like
they
all
kind
of
share
a
common
use
case
of
identifying
how
how
we
organize
our
outputs.
B
Or
just
a
non-uh
internal
instrument
or
something
like
that:
yeah
yeah,
okay,
cool!
That
sounds
good.
So
that's!
I
think
the
only
thing
on
the
open
side
of
the
metrics
process
had
some
good
movement
this
past
week
so
definitely
appreciate
all
the
reviews
that
are
already
actively
being
done
there.
So
it's
definitely
helping
the
project
move.
On
last
thing
I
wanted
to
talk
about.
B
Was
this
auto
prop
package
that
I
posed
a
little
while
ago,
it's
kind
of
sat
in
the
back
of
my
burner,
so
it's
gotten
some
more
reviews
in
the
recent
days.
So
I
just
kind
of
wanted
to
ask
a
little
question
here.
So
for
those
aren't
familiar
right
now,
our
propagation
support
is
that
you
need
to
configure
the
propagator
via
code
and
that's
it
like.
You
can't
use
the
hotel,
propagator
environment
variable
that
is
specified
by
the
specification.
B
It'd
be
ideal
if
you
could,
but
the
problem
then
becomes
like
how
do
you
support
this
environment
variable?
If
you
don't
import
everything,
and
then,
if
you
import
everything
you
have
all
these
dependencies.
So
maybe
not
everybody
wants
to
do
that.
So
we
talked
in
the
past-
and
this
is
one
of
the
proposals-
was
to
essentially
create
a
new
package
for
it,
and
this
is
what
this
is
doing.
B
It's
called
auto
prop
again
naming
if
you
have
better
names,
I'd
love
to
hear
them,
but
so
the
idea
here
is
that
there's
this
new
techno
propagator,
which
is,
is
equivalent
to
this.
Where
you're,
you
know,
this
big
long-winded
thing,
which
is
again
was
another
ask
from
the
community
that
this
big
long-winded
thing
be
shortened
down
in
some
way
or
somehow
some
sort
of
easy
way
to
set
this,
so
that
is
kind
of
achieving
that
as
well.
B
Instead
of
this
multi
parameter
functions,
call
it's
just
a
single
function,
call
which
defaults
to
a
trace
context
and
a
baggage,
but
it
also
works
like
a
composite
text
propagator.
So
if
you
do
pass
it
propagators,
it
will
compose
based
off
of
that,
and
the
other
cool
thing
is
that
it
supports
the
environment
variable.
B
So
if
you
just
pass
this
and
then
you
pass
an
environment
variable
as
an
override,
it
will
use
that
environment
variable
instead
and
that
environment
variable
currently
supports
all
of
the
environment
variables
that
the
specification
supports,
which
I
guess
they
could
pull
that
up.
Really
quick,
because
it's
been
asked
in
this
pr
as
well.
It's
a
pretty
limited
list,
which
it's
kind
of
pointed
out.
B
It
does
not
comprehensively
include
all
the
propagators
that
we
actually
include
in
the
repo
so
trace
context,
baggage,
b3,
b3,
multiple
jaeger,
x-ray,
ot
trace
and
then
explicitly
none
which
is
turning
things
off.
But
things
like
the
open
census.
Binary
is
not
currently
here,
which
it
probably
should
be.
That
should
probably
be
a
standardized
form
as
well.
So
just
a
heads
up
on
that
one.
So
then
the
question
becomes
like
how
do
you
extend
it
because
otherwise,
like
this
is
not
that
useful
outside
of
the
defaults?
B
And
so
there's
this
way
to
extend
it
by?
I
guess
it's
not
in
the
description
here
by
having
this
function
called
register
text
propagator,
so
you
can
register
your
own
and
the
name
will
then
be
what
the
environment
variable
value
is
supported
and
then
the
propagators
associated
propagator
the
way
this
is
written.
Currently
it
uses
an
environment
registry
which
stores
all
the
defaults
already,
but
it's
written
to
override.
B
So
any
I'm
trying
to
find
where
I
wrote
this
any
store
will
override
anything
that
already
exists,
which
includes
the
defaults
so
say
you
wanted
to
pass
like
you
know,
b3,
and
you
wanted
a
different
implementation
was
my
original
idea.
You
could
override
whatever
the
default
bp
propagator
was
or
trace.
Contacts
propagator
and
david
pointed
out
that
you
know
this.
B
Is
you
know
it
needs
to
be
a
little
bit
more
clearly
explained
which
it
was
and
then
anthony
said,
like
you
know,
maybe
this
isn't
the
best
behavior,
and
so
my
thought
on
this
was
that
like,
if
you
have
a
user
that
comes
by
and
they're
registering
a
different
propagator
they're
already
making
that
decision
right,
so
it
didn't
seem
like
there'd,
be
too
much
confusion.
B
However,
this
question
also
like
made
me
think
about
it
a
little
bit
harder
and
asked
like
well
what
happens
if
you
have
a
third-party
library
that
tries
to
come
in
and
say,
they're
a
malicious
actor
and
they,
you
know,
are
doing
some
sort
of
you
know
reset
of
the
trace
context,
propagator
so
that
when
somebody
uses
it,
they
I
don't
know,
do
something
malicious
with
that
data,
which
doesn't
sound
like
a
great
idea
to
me.
Now
that
I'm
saying
it
and
thinking
about
it.
B
So
I
was
thinking
that
maybe
this
is
a
you
know
a
good
reason
to
not
override
the
defaults
and
maybe
even
not
override
any
other
previously
set
values.
So
my
question
then,
is
to
the
community
like
does
this
seem
reasonable
and
then,
if
it
is
like
what
alternate
behavior,
do
you
think
we
should
be
supporting
here.
A
So
the
one
issue
you're
going
to
have
like
overwriting
defaults
might
not
be
too
difficult
because
you
can
have
those
set.
You
can
fill
in
the
struct
before
anything
is
set
up.
But
if
you
allow
like
in
init
the
registration
of
propagators,
the
you
don't
get
to
control
the
order
which
inits
are
executed.
B
B
D
You
end
up
in
the
race,
condition
right,
yeah
and,
I
think,
maybe
the
way
to
handle
that
is
then
to
panic.
If
you
attempt
to
re-register
a
value,
that's
already
there,
because
if
it's
happening
in
a
net,
this
should
be
caught
very
early
on.
Something
should
never
be
shipped.
That
would
do
this.
It
will
be
irrelevant
of
you
know:
runtime
conditions,
two,
two
libraries,
two
packages
try
to
register
the
same
name,
you
get
a
panic,
everything
just
stops
and
and
the
application
author
has
to
go
and
figure
out
what
the
heck
went
wrong.
A
Yeah
so,
like
I'm
saying
in
a
case
like
say,
somebody
has
a
very
useful
third
party,
one
of
I
don't
know,
I
don't
think
google
has
one
but,
like
google
comes
out
with
their
executor
and
it's
not
part
of
this
default
package
right,
it's
registered
in
their
package.
A
malicious
actor
could
also
try
and
register
the
google
name
and
we
don't
get
to
control
which
of
those
registrations.
Fires.
First.
B
Right
yeah
because
I
like
you
can't
over
like
there,
wouldn't
be
a
race
condition
for
baggage
but
say
like
yeah
like
open
census,
right,
like
that's
one
that
we're
already
talking
about
so
there's
a
wrapper
around
this
package
that
does
open
census.
But
then
you
have
a
third
party
that
comes
in
and
goes
like.
Actually,
I'm
gonna
steal
that
name
space
beforehand,
and
if
we
drop
this
silently,
the
user
has
no
concept.
That
actually
happens.
B
D
B
Yeah
I
error
was
the
other
thing
that
I
was
thinking
about
as
well.
I
think,
since
it's
like
there's
no
chaining
like
it
doesn't
currently
return
anything.
It
just
means
that
you
have
to
handle
the
error
right.
I
guess
is
the
only
question
which
or.
B
Yeah,
that's
the
other
thing
right,
like
you,
couldn't
just
be
calling
this
and
ignoring
the
error,
and
so
I
guess
that
kind
of
goes
back
to
the
question
is
like:
how
important
is
this
like
what
sort
of
malicious
activity
could
we
anticipate
here?
Like
you
know,
I
I
was
thinking
like
you
know
you
get
access
to
like
request
headers,
which
can
contain
sensitive
information,
so
it
seemed
pretty
important
to
me,
but
you
know,
I'm
just
kind
of
wondering
is
that
is
that
a
shared
understanding.
D
Yeah,
I
think
this
is
something
we
don't
want
to
surprise
users
with,
as
you
say,
it
does
get
access
to
potentially
sensitive
information,
and
it
does
get
all
of
the
request.
Headers.
It's
not
like
the
the
propagation
extract
says.
Oh,
what
are
your
fields?
Let
me
go,
get
those
and
put
them
into
another
object
that
I'm
going
to
give
you.
So
you
just
see
those
right,
but
even
even
if
it
did
a
malicious
propagator
could
simply
say
here
are
my
fields
I
need
x,
authors
or
authorization,
add
x,
user
id
and
whatever
right.
B
Yeah,
okay,
I
mean
in
that
case
it
kind
of
says
that
panicking
is
the
right
approach
then,
rather
than
returning
an
error
because
of
you
know
the
laziness
of
the
user.
If
I'm
hearing
that
correctly.
D
I
think
it's
the
safest
approach,
it
may
cause
user
consternation
if
they
end
up
with
conflicting
packages
and
need
to
figure
out
what
to
do
with
it,
because
I
don't
know
if
there's
good
options
when
that
happens
other
than
to
stop
using
one
or
the
other
or
to
go,
find
the
the
authors
of
them
and
yell
at
them
and
get
them
to
fix
it.
D
B
Yeah,
okay,
that's
also
a
good
point.
It
may
just
mean
that
we
need
to
be
more
explicit
in
our
documentation
of
this
function.
Saying
like,
if
you
use
this,
you
have
to
understand
like
the
return
error
is
important.
It
could
cause
a
security
vulnerability
if
we
want
to
return
the
error,
yeah
docs.
No
one
ever
reads
them:
okay,.
B
Okay,
I'll
think
about
it
for
a
little
bit.
I
appreciate
the
conversation,
though,
that's
that's
helpful
and
with
that
we're
through
the
agenda,
I
will.
D
Say
that
this
this
is,
this
is
definitely
a
valuable
functionality.
One
of
the
things
I
heard
from
users
at
kubecon
was
hey.
It's
really
frustrating
that
go
doesn't
have
default
propagation.
You
really
wish
it
did.
I
think
at
least
one
of
them
heard
me
when
I
said
you
know
this
is
a
spec
thing
and
was
going
to
go
and
to
get
the
spec
change,
but
I
don't
expect
that's
going
to
happen
either,
because
I
think
that
would
be
a
breaking
change
as
well.
So.
B
Yeah,
that's
actually
a
really
good
point,
though
anthony,
because
I
was
also
looking
at
this
as
another
approach
for
our
exploratory
problem.
You
know.
Currently
we
don't
support
the
ocell
exporter
environment
variable
either.
So
you
know
if
this
is
useful
and
people
are
actually
using
it.
We
could
probably
look
into
doing
something
similar
for
the
exporter.
B
Yeah,
I'm
trying
to
think
I
I
think
I
remember
looking
at
yours.
I
think
I
remember
the
same
thing
for
the
the
propagate
or
the
exporters
as
well.
A
Yeah
yeah,
I
did
so
here's
how
I
support
it.
It
just
it
is
very,
very
rough
proof
of
concept
type
code,
but
that's
that's
how
I
thought
of
doing
supporting
the
exporters,
exporters,
registration
and
whatnot.
B
So
yeah
well
cool,
that's
kind
of
a
good
segue
into
uses
oppo
telemetry
yeah.
So
on
that
note,
there's
not
too
many
people
on
the
call,
but
if
anybody
has
any
updates
of
use
cases
of
open
telemetry
in
the
past.
B
Yeah,
I
don't
think
so.
Okay,
so
one
of
the
other
things
I
forgot
I
was
gonna
mention.
Is
I've
been
looking
into
the
aggregators,
but
I've
also
been
looking
into
that
ticket.
We
have
to
publish
deprecation
packages
and
looking
at
a
solution
there,
I
was
hoping
to
post
something
in
that
issue
recent
or
in
the
next
day
or
two
with
a
essentially
like
a
test
case.
B
Because
doing
this
is
a
little
scary,
because
it
involves
this
thing,
essentially
a
single
actor
doing
some
pushes
to
upstream
with
tags,
and
so
I
wanted
to
make
sure
that
it's
really
documented
before
anything's
actually
done,
and
I'm
contemplating
also
like
building
out
a
separate
repo
entirely
to
try
to
test
this.
But
yeah.
I'm
working
on
a
comment
to
this
issue
that
I
just
posted
in
the
agenda
if
you're
interested
just
follow
along
in
the
next
day
or
two,
and
I
should
have
something
there
but
yeah,
just
a
heads
up.
A
I've
I've
done
a
little
bit
of
experimenting
with
it.
If
you
want
to
see,
do.
A
A
B
Oh
yeah,
I'd
love
it.
If
you
could
post
a
link
in
the
issue,
maybe.
A
B
Eight
but
yeah,
I
I
think,
if
that's
ideal,
I
I'm
looking
through
the
deprecation
and
retraction
thing.
I
think
we
need
to
do
both,
but
I
wanna
motivate
that.
So
I'm
still
thinking
through
that.
That's
why
the
comments
is
hanging
so
yeah.
A
Just
the
heads
up
the
so
going
through
this
deprecating
a
function
or
a
struct
is
a
little
bit
more
powerful
than
deprecating
a
package,
but
deprecation
is
mostly
is
a
docs
and
lint
item.
It
doesn't
prevent
things
from
automatically
trying
to
choose
that
package.
B
I
think
that
actually
has
changed
117
trying
to
this
is
one
of
the
things
that
I've
been
was
kind
of.
A
B
Up
through
yeah
and
go
117
like
go
list
mu,
which
is
also
the
thing
that
checks
for
the
latest
package
and
any
upgrades
we'll
we'll
look
into
this
deprecation
of
modules.
So
I
again,
this
is
one
of
the
things
like
I'm
still
validating.
I
definitely
know
we'll
say
something,
but
whether
like
how
that
gets
chosen,
I
think,
is
something
we
want
to
keep
in
mind.
There's
also
nothing
in
here.
B
That
says,
like
you,
can't
combine
a
deprecation
with
a
retraction,
so
I
think,
if
that's
fair,
it
just
needs
to
motivate
the
retraction,
because
you
know
it.
I
think
retraction
is
really
key.
The
fact
that
it
doesn't
remove
the
old
package,
it's
still
maintained
in
proxies
and
it's
still
in
source
code,
so
you
can
still
build
like
it
can
still
successfully
build.
But
the
thing
is:
is
that
essentially
like?
B
If
new
people
come
along
looking
for
something
to
satisfy
a
dependency,
it
will
not
use
that
and
I
think
that's
kind
of
like
the
big
thing
right
now
that
we're
having
a
problem
with
is
like
if
you
came
along
and
you
looked
at
package.go
and
you
looked
at
like
say,
an
old
version
of
something
that
doesn't
exist
anymore.
That
would
still
be
there
right,
but
if
you
could
find
the
latest
version
and
that
latest
version
has
a
deprecation
notice
on
it,
I
think
that
that
would
solve
both
of
our
our
problems.
B
A
B
Like
I
said,
I'm
still
very
early
stages,
looking
at
this,
as
kind
of
like
a
side
thing
so
yeah.
B
Cool
yeah,
I
think
that
it'd
be
useful
users,
I
think,
are
having
a
lot
of
problems
there.
We
do
have
a
little
bit
of
time
anthony.
I
don't
know
if
you
have
more
insights
from
kubecon,
you
know
looking
at
user
behavior
I'd
love
to
know.
If
you
talk
to
I'm
guessing,
you
probably
write
the
booth
any
any
updates
from
that.
D
D
We
pulled
in
chairs
from
other
rooms
and
almost
certainly
a
fire
hazard,
but
we
survived
and
users
had
a
lot
of
good
things
to
say,
and
there
were
some
go
users
there
who
had
good
things
to
say
so,
congratulations
to
all
of
us
for
building
something
that
people
generally
seem
to
like
to
use
and
are
having
success
with.
There
were
a
lot
of
questions
from
people
who
were
just
getting
started
as
well.
That
was
more.
D
What
I
saw
at
the
booth
was
people
who
were
you
know
interested
in
open,
telemetry,
just
getting
started
with
it.
Where
do
they
get
going?
Obviously,
documentation
getting
started
guides
were
a
challenge
that
a
lot
of
people
expressed,
I
think
that's
across
languages.
D
I
think
I
mentioned
the
you
know
one
person
who
had
mentioned
the
the
propagators
being
a
challenge
to
them
and
wanted
us
to
fix
that,
but
I
think
we're
making
progress
there
so
yeah.
I
think
overall
kubecon
was
a
really
good
affirmation
that
we're
on
the
right
path,
we're
doing
the
right
thing
and
people
are
starting
to
use
the
project,
and
you
know
not
not
just
a
few
people
but
a
lot
of
people.
D
B
I
do
I
want
to
point
out
one
more
thing:
we
have
surpassed
the
specification
in
the
number
of
stars
at
the
repo
you.
B
B
Cool,
I
think,
with
that
we
are
at
the
end
of
the
agenda.
We
could
probably
end
it
here
so
same
time
same
place
next
week
at
this
new
zoom
link,
and
hopefully
the
people
in
europe
are,
they
should
be
back.
I
think
because
most
of
them
are
on
vacation
there's
a
reason,
so
hopefully
we'll
see
some
new
faces
next
week,
but
until
then
thanks
everyone
talk
to
you.