►
From YouTube: 2022-10-20 meeting
Description
Instrumentation: Messaging
B
B
Is
you
come
next
week.
A
A
Are
we
going
to
have
the
time
at
the
same?
The
meeting
at
the
same
time.
B
I
mean
I,
don't
know
I'm
kind
of
looking
at
the
agenda
so
far,
I
think
we
might
have
quorum
to
actually
discuss
some
of
these
topics.
So
I'm.
A
B
I
think
that
would
I
already
know
the
answer,
but
I
just
wanna
I'd
like
if
more
of
the
community
we
could
also
post
inside
if
no
one
shows
up
so
yeah
I
guess
starting
off.
We've
got
the
Viper
V1
113
issue
here
Aaron.
You
want
to
talk
about
this.
A
Yeah
sure
I
did
a
little
bit
of
a
deep
dive
on
this
apparently
Viper
in
version.
113
changed
how
it
handles
nested
configs
long
story
short
is
because
golang
CI
uses
Viper,
but
some
of
the
components
don't
it
broke.
Some
of
their
configs,
specifically
the
one
we
use
is
context.
As
argument
I
found
two
potential
options.
Is
we
either
replace
two
Viper
1.12
until
something
happens,
Upstream
to
to
allow
us
to
fix
it,
or
we
disable
that
linter
until
something
allows
it
to
have
to
work.
B
Yeah
so
I
I
was
looking
at
this
as
well.
I
I
mean
my
first
thought
is
to
just
go
with
the
replace
statement
here,
but
I
do
I
do
want
to
make
sure
that
this
is
actually
being
tracked.
Upstream
like
is
there
an
actual
open
issue
for
it,
because.
A
That's
that's
where
the
the
fix
would
have
to
be.
Viper
is
not
going
to
budge
like
as
of
right.
Now.
Viper
is
not
going
to
change
how
they
do
this
I
could
see,
potentially
them
changing
how
they
they
they
like
diving
into
kind
of
the
golang
CI
I
could
see
how
they
could
change
the
the
couple
of
projects
that
use
this
to
a
different
way
of
specifying
their
arguments.
A
A
B
I
was
gonna
put
this
as
a
reference
here,
I,
that's
troubling,
that's
that's
the
thing
I
wanted
to
find
out,
because
that's
the
reason
I
probably
would
just
go
with
disabling
this
winter
yeah,
because
I
I
mean,
if
there's
no
expected
change
from
Viper
upstream,
and
we
just
do
this
for
place
like
it's
just
a
time
bomb
before
they.
You
know
so
there's
some
sort
of
dependency
on
a
version
feature
that
is
released
after
this
and
then
we
are
going
to
break
based
on
that
yeah
agreed
yeah.
B
So
my
take
and
I'd
like
to
hear
other
people's
take
is
to
go
with
number
two
then,
and
just
delete
that
winter.
It's
not
like
the
most
critical
winter
ever.
A
B
Yeah
yeah
and
the
issue
that
we
have
is
that
in
the
testing
packages,
sometimes
you
want
to
pass
the
testing
object
first,
instead
of
a
context,
because
that
makes
sense-
and
so
we
have
this
like
override
for
that
testing
package.
But
like
I
I,
don't
know
yes,
that's
that's
the
that's
the
winter.
C
I'm
just
trying
to
think
about
what
the
the
consequences
of
disabling
it
would
be
and
I
think
that
just
means
we
need
to
be
more
Vigilant
in
PRS
to
ensure
that
we're
following
that
convention.
B
Yeah
this
this
issue's
still
open
is
there
any
chance
that
going
to
see
island
is
going
to
address
this.
A
The
way
I
could
see
them
potentially
addressing
it
is
change.
What
is
a
map
in
the
config
to
a
slice
of
strings.
B
A
Or
a
block
of
strings
either
way,
but
that
would
mean
we'd
have
to
have
a
config
change
and
I.
Don't
I
don't
know
if
they
have
the
appetite
for
that.
A
And
there's
also
potential
affix
from
revive,
which
is
the
linter.
That's
underneath.
That's
that
provides
this
to
not
be
the
way
they
they
read
it
to
not
read
it
as
a
an
intact
screwing
but
normalize
it
in
some
way.
A
This
is
revives
config
gulling,
CI
kind
of
converts
their
config
into
arguments
past
to
revive
right.
So
there's
there's
a
couple
levels
of
of
config
that
could
happen.
Remember.
B
This
now
and
okay.
A
B
C
A
A
different
yeah,
it's
a
different
winter
like
it's
possible,
but
I,
don't
think
golang
CI
automatically
switches.
It
I
think
it
does
some
kind
of
yaml
validation.
We
could
try.
It
I
have
no
problem
with
that,
but
from
the
looks
of
it
I
there
is
some
kind
of
validation
that
would
prevent
us,
because
there's
not
just
this
one
there's
another
Revival
inter
that
has
the
same
problem.
A
B
C
B
I
think
that's
fine,
having
like
an
issue
tracking
it
or
something.
That's
I,
guess
not
an
active
reminder
as
much
as
it
is
a
passive
yeah.
B
A
I'm,
fine
I'm
fine
with
any
of
the
above
Solutions
I,
just
wanted
to
bring
it
up
and
make
sure
we
have
some
kind
of
consensus
going
forward
with
it.
B
B
All
right
next
up
on
the
agenda
is
release
management
proposal,
so
I
was
I'm
looking
at
the
trails
meeting
last
week
and
then
looking
at
a
bunch
of
issues
this
week,
I
was
kind
of
just
wondering
like
if
there's
a
better
way
to
structure
how
we're
doing
sort
of
tracking
the
progress
of
the
project
So.
Currently
the
project
is
tracked
in
both
a
milestone
and
in
a
project
board
and
by
that
I
mean
like
the
the
beta
milestone
for
the
metrics
SDK,
just
in
case
I
want
to
double
check.
B
So
we
have
this
like
miles
down
here,
but
we
also
are
tracking
the
metric
releases
as
well.
Some
kind
of
wondering
is
just
drop
the
metric
SDK
Milestone
because
it
seems
more
duplicate
duplicative
than
it
is
actually
helpful
track.
The
beta
Milestone
as
a
project
which
is
already
created
and
have
the
milestone
for
each
release
that
is
actually
progressing
towards
that
beta
SDK
status
was
what
I
was
thinking
of.
Doing
I
was
wondering
if
that
makes
sense,
with
people.
C
I
think
that
makes
sense
to
me.
The
beta
Milestone
currently
is
serving
just
as
the
same
thing
as
the
project
right
it's
a
bucket
where
we
dump
issues
that
need
to
be
done
before
we
say
it's
beta.
B
A
I'll
say
I've
actually
preferred
this.
The
last
like
three
weeks
that
we've
been
doing
it
so
I'm
happy
to
move
to
that.
Okay.
B
I
will
I'll
switch
it
afterwards.
I'll
just
I'll
delete
that
Milestone
and
have
the
project
tracking.
All
the
things
in
the
next
thing
related
to
the
message
just
Decay
is
currently
in
the
project
tracking.
This
I
think
there
are
things
this
is
going
to
be
I,
think
more
relevant
for
tomorrow
during
our
Trio
session,
but
there
are
things
here
that
I
I
think
can
be
done
after
our
stable
release
for
the
metrics
SDK
I
think
that
there
are
probably
things
that
kind
of
stand
out.
B
One
of
or
a
few
of
them
are
I
think
up
for
discussion
later,
namely
the
exemplars
and
the
exposure.
Histograms
are
still
not
stable
in
the
specifications,
so
those
two
stand
out
as
things
that
might
I
think.
Maybe
we'll
talk
about
that
in
a
little
bit
be
up
for
things
we
could
pull
out
of
this,
so
I
was
also
proposing.
Maybe
we
want
to
have
like
the
catch-all
project
for
the
next
phase
of
this,
where
it's
essentially
like
the
host
ga
metric
SDK
project
board.
B
We
would
want
to
create
to
track
things
that
we're
going
to
do
after
the
ga,
or
maybe
we
want
to
do
the
same
thing
and
fill
the
Milestone
to
hold
them
as
just
a
generic
bucket.
There
are
opinions
there.
A
B
Well
after
GA
is
what
I
was
thinking
because
I
mean
the
next
release
is
beta
and
then
it's
a
maturing
process.
I
guess
I
I
would
see
beta.
As
you
know,
the
next
phase
after
that,
according
to
what
we
did
in
the
tracing
world,
is
RCS,
and
so
I
would
look
at
that
as
a
phase
of
bug,
fixes
and
having
some
sort
of
confidence
in
the
API
itself,
not
changing,
but
I
use
API
in
the
term
of
code
there,
but
yeah
the.
A
Code
API,
the
one
thing
that
I
want
to
bring
up
is
both
of
those
issues
that
you
you
like
I
I'm
behind
the
idea
generally.
But
the
the
two
issues
that
you
specifically
bring
up
could
potent
have
potential
impacts
on
the
metric
data
package
as
kind
of
the
bridge
between
where
so.
A
B
Well
sure
we
can
talk
about
that.
So
I
think
that
these
issues
that
are
being
tracked
here
so
adding
support,
for
example,
is
like
maybe
before
they're
triaged
and
moved
to
a
particular
post,
stable
release,
smile
or
post-able
release
projects.
We
could
put
some
thought
into
how
they
would
actually
be
implemented
and
determine
if
they
could
be
implemented
in
a
backwards
compatible
way.
I
I,
you
know,
adding
fields
to
a
structure
is
backwards,
compatible,
adding
new
structures
to
a
package
is
backwards
compatible.
B
So
if,
in
the
metric
data
we're
going
to
be
extending,
you
know
the
scope
metric
type
to
include
I,
actually
don't
know
where
they're
going
to
be
included,
but
if
we're
going
to
be
extending
it
like
I,
that's
all
backwards
compatible
to
me,
and
so
it
doesn't
seem
like
it
should
be
blocking
our
release.
It's
going
to
be
extending
an
interface
like
then
yeah.
We
need
to
be
thinking
about
that
now
and
maybe
having
a
placeholder
but
I
yeah.
B
C
B
It's
just
not
and
then
exponential
bucket
histograms
is
experimental.
So
this
one
I
don't
know
like
I.
It's
still
just
a
data
type.
So
to
me,
I,
don't
know
why
it
would
include
interface.
Extensions
but
I
mean
I,
see
this
as
just
a
new
type.
That's
going
to
be
added
to
our
metric
data
package
and
to
our
aggregators
package,
probably.
C
Right
I
would
say
this
is
a
new
implementation
of
the
aggregator
interface,
but
not
necessarily
changing
it.
The
the
the
exemplars
is
actually
where
it
might
be
more
worried
about
API
change.
I
know
it's
is
it
feature
freeze,
but
does
it
require
new
API
service
that
isn't
in
the
stable
API
that
we
have
implemented.
A
Go
ahead,
it
would
either
require
public
fields
to
be
added
for
the
Exemplar
Reservoir,
or
we
would
have
to
extend
it
with
a
some
kind
of.
A
A
I'm
not
sure
if
I
I
would
assume
that
it
would
have
some
kind
of
space
somewhere
in
the
metric
data
set.
I'm,
not
sure
if
it's
a
scope,
metric
or
an
actual
metric
I
haven't
looked
at
it
for
a
long
time,
yeah
or
even
if
it
is
just
like
an
an
extra
inner.
An
extra
function
on
that.
The
aggregation
interface.
B
A
So
we
would
either
need
a
public
field
and
adding
a
public
field
to
a
public
type
yeah
that's
backwards
compatible.
That
is
not
backwards
compatible.
Why
not,
if
you've
defined,
if
you
have
what
you
would
call
it
if
you've
instantiated
it
without
the
names
that
would
be
backward
backwards,
incompatible,
yeah.
C
C
I
I
think
that's
the
the
one
the
one
place
where
I
would
feel
just
fine
breaking
backwards
compatibility.
Please,
please,
please
don't
use
short
struct,
initializers
yeah
right.
B
A
Where,
where
does
the
Exemplar
sorry
survive
in
the
in
the
Proto?
Is
that
a
number.
C
B
Yeah,
so
one
thing
that
is
standing
out
is
that
there
are
slices
here.
So
are
these
comparable?
This
is
not
comparable.
This
this
might
be
comparable
yeah.
This
is
so
that's
that's
something
is
this
data
type
would
change
from
being
comparable
to
not
comparable
if
we
added
Exemplar
a
slice
of
exemplars
in
here,
so
we
would
want,
to
maybe
add
a
non-comparable
field
to
this
type
prior
to
releasing
to
ensure
that
nobody
actually
is
using
this
as
a
comparable.
A
Yeah
I'm
I'm
fine
with
that.
Okay.
A
But
we're
getting
kind
of
Deep
In
The
Weeds
on
this
particular
issue,
I
think
generally,
the
the
what
we
would
want
to
do
before
we
we
kick
this
off
into
post
GA
is
make
sure
that
there
is
some
plan
in
place.
To
add
these
add
these
capabilities
in
a
backwards
compatible
way.
C
Yeah-
and
there
are
other
languages
that
are
already
at
GA-
that
don't
have
exemplars,
so
they
expect
they
have
a
way
to
do
it.
I
think
we
just
need
to
ensure
that
we
see
a
path
for
our
implementation,
which
may
be
things
like
making
sure
that
the
data
type
is
not
comparable.
So
people-
don't
accidentally,
do
it
when,
when
that
will
change,
yeah.
A
B
I
I,
don't
know,
I
think
the
discussion's
done
honestly
in
that
one,
like
I
I,
think
we
just
went
through
it.
Those
are
the
two
places
that
I
would
see
being
added
and
I.
Think
we
just
touched
on
everything
that
I
would
see
is
breaking
so
yeah
I
mean.
Maybe
we
want
to
go
through
it
a
little
bit
more
in
the
trio
session,
but
yeah
I
think
that
was
pretty
good
for
the
other
exponential
histogram
one
that
one
I'm
a
lot
less
certain
about,
given
its
experimental
status.
A
The
other
question
I
have
with
that
is:
how
do
we
add
that,
to
our
data
type,
our
metric
data
type,
in
a
way
that
I.
B
B
A
And
then
also,
how
do
stable
exporters
rely
on
the
non-stability
like.
B
Yeah
yeah
I
mean
because
otherwise,
then
you
just
have
like
a
one
and
that's
it
right,
like
you
can
only
essentially
well
I,
don't
know
I
guess
you
could
try
to
build
this
in
a
branch
and
then
test
it
in
a
branch.
But
how
do
you
get
adoption
of
people
using
it
in
a
branch
to
validate
that?
It's
ready
to
be
stabilized
because
I
mean
the
way
I
see
it
is
like
you
would
add
a
different
type
here.
You'd,
add
an
exponential
histogram
data
point
type
or
something
like
that
right,
but
then
like.
B
C
We
added
them
as
1.13
rc1,
rc2
rc3
get
those
releases
out,
get
people
using
them
and
then
1.13
is
where
we
solidify
the
API.
A
That's
that
is
assuming
that
what
you
call
the
the
spec
Upstream
doesn't
change,
which
I
doubt
it
is,
but.
B
But
I
think
that's.
The
Anthony's
point
is
like
you
know:
112
we
released
without
it
and
then
this
spec
stabilizes
Upstream.
So
now
we're
like
cool.
Let's
go,
add
that
to
our
distro
and
then
and
then
we're
like
okay,
but
we
want
to
make
sure
that
our
implementation
works
and
is
accurate
with
the
specs,
so
yeah
I
think
Anthony.
You
have
a
great
point.
There
is
like
so
113
would
be.
You
know
a
release
candidate
phase
to
ensure
that
it's
correct.
B
C
That
make
sense
here
yeah.
It
might
mean
that
we,
we
have
a
prolonged
gap
between
those
two
minor
versions
and
we
might
need
to
do
more
patch
versions
if
things
come
up,
but
I
think
that's
a
thing
that
we
can
plan
for
agreed.
B
Okay
impressed
because
I'm
pretty
sure
job
already
has
a
both
of
these,
so
yeah
they're,
pretty
bold.
So
let's
just
say
that.
C
A
They
also
don't
have
the
same
kind
of
automatic
upgrade
problems
or
problems
related
to
the
automatic
upgrade
of
fully
Backward
Compatible
with
go.
B
Yeah
I
know,
and
then
you
have
all
these
build
tools
to
try
to
fix
that
problem.
Okay,
so
with
that
said,
I
think
we
could
probably
create
this
project
to
track
posts.
You
know
naming
is
hard,
we'll
figure
that
out,
but
I
think
at
the
maybe
I
might
not
get
this
done
this
afternoon,
but,
like
we'll
plan
on
doing
this
at
the
tree,
I
was
reading
both
of
these
items
on
the
agenda.
So
that's
not
good
Aaron
and
anyone
else
or
Anthony
wants
to
try.
B
Okay
cool
moving
on
to
the
next
on
the
agenda.
Is
the
metrics
API
stable
enough
to
have
a
V1
release?
B
B
A
Okay,
so
I
have
no
problem
splitting
it
up.
I
know
when
we
first
released
the
API
there
was
calls
to
to
reform
it.
I
don't
know
if
we
want
to
rehash
that
again,
because.
C
A
It
is
different
from
the
rest
of
the
open
Telemetry
project,
but
we
would
then
have
to
have
a
definitive
answer
for
any
of
those
calls.
I'm
I'm
sure
we
can
go
dig
up
some
old
issues,
but
I
I
think
having
at
least
some
kind
of
decision
on
that
topic
would
be
appropriate.
C
A
I'm
I,
don't
know,
I,
don't
know,
I,
don't
think
we
need
to
rehash
them,
but
I'm
perfectly
okay,
saying
that
we
need
to
that.
These
are
acceptable
and
yeah.
They
differ
it's
okay,
but
we
need
to
put
that
in
more
definitive
writing
than
I
think
we
last
left
it.
B
Yeah
I
mean
that
was
kind
of
my
take
as
well
is
like
I
mean
if
we
want
to
rehash
it,
that's
I,
don't
know,
that's
I,
don't
have
the
energy
for
it,
but
if
somebody
wants
to
rehash
it,
they're
welcome
to
I
I.
Think
that's
a
lot
of
work,
because
it
will
also
involve
our
any
changes
to
the
API
to
this
SDK
and
and
to
Anthony's
point.
It's
been
out
there
for
six
months
and
people
have
been
using
it
and
we're
instrumenting
things
with
it.
B
So,
like
I,
don't
know
it
seems
adopted
I,
don't
think,
there's
anything
that
is
implicitly
contrary
to
the
specification,
but
I
think
that
that's
something
that
we
would
also
need
to
verify
is
that
we
are
conforming
in
the
same
way
that
we
did
the
first
time
with
the
trace,
SD
or
the
trace
API.
And
then
the
last
thing
that
I
see
is
like.
We
need
to
document
the
interfaces
with
our
versioning
policy,
but
other
than
that,
like.
C
Forward
that
we
need
to
reassess
our
versioning
policy,
there
is
that
issue.
That's
that's
been
raised
regarding
adding
methods
to
interfaces
being
breaking
changes
and
I
know.
We've
we've
said
we're
okay
with
that,
but
the
the
topic
has
come
up
again
and
maybe
we
should
rediscus
since
I.
Don't
think.
B
B
B
Right
but
that's
the
thing
like
it
doesn't
say
they
won't
and
I.
Remember
the
conversation
being
explicitly
that
we
like
it.
It
did
say
that
originally
and
it
was
taken
out
of
the
versioning
policy,
because
Bogdan
and
others
were
saying,
that's
something
that
they
don't
want
to
be
held
to
in
the
specification.
Like
that's
the
thing
like
there's
nothing
in
here
that
says
that
they
will
not
be
adding
API
API
calls
or
methods
to
interfaces.
B
B
A
So
I
think
the
the
issue
here
with
the
the
issue
that
Anthony
has
brought
up.
The
actual
GitHub
issue
is
we're
kind
of
at
a
standstill.
We
have
two
different
interpretations
of
what
we
think
we
need.
We
are
a
lot
or
what
we
think
Upstream
is
allowed
to
do.
B
I
mean
yeah
if
you
would
like
to
do
that.
I
I
was
involved
in
this
discussion
here
in
2021
and
it
is
extensive
if
I
remember
correctly,
and
it
definitely
talks
about
this
in
this
issue-
that
it
was
added
and
I
know
that
it
was
specifically
removed.
So
I
mean
like
if
you
would
like
it
explicitly
called
out
I
think
that's
fair,
but
I
I
mean
I.
It
seems
pretty
clear
in
the
specifications
thing
that
that
was
something
that
they
were
adamant
about.
The
fact.
C
B
Yeah
I,
I,
I,
I
I
feel
the
same
way
and
that's.
This
is
I
think
where
a
lot
of
my
like
apathy
to
try
to
fix
this
is
like
I
mean
I
to
Anthony's
point
nothing's
been
added
since
this
versioning
policy.
You
know
that's
over
a
year,
oh
God
I
think
this
took
over
six
months
to
merge
or
something
like
that,
like
it
was
no
two
months
to
merge
and
so
like
it.
It
was
not
like
the
easiest
thing
to
get
disagreed
upon
upon
the
specification
and
I
know.
B
This
was
one
of
the
most
contentious
points
and
I
know
that,
like
people
were
willing
to
go
to
the
mats
on
this
and
I
like
yeah
I'm
happy.
If
somebody
is
willing
to
go
to
the
mat
again
to
try
to
have
a
specification,
not
add
anything,
they
haven't
done
it.
Since
you
know
this
was
introduced,
but
until
that's
done,
like
I,
really
don't
feel
comfortable
in
our
project,
saying
that
we
can't
add
to
the
interfaces.
For
that
exact
reason.
B
Sure
I
don't
know
where
we
want
to
call
that
out.
Were
you
talking
about
I.
A
I,
don't
know,
do
we,
we
don't
have
any
kind
of
statement
on
our
stability.
Do
we
I
mean
we.
C
A
Then,
like
have
some
text
to
to
say
this
is
our
reasoning.
Why
and
then
we
can
point
to
not
having
these
conversations
again
and
again
and
again
right
like
unless
something
changes,
Upstream
we're
like.
B
At
a
sentence
here
that
this
is
a
requirement
that
comes
from
the
specification
being
allowed
to
add
it
yeah,
okay,
yeah
sure.
A
Just
I
know
this
is
kind
of
a
contentious
topic
and
we've
we've
hashed
it
a
lot
over
and
over
again.
Maybe
we
just
add
enough
until
we
we
have
enough
big
warning
signs.
That
says
this
is
going
to
happen
until
like
this
is
The
Stance
and
it
stays
that
way
until
we
have
other
input
right.
B
And
I,
it's
not
other
input.
It's
it's
changes.
Upstream
yeah,
like
yeah
like
we
have
I,
will
say
that
I
am
not
comfortable.
Changing
our
versioning
policy
until
our
streams
change,
like
that's
just
something
I'm
not
comfortable
doing
I,
also
will
say
that
I
am
not
comfortable.
Changing
our
apis
like
I
I.
B
Do
not
think
that
we
should
be
doing
it
willy-nilly,
and
we
should
try
to
look
at
ways
that
don't
break
the
ghost
ability
guarantees
as
best
we
can,
but
if
we're
painted
into
a
corner
because
yeah
upstream's
allowed
to
do
something
and
we
have
to
follow
what
that
is
to
be
compliant
with
the
specification,
I
I
need
to
be
able
to
ensure
that
we
have
the
we've
already
and
there's
the
thing
like
we
communicated
this
before
our
first
stable
release
like
this
is
something
that
we
say
specific.
B
We
specifically
added
to
communicate
to
users
This
and
like
if
users
are
coming
back
and
saying
like
we
need
to
remove
that
comment
like
this
is
the
policy
we
adopted
for
this
exact
reason
like
I
I.
That's
if
they
need
clarification,
I
mean
I
in
that
issue.
You're
talking
about
I
did
clarify
like
this
is
that's
where
that
comes
from
it's
from
Upstream,
like
Upstream,
is
willing
to
add
to
the
API.
A
B
C
B
B
B
Yeah
I
don't
see
it
and
then
I
could
try
to
find
it,
but
I
definitely
think
that
was
also
something
that
was
contentious
as
well.
Was
this
lock
step
of
mutual
version?
I
I'll
try
to
find.
B
C
B
Yeah
yeah,
that's
I
mean
I
I,
hear
you,
but
I
also
think
that
there's
parts
of
this
that
I
have
to
review
again.
That
say
that
the
implementation
language
implementations
needs
to
match
the
major
version
of
the
specification
that
they're
implementing.
C
It
just
says:
version
numbers
the
just
above
that
major
version
pump
language
under
version
numbers.
The
last
bullet
point
there:
okay
yeah,
so
it
the
examples
it
gives
are
all
within
1X.
But
the
text
says
you
can
have
version
numbers
that
are
independent.
B
B
Yeah
I,
don't
know,
I,
don't
see
anything
specifically
here.
I
could
take
a
look,
though,
because
I
do
remember
this
being
something
that
was
a
part
of
this,
but
I
I
don't
see
it
here
right
now,
Anthony.
C
B
C
B
C
It
is
so
back
to
the
the
original
topic
which
I
think
was:
can
we
make
the
metrics
API
stable,
I?
Think
you,
you
had
listed
three
bullet
points
that
we
need
to
do.
One
of
those
is
review
against
the
spec
I
think
we
we
should
get
someone
from
the
TC
to
do
a
review
again
as
an
outside
check
the
same
way
we
did
before.
B
B
Should
I
then
make
this
into
a
probably
a
ticket
then,
or
something
like
that?
I'm
guessing
foreign
yeah
I
can
handle
that
okay,
yeah
I
think
that's
so,
but
other
than
that
the
rest
of
the
community
is
fine.
With
splitting
the
SDK
and
the
API
release.
B
Okay,
you
see
one
thumbs
up
two
thumbs
up:
cool,
okay,
cool,
then
yeah
I.
Don't
think
this
is
gonna
get
out
before
kubecon,
given
that's
next
week.
So
that's
not
what
I
want
to
do,
but
yeah.
That
sounds
like
something
we
should
probably
take
a
look
at
okay,
one
of
the
other
things
I
wanted
to
get
to
today
is
this.
Ownership
model
was
proposed
during
the
instrumentation
Sig
automation
Sig
for
go
one
of
the
questions
Anthony.
B
One
of
the
things
that
we
were
talking
about
prior
to
this
was
the
instrumentation
for
Source
level.
Modification
seems
like
a
better
fit
to
some
place
that
was
trying
to
host
instrumentation
for
particular
libraries
or
to
help
build
user's
manual
instrumentation,
because
this
is
more
in
line
with
building
manual
instrumentation.
B
It
takes
your
code
and
it
auto
generates
that
manual
instrumentation
and
there's
a
lot
of
thought
in
the
auto
information
saying
that
it
would
fit
better
there,
because
it's
not
really
Auto
transportation,
it's
source
code
modification,
and
because
of
that,
it
was
proposed
that,
if
you
move
back
to
this
contribute
Repository.
B
That
being
said
like,
there
was
a
big
worry
that
was
expressed
in
this
sig
meeting
as
well
and
the
other
ones
for
ownership
of
any
sort
of
changes
that
were
going
in
there,
because
it's
really
not
a
great
place
to
overload
this
community
with
changes
that
need
to
be
reviewed
from
that
community.
So
we
would
need
a
clear
ownership
model
and
I
think
this
is
something
that
is
long
overdue.
B
We
were
talking
about
having
an
ownership
model
in
the
future
repository
one
to
host
different
instrumentation
packages,
but
also
too
just
to
like
clean
up
what
we
already
have.
So
in
that
process.
They
Sig
this
past
week
or
on
Tuesday,
talked
about
an
ownership
model,
and
this
is
to
mimic
the
contrib
I'm.
B
Sorry,
The
Collector
Sig,
so
Anthony
I
would
really
like
your
opinion
on
a
lot
of
us
to
see
like
you
know
like
what
doesn't
work
in
the
collector
sync
as
well
as
is
this
in
line
with
it,
but
it
essentially
defines
the
ownership
model
being
with
code
owners.
The
code
owner
similar
to
the
contributory
need
to
have
some
sort
of
ownership
of
each
module.
That's
added
or
exists
currently
in
the
Repository.
B
The
repo
permissions
need
to
be
updated
so
that
a
PR
for
that
particular
module
requires
reviews
from
those
code
owners
I,
don't
know
if
it's
possible,
but
I,
think
there
was
a
question
of
whether
they
should
be
able
to
merge
in
that
module
as
well.
I,
don't
think
it's
possible,
but
I
it'd
be
cool
if
it
happened,
I
don't
know
if
github's
updated
to
do
that
not
possible
as
far
as
we
know,
yeah.
Okay,
all
right.
B
So
that
would
add
a
burden
onto
the
maintainers
of
this
project
just
to
merge
things
but
I
think
there's
probably
ways
we
could
address
that
and
then
a
deprecation
strategy,
things
that
don't
have
code
owners
are
removed
or
are
abandoned,
are
removed.
Is
something
that
needs
to
be
encodified
in
a
some
sort
of
policy
here,
as
well
as
all
existing
modules
need
to
I
think
be
allocated
as
well?
But.
A
C
So
I
can't
totally
eliminate
the
the
load
on
the
existing
approver
maintainer
core,
because
they'll
have
to
be
code.
Owners
of
these
components
too,
but
hopefully
we
can
have
them
rely
largely
on
the
the
independent
owners
and
potentially
that
could
be
a
funnel
for
new
approvers
as
well.
B
I
can
definitely
speak
to
the
auto
transportation
one
because
I
am
a
maintainer
on
both
projects
as
well
as
you
and
Aaron
as
well,
but
yeah,
that's
a
good
point
for
like
you
essentially
need
a
sponsor
to
get
it
included
here.
So
that's
that's
fair.
C
Yeah
and
that's
how
it's
referred
to
in
The
Collector
as
well,
you
need
a
sponsor
and,
if
they're
vendor
components,
someone
from
the
vendor
is
ideally
one
of
the
code
owners
as.
B
Well,
we
don't
want
a
data
dog
exporter
unless
databog
wants
to
come
by
yeah,
that's
an
old
joke
for
long-standing
members,
I
guess
so:
okay
yeah,
that
sounds
good.
Other
feedback
on
that
Anthony
I
know
that
you
have
the
most
experience
with
this.
C
Yes,
they
there's
a
bunch
of
tooling
that
has
been
being
worked
on
in
collector
contrab
for
things
like
notifying
the
code
owners.
When
so
there's
there's
a
label
that's
attached
to
to
every
component
as
well,
and
then,
when
those
labels
get
added
to
issues
or
PRS,
the
code
owners
are
notified.
That
way,
which
I've
been
finding
helpful,
was
to
to
make
sure
that
you
know
I'm,
aware
of
all
of
the
issues
in
PR's
affecting
components
that
that
I'm
responsible
for.
C
A
I
wouldn't
say
that
they're
a
good
way
to
prevent
components
from
becoming
unmaintained,
because,
most
of
the
time,
the
approvers
who
are
requisitioned
into
having
to
be
approvers
for
it
they'll
help
a
little
bit
to
get
started.
Especially
if
there's
like
someone
who's
excited
about
introducing
a
new
component
has
questions
and
stuff,
but
a
lot
of
them
don't
have
time
to
go,
say,
hunt
down
bug,
fixes
for
a
component
that
they're
technically
approvers
of,
but
you
know
it.
It
works.
A
Yeah
I
guess
talking
about
what
we
would
do
with
something:
that's
unmaintained,
meaning
everyone
except
the
approver
who
isn't
that
interested
in
maintaining
it
is,
has
left
or
you
know,
isn't
maintaining
it
doesn't.
The
Collector
have
a
policy
around
like
if
there
is
a
bug
on
a
component.
That's
has
no
movement
for
a
month
or
some
some
amount
of
time
that
that
labels
it
as
deprecated
and
then
after
another
bunch
of
time
it
can
be
removed.
A
A
B
A
That
idea
was
proposed,
but
for
exactly
that
reason
like
when
people
get
busy
or
things
come
up,
it's
like
it's
hard
to
enforce
that
without
upsetting
people
who
maybe
are
working
on
a
bunch
of
other
things.
So
it's
an
ideal
but
hard
to
live.
B
Up
to
I
think
yeah
and
I
mean
I.
Think
that's
the
that's.
The
key
is
like
it
involves
context,
squishing
right
like
if
you're
there.
If
there's
no
issues
for
three
months
and
all
of
a
sudden
there's
an
issue
like
maybe
you're
in
the
middle
of
a
project
at
work
that
you
can't
get
off
of
for
a
month
right
like
yeah.
C
My
biggest
worry
with
the
you
know,
having
sponsors
who
are
volunteled
that
they
will
sponsor
a
component.
Is
you
you
end
up
being
responsible
for
components?
You
don't
understand,
don't
have
you
know
a
vested
interest
in
and
in
some
cases
might
actually
be
contrary
to
some
of
your
other
interests
like
I,
I
I'm,
the
sponsor
of
the
Azure
blob
store
exporter.
Now,
even
though
I
work
for
AWS
and
have
no
idea
how
Azure
works.
A
B
Yeah
and
I
think
this
is
this
is
the
issue
that
I
was
worried
about
eventually
happening,
we're
there,
where
we
just
have
people
that
are
not
like
in
the
Wheelhouse
like
it's,
so
it's
like
you
said
you
have
to
go,
learn
it
when
you
want
to
go
fix
it
that
says
to
me
that
things
need
to
get
deprecated.
If
that's
the
case
or
or
I
think
Anthony
pointed
out,
it's
a
good
recruiting
tool
to
see.
B
If
there
are
people
in
the
community
that
want
to
adopt
it,
I
mean
like
I,
really
like
our
policy
of
adding
instrumentation
being
like.
Can
it
go
natively
in
the
package?
It
should
go
there
first.
Can
you
host
it
yourself?
You
should
host
it.
Third
then
come
to
the
contrib
like
I.
Think
if.
A
A
B
Going
to
be
asking
people
from
the
other
project
to
come,
maintain
instrumentation
here,
okay,
I,
think
that's
good
feedback.
I
think
that
the
sponsorship
model
should
work,
but
I
also
think
that
it
should
be
a
if
you
want
to
add
something
you
need
to
go
actively,
recruit
a
sponsor
or
get
somebody
on
the
approver
team.
B
Cool
I've
got
feedback
on
that.
I.
Do
think
that
there's
a
PR
that
needs
to
be
created
for
this
policy
next,
for
that
issue,
so
I
think
that
that's
incoming
just
a
heads
up,
it
doesn't
seem
like
there's
any
yeah.
Okay,
I
get
a
thumbs
up,
so
I
know
we're
short
on
time.
I
do
also
want
to
talk
more
on
some
of
these
beta
issues,
but
first
I
want
to.
B
This
is
really
quick.
The
symmetric
convention
generation
thing
is
broke,
I've
been
looking
at
it
for
a
few
weeks.
Now,
it's
disaster
seems
fair.
Upstream
changed
a
lot
of
things.
It
essentially
needs
two
different
generation
code
paths
right
now,
I'm
working
on
developing
them.
It's
going
to
be
a
big
PR.
It's
it's
a
it's
a
it's
a
problem,
but
I'm
still
working
out.
Just
a
heads
up
on
it.
C
So
I
was
I
was
able
to
update
the
collector's
templates
to
generate
1.13
without
too
much
change.
So
let
me
find
the
pr
that
I
did
for
that,
and
I
can
point
you
at
that.
Otherwise,
I
can
take
a
look
at
this
if
you,
if
you
want
as
well
yeah.
B
If
you
have
time,
I'm
definitely
happy
to
hand
it
off
to
somebody
if
you
want
to
take
ownership
of
it.
If
you
want
to
post
the
pr
that'd
be
great
as
well,
I
was
trying
to
make
it
so
that
if
people
still
wanted
to
generate
code
paths
from
prior
to
113,
they
wanted
to
regenerate
112,
it
would
still
work,
but
it
would
be
a
lot
easier
if
we
just
said
like
go
check
out
the
old
code.
If
you
want
to
generate
it
there
and
just
switch
directly
to
the
113
generation.
B
C
A
B
So
it
isn't
unfortunate
because
we
have
a
meta
template
and
that
is
the
oh,
oh
right.
The
the
HTTP
yeah.
A
B
So
Anthony,
if
you
want
to
take
a
look
at
it,
I
love
it.
If
you
want
to
post
the
pr
I
can
still
keep
chugging
on
it.
That
sounds
great
too.
Next
thing
is
the
kubecon.
We
have
more
people
on
the
call
I
want
to
ask
the
question
now
is
Groupons
next
week,
I
think
everyone,
except
for
me
on
this
call,
maybe
he's
going.
A
Like
we
might
be
able
to
find
meeting
space
last
minute,
but
I,
don't
I,
don't
think
we
planned
for
it.
So
yeah.
A
A
B
Okay,
then
I
will
take
that
as
an
extra
item
and
cancel
it
and
I'll
post
in
slack.
B
Cool
this
is
notes
about
the
versioning.
Definitely
some
I
want
to
follow
up
on
that
with
Anthony.
Next
is
this
beta
SDK,
but
that's
that's
a
whole
can
of
worms.
I
could
take
a
whole
hour
itself.
So
with
that
said
triage
meeting
tomorrow,
if
you
want
to
show
up
we'll
still
chunk
through
it,
it's
pretty
sparsely
populated
right
now,
but
I.
You
know,
I
I
think
it's
it's.
It's
also
kind
of
mind-numbing.
B
Sometimes
so,
if
you
want
to
show
up
we'd
love
to
collaborate,
I'll
be
there,
I
know,
Aaron
might
be
there.
I.
C
B
Yeah
that
doesn't
sound
like
fun
at
all:
okay,
cool
we're
right
at
time.
I
want
to
be
respectful
of
people's
time
thanks
everyone
for
joining,
we'll,
see
you
all
asynchronously
or
next
week,
bye.