►
From YouTube: 2022-06-02 meeting
Description
Instrumentation: Messaging
A
B
A
A
It's
been,
it's
been
flirting
with
the
hundreds
most
of
this
week.
B
When's,
the
open
source
conference
is
that
is
that
next
week
or
the
week
after.
D
A
Yeah
yeah
the
monday
is
the
extracurriculars
and
then
the
21st
through
the
24th
or
the
open
source
summit.
A
A
The
nice
thing
is,
the
nice
thing
is
almost
everything
here
is
air
conditioned
so.
A
When
it's
that
high,
it's
usually
about
lows
of
70s,
but
sometimes
it's
been
dipping
down
into
the
60s.
So
oh
nice,
nice
I'll,
also
bring
bring
a
bathing
suit
and
hang
out
in
the
hotel
pool.
D
Yeah,
so
the
meeting
the
location
is
correct.
The
meeting
link
link
in
the
description
was
not.
I
updated
it,
but
probably
updated
it
after
you
loaded
the
calendar.
B
B
Yeah
right,
that
makes
sense,
cool
well
sounds
like
everyone's
getting
here,
so
let
me
figure
out
how
to
share
my
screen.
We
can
start
us
off
awesome,
so
welcome
everyone
thanks
for
joining,
if
you
haven't
already,
please
add
your
name
to
the
attendees
list.
If
you
have
anything,
you
want
to
talk
about,
add
it
to
the
agenda,
and
we
can
jump
in
here.
B
I've
added
two
things:
one's
recurring
one's,
just
kind
of
a
holdover.
So
just
to
start
us
off.
I
wanted
to
take
a
look
at
the
metrics
sdk
alpha
release
projects,
so
we
have
a
current
milestone
here,
still
hovering
around
50
percent
spending.
A
lot
of
time.
I
think,
on
the
the
views.
Pr,
I
didn't
get
an
a
pr
up
this
week,
but
still
still
active
work,
even
if
it
says
it's
kind
of
stalled
in
the
scale
here.
B
As
for
the
project
boards,
this
is
the
current
status.
I
think
that
we
actually
have
a
fair
number
of
things
that
can
be
worked
on
in
the
to
do
column
still
some
stuff
blocked,
but
we
are
making
progress
here.
I
think
this
is
the
active
pr.
I
wanted
to
talk
about
in
just
a
little
bit,
but
yeah
it's
looking
pretty
good.
I
I
guess
also
it's
a
little
bit
of
a
short
week.
B
I
know
monday
was
off
here
in
the
us
and
I
think
I've
got
a
lot
of
european
colleagues
who
are
taking
a
lot
of
time
off.
So
I
don't
know
if
that's
a
standard
thing
in
europe
right
now,
but
yeah,
so
it
kind
of
makes
sense
that
we
might
see
a
little
bit
of
a
a
lull
in
activity
here,
but
just
a
heads
up.
B
This
is
the
active
status
if
you're
looking
to
communicate
or
looking
for
something
to
work
on
cool
with
that,
I
think
this
is
the
pr
hopefully
yeah.
I
wanted
to
kind
of
jump
into
this
a
little
bit.
We
were
talking
about
this
last
week
and
it
was
just
submitted
right
before
the
meeting
last
week.
So
it
looks
like
a
few
people
have
had
some
chances
to
look
it
over.
It's
the
you
know
current
metrics
pr,
that's
open.
B
I
think
there's
only
one
like
I
said,
I'm
getting
anything
open
this
week.
So
there's
I
don't
know
the
best
way
to
look
at.
This
is
there's
a
few
feedback
issues
here,
but
I
wanted
to
touch
base
on
this
issue
with
aaron
just
to
make
sure
that
we're
in
sync
about
instrument-
name
matching-
and
maybe
maybe
it's
better-
I'm
gonna
do
a
lot
of
talking
aaron.
A
So
the
overview
of
the
pr
is
what
we're
creating
here
is
is
the
object
that
kind
of
is
described
that
is
described
by
the
sdk
view
thing.
It
has
two
main
roles
that
can
be
done
independently,
as
per
the
spec.
A
The
first
one
is
to
match
instruments,
specifically
both
the
meter,
the
scope
that
it
comes
from
and
the
instrument
name
or
description-
I
don't
know,
actually
I
don't
think
you
can
match
on
description,
but
the
scope
and
the
name,
and
the
second
thing
that
the
the
second
thing
is
you're
able
to
do
some
kind
of
transform
transformations.
The
description,
the
you
can
filter
attributes
and
you
can
change
the
aggregation
since
we
don't
have
any
kind
of
aggregations
defined.
A
That
is
still
tbd
in
this
patch,
but
I
would
assume
that
that
we
would
come
back
to
that
later,
but
we
can
get
the
the
majority
of
this,
so
there
will
be
a
single
device
that
that
can
do
matching
and
then
also
transformations.
A
A
The
initial
presentation
I
had,
we
used
matt
regex
to
do
wild
card
matching,
specifically,
you
can,
you
know,
get
a
range
of
names
from
a
regex,
but
one
thing
I
would
very
much
caution
against
is
if
we
are
going
to
go
down
the
wild.
Like
writing.
Our
own
wild
card
matching
is
doing
this
kind
of
text
processing,
especially
if
we're
doing
wild
card
matches
within
the
innards
of
a
string
is
very
complicated
and
very
error
prone.
A
B
So
one
of
the
things
that
I'm
really
drawing
this
from
is
this
requirement
in
the
specification,
and
it
says
that
the
name
of
the
instrument
is,
I
think
you
can
match
on
and
authors
can
support
wildcard
matching
and
they
do
specifically
lay
out
what
that
matching
definition
is
for
those
wild
card
characters,
mostly
the
question
mark
and
the
asterisks,
and
if
wild
cards
are
not
supported
in
general,
open
symmetry,
they
need
to
actually
still
support
somebody
catch
all
and
that's
a
single
asterisk
is
one
of
the
things
that
you
need
to
actually
support
if
you're
not
going
to
support
wild
cards-
and
so
that's
kind
of
my
hang
up
here
is
because
this
doesn't
actually
comply
with
that,
so
it
doesn't
support
wildcard
matching.
B
It
supports
regex
matching
which
are
semantically
different,
and
I
guess
not-
maybe
semantically
syntactically
you
can
semantically
do
the
same
thing,
but
yes,
syntactically
they're
different
and
they
don't
comply
in
the
same
sense
that
what
the
specification
would
lay
out.
B
However,
in
that
case,
that
means
that
then
our
string
matching
needs
to
actually
match
on
this
asterisk,
and
so
I
think
that
either
we
need
to
provide
wildcard
matching
or
we
need
to
you
know,
handle
this
case
where
you
have
a
string
match
on
an
asterisk
is
my
concern,
because
otherwise
we
will
not
be
compatible
with
the
specification,
and
I
don't
know
if
you've
looked
at
this
comment
yet
aaron,
but
I
did
propose
something
like
this,
where
you
have
some
sort
of
string
matcher,
which
does
handle
this
string
matching
of
the
the
catch-all.
B
Essentially,
I
guess
it
doesn't
actually
because
this
is
incorrect,
then,
but
I
mean
I
I
don't
know,
there's
there's
some
ideas
here,
but
I
think
that,
like
yeah,
we
can
still
I'm
not
opposed.
So
I
just
want
to
make
clear:
I'm
not
opposed
to
regex
match
matching,
because
I
think
that
that's
probably
the
more
useful
you
know
I.
I
do
think
that
there's
you
know
overhead
for
matching
on
regexes,
but
it.
B
A
So
the
overhead
is
only
done
at
instrument
creation,
so
it's
almost
nil.
B
No
yeah,
that's
what
I'm
saying
yeah
exactly
so
I
think
I
think
that's
fine!
I'm
not
particularly!
You
know
interested
in
in
saying
that
we
have
to
support.
You
know
wildcard
matching
just
to
match
the
specification.
I
don't
think
it's
honestly.
I
don't
think
it's
that
hard
I've
written
those
functions
in
the
past,
maybe
not
in
go.
That
was
a
long
time
ago,
but
I
I've.
D
Done
this,
I
don't
think
we
even
we
don't
even
need
to
rewrite
it.
I
mean
there's
one
I
I
think,
there's
an
implementation
of
wild
card
matching
in
the
actual
remote
sampler
spec,
because
that
also
has
wild
cards
in
it
and
two.
If
we
don't
want
to
do
that,
we
can
simply
convert
it
to
a
regex
by
putting
a
dot
before
the
star
and
replacing
the
the
question
mark
with
a
dot,
and
then
we
can
treat
it
as
a
regex.
A
Also,
adding
the
beginning
and
close
string
tags,
but
the
the
carrot
and
the
dollar
sign,
but
yeah.
I
was
exploring
that
right
now
before
right
before
this
meeting.
D
So
my
take
on
this
is
that
the
spec
doesn't
specify
regex
support
and
I
don't
think
we
should
be
adding
it
for
that
reason.
At
this
time
I
I
recall
that
there
was
discussion
in
the
spec
of
whether
we
should
support
regex.
There
were
some
concerns
from
other
languages
that
it
might
be
difficult
or
there
might
not
be
consistency
in
regex
implementations,
and
so
the
simple
wild
card
was
what
was
specified.
B
Yeah
I
was
having
the
same
concern
in
supporting
an
additional
thing.
That's
not
in
the
specification
but
the
other
side
of
me.
I
didn't
state
it
because
it
also
is
super
useful.
B
You
know
like
I,
I
I
was
kind
of
on
the
fence
of
like
you
know.
This
is
something
like
I
I
imagine
within
a
week.
We'd
have
users
asking
for
it,
so
I
also.
A
So
so
my
interpretation
of
the
spec
is
you:
may
you
may
support
wild
cards
and
then
it
goes
on
and
gives
an
example
of
what
a
wild
card
would
look
like,
but
I
don't
think
that
is
the
only
example
that
necessarily
fulfills
the
wild
card
matching
that
is
intended
to
be
normative.
B
B
That
being
said,
like
I
also
like
I,
I
would
support
if
we
wanted
to
just
pull
it
out,
and
you
know
I
think
we
have
proposals
here
where
we
could
add
options
in
the
future
and
if
we
wanted
to
start
with
just
the
simplest
possible
thing.
Like
honestly,
I
don't
think
that's
a
problem
but
yeah.
I
I
just
wanted
to
like
kind
of
bounce
that
off
yeah.
A
I'm
okay,
the
I'm
okay!
With
that
I've
found
it.
It
is
very
simple
like
if
we're
going
to,
I
don't
have
a
working
regex,
one
that
might
be
a
path
forward.
I
found
it
very
simple
to
add
post
wildcard
expansion,
so
just
if
the
while,
if
the
suffix
is
a
star,
then
we
can
just
do
we
can
do
a
check
prefix
like.
Is
it
a
prefix
that
is
very
simple,
but
it
yeah
and
furthermore,
like
honestly,
the
internals
of
how
the
match
happens
isn't
exposed
publicly.
A
B
The
only
thing
is
the
api
right,
so
it's
that
option,
and
so
I
think
that
that's
kind
of
like
the
key
there
is
like
if
we
could
get
the
option.
B
I
if
I
honestly,
if
you
could
just
unify
the
option,
I
was
looking
into
like
maybe
exposing
some
sort
of
interface
there.
So
we
could,
you
know,
build
from
it
in
the
future
or
using
a
generic
which
that
didn't
make
any
sense.
But,
like
you
know
like
it's
just
that
api
right,
and
I
think
that,
if,
if
we
want
to
just
build
out
another
option
in
the
future,
like
add
match
instrument
main
regex
in
the
future,
that
would
also
work
right
so,
like
I
think
we
could
just
do
that
as
an
extension.
B
C
B
That
just
the
internals,
that's
also
the
key,
is
like.
I
think
that
one
of
the
things
that
the
proposal
I
had
and
I
think
that
you're
kind
of
looking
at
it
as
well,
is
like
when
you
create
the
view
like
trying
to
return
the
least
number
of
errors
that
the
user
has
to
handle.
I
think,
is
ideal,
so
having
last-in-wind
semantics
is
probably
better
than
having
an
error
detection.
When
you
pass,
you
know
a
regex
or
a
name
or
something
like
that.
A
You're
yeah
the
proposal
that
I
had
you,
you
would
still
have
last
win.
B
B
But
yeah
I
mean
like
I'm
also
just
looking
at
the
specification-
and
you
know
what's
really
required,
is
that
we
have
to
support
a
name
matching
for
the
instrument
name
with
the
string,
and
maybe
we
don't
have
to
support
wild
cards
we
do
have
to.
B
We
do
have
to
support
a
an
asterisk
right
like
in
a
catch-all
for
all
and
then
yeah,
then
the
transformations
again
like
it's
a
description
is
essentially
the
description
thing
that
we
need
to
be
able
to
translate
right,
and
so
I
think,
as
long
as
we
we
have
those
those
key
things
down.
We
can
always
build
from
that.
If
that
makes
sense,.
D
Yeah,
so
that's
that's
the
implementation
we
have
in
the
x-ray
remote
sampler
of
converting
a
string
with
traditional
wild
card,
glob
style
semantics
into
a
regex
okay,
so
it
basically
builds
it
up
takes
any
part.
D
That's
not
a
wild
card
quotes
it
with
regex,
quoting
so
that
it
doesn't
get
treated
as
regex
converts,
dot
to
dots
or
started
out
star
and
question
mark
to
dot,
and
I
I
think
that
should
give
us
what
we
want
in
terms
of
being
able
to
process
as
a
regex,
a
wild
card
string
yeah,
and
so
we
should
be
able
to
simply
support
wild
cards
initially
and
keep
open
the
option
to
have
direct
user-provided
regexes
later
on.
If
we
get
that
specified
in
some
way,
that's
workable
for
us
with
re2.
B
I
honestly,
if
I
see
two
ways
like
I
think
I
think,
if
we're
going
to,
we
can
go
the
simple
way
and
I
think
that
we
should
just
tear
everything
back
and
just
essentially
provide
string
support
or
if
we
want
to
add
this,
which
I
don't
I'm
not
really
opposed
to,
because
I
think
that
there's
a
lot
of
value
here,
we
could
add
wild
card,
and
then
we
don't
have
to
add
like
this
asterisk
thing
at
the
string
and
at
the
same
time
we
could
add
regexes,
because
it
would
just
be
like
a
natural
extension.
B
I
I
honestly,
I
don't
have
strong
opinions
either
way.
I
just.
I
feel
we
feel
really
strongly
that
our
current
approach,
where
we
don't
implement
the
specification
we
need
to,
we
need
to
make
a
decision
off
of
that.
D
I
think
I
would
prefer
to
have
at
least
the
minimum
wild
card
support,
whether
we
do
that
by
having
a
wild
card
parser
or
doing
the
conversion
to
regex.
I
would
be
a
bit
wary
of
adding
regex
support,
simply
because
re2
is
weird
and
not
pcre,
and
I
hate
it
and
and
russ
I
I
will.
I
will
fight
100
duck-sized
russes
over
this
anytime.
B
I
don't
know
yeah
there's
a
few
other
authors
there
that
I
might
just,
I
might
be
afraid
of
I'm
just
gonna,
say
it
that
way:
okay,
cool
aaron
does
that
make
sense
as
a
plan
forward.
So
what
we're
trying
to
do
is
do
string
and
a
wild
card.
A
Sure
I
think
so
how
about
this
I'm
trying
to
work
a
solution,
that's
similar
to
what
anthony
posted
of
converting
that
string
into.
A
And
I
think
it's
90
there.
I
just
got
a
good
debug,
a
problem
that
I
found
if
that's
acceptable,
how
about
we?
We
move
with
that,
if
not
we'll
part
price
it
back
just
to
the
star
match
and
then
only
the
star
match.
A
B
I
think
that
sounds
good.
I
guess
then
my
question
is:
how
do
you
want
to
present
that
api?
Do
you
want
a
option
where
it
will.
B
C
A
Either
do
wild
card
support,
or
in
the
alternate
it
will,
an
alternative
is
to
match
on
star.
D
D
I
I
think
with
name
is:
is
the
right
api,
regardless
whether
we
have
files
card
support
or
not,
and
then,
if
we
later
add
reject
support,
we
could
we
could
have
like
with
name
right
x
or
something
like
that.
That's.
E
A
Is
there
any
feedback
on
the
difference
between
match
versus
width?
I
know
it's
a
little.
A
But
that
is
the
fact
that
these
views
do
two
separate
things
right.
They
both
match.
D
Well,
and
do
they
do
they
have
a
name
themselves
so
like
with
name
would
be
the
name
for
the
view
match
name
would
be
the
or
match
instrument.
Name
would
be.
The
name
of
the
instrument
to
match
is
there
is.
A
There
is
a
match
on
meter
name,
so
that's
why
it's
match
instrument
name
match
meter,
name
or
I
think
maybe
scope
name,
and
there
is
a
width
name,
which
is
both
the
view
name,
but
also
the
output
name
of
the
instrument,
slash
metric.
That
comes
out
of
that
view.
Right.
B
Yeah,
which,
just
as
a
side,
is
confusing
to
me,
not
your
specification.
Yes,.
B
Post
yeah,
it's.
I
think
this
is
the
the
section
that
kind
of
describes
that
yeah
it.
B
B
So
I
guess
that's
kind
of
yeah,
I
don't
know
we
can
essentially
do
that
like.
If
you
do
this
wildcard
substitution
thing,
you
can
see
if
you
made
any
modifications
and
if
you
did,
that
means
that
it
was
a
wild
card
and
it
was
therefore
possibly
going
to
match
more
than
one
instruments.
Therefore,
should
error.
A
I
mean
technically,
if
you
don't
support,
if
you
don't
supply
a
name,
a
single
match,
name
right,
anything
that
there
is
potentially
a
conflict
so
like
if
you
supply
a
meter
name
or
a
scope,
name
right,
but
you
don't
do
an
instrument,
name
yeah,
but
you
don't
include
an
instrument
name
with
view
or
with
name
will
also
create
conflicts
like
the
only
way
you
can
use
with
name
is
if
you
have
a
non-wild
card
instrument
name
also,
so
I
found
that
I
I
realized
that
so
there's
a
patch
that
I'm
working
on
that
will
correct
that
yeah.
A
Okay,
also,
I
I
realized
that
I
left
that
I
created
the
new
instrument
and
left
the
old
descriptor
in.
So
that's
going
to
be
pulled
out
here
by
the
end
of
the
day,
probably
okay,
so
cool.
A
B
B
Do
we
want
to
continue
on
with
this
options
approach,
or
should
we
be?
You
know
one
of
the
things
I'm
asking.
I
guess
is
I'm
beating
around
the
bushes.
You
know
we
have
a
lot
of
matching
things
and
we
have
a
lot
of
modification
or
transform
things.
Should
we
instead
take
a
modify
function
and
a
transform
function
and
essentially
like
build
a
way
like
find
a
way
to
compile
both
of
those
I'm
just
wondering
if.
A
I
did
I've
not
found
one
that.
A
A
Transform
functions,
one
zero
or
more
transform
functions
and
guarant
like
not
have
that
error
case;
yeah;
okay,
everything
that
I've.
B
The
only
thing
that
came
to
my
mind
was
like
a
chaining
api,
which
probably
is
not
a
good
idea,
since
we
never
use
that.
D
That
is
really
a
chain
api,
but
like
a
combination,
api
boolean,
with
an
and
or
similar
to
http
instrumentations
filters
where
it's
got
any
all
and
none
and
you
can
compose
them.
That
way
could
be
one
way
to
do
it.
But
we
use
the
the
functional
options
pattern
pretty
much
everywhere,
so
I
I
think
not
to
do
that
might
be
surprising.
A
Yeah,
I
I
also
considered
something
similar
to
that,
but
that
became
way
more
complex
and
for
almost
no
benefit
over
this
as
well.
B
Catch
it,
okay,
awesome,
aaron!
Is
there
anything
else
we
need
to
talk
about
on
this
vr?
I
think
we've
got
a
lot
that
we've
discussed.
I
don't
want
to
overload
you
or
anybody
else,
but
okay,
okay,
cool.
I
think
the
only
other
thing
I
had
was
this
auto
prop
pr
just
a
reminder:
it
exists.
Maybe
there
was
a
discussion
last
week
that
we
talked
a
little
bit
about
the
registration
mechanism.
B
I've
got
some
approval,
so
maybe
I'm
speaking
to
an
audience
that
doesn't
need
to
hear
this,
but
essentially
just
kind
of
heads
up
anybody
on
the
call.
We
did
decide
that
we
were
gonna
go
through
this
panic
when
the
registration
is
that
the
kind
just
for
a
safety
guarantee
here
so
that's
been
updated
but
yeah.
If
you
haven't
seen
it,
please
take
a
look.
B
There's
been
a
reference
to
it
in
you
know,
as
as
using
as
an
example
for
then
building
out
the
specific
exporter
initialization,
similar
to
what
we
talked
about
last
time
out.
Aaron
and
a
few
people
have
created
packages
for
that
we
could
do
something
similar
cool.
I
think
with
that.
There's
nothing
else
on
the
agenda.
B
So
I'll
stop
sharing
and
I
do
see
some
new
faces
damien.
I
definitely
see
you
there
and
I
wanted
to
kind
of
pause
and
make
it
really
awkward
and
throw
people
on
the
spot.
I
don't
see,
oh
ambassador,
so
when
we
pause-
and
maybe
we
can
do
a
little
introductions
community
introductions-
I
know
that
we've
seen
people
asynchronously,
but
maybe,
if
you
wanted
to
like
just
unmute
and
say
hi
or
turn
off
your
camera
and
say
I'm
not
interested,
that's
cool
too.
I
want
to
respect
that
as
well.
C
Yeah
thanks
yeah,
you
may
have
seen
me
asynchronously
so
yeah.
I
work
at
an
observability
team
at
ob0
and
I
have
been
contributing
since
january
around
like
that
and
I
became
an
approver
two
weeks
ago.
B
Yeah
welcome
I'm
glad
we
were
able
to.
C
Thanks
thanks
for
moving
the
meeting,
7
pm
isn't
isn't
perfect
but
way
better
than
10
pm.
B
Yeah,
I
could
see
that
I
don't
think
I
think
we
used
to
have
another
meeting
in
hotel.
That
was
at
10
p.m,
and
I
went
zero
time.
So
I
can
understand.
B
And
vassi
I
see
you're
from
aws.
I
can't
remember
if
we've
seen
you
before
I
apologize.
G
B
Yeah,
well
welcome
glad
to
have
both
you
cool
so
with
that.
Maybe
I'll
just
pause
and
see
if
anybody
else
wants
to
add
something
to
the
agenda
or
just
bring
up
a
topic
of
conversation.
B
F
C
B
That's
a
really
good
question.
I
think
you
take
all
the
boxes
for
getting
it
into
the
contrib,
except
for
maybe
one
but
we'll
get
to
that,
and
mostly
that
box
is,
did
you
try
to
submit
this
upstream
because
I
think
that's
the
ideal
location
for
it.
B
I
think
the
second
would
probably
be
self-hosted,
but
that
kind
of
thing
kind
of
comes
down
to
this
other
question
that
I've
been
having
for
a
little
bit
is:
if
we
can,
we've
talked
about
this
in
the
past
having
an
ownership
model
in
the
contrib
repo,
and
I
think
that
if
we
do
something
similar
to
what
the
collector
can
trip,
repo
is-
and
so
this
is
maybe
where
I'm
gonna
lean
on
anthony
for
some
suggestions
here,
but
where
they
have
a
collector,
contrib
repo
and
anything
that's
submitted,
gets
an
owner
file
or
some
sort
of
ownership
from
a
person,
and
if
that
person
is
no
longer
able
to
own
that
that
that
contribution
gets
removed,
essentially
anything
that's
not
owned
is
removed
from
the
repo.
B
I
think
that
that's
that's
a
a
good
approach.
I
want
to
try
to
like
pass
that
by.
We
need
to
make
this
a
little
bit
more
of
a
policy,
but
it's
just
an
idea
at
this
point,
because
I
I'm
really
wary
of
a
lot
of
times.
We
get
things
thrown
over
and
we
just
do
not
have
the
developer
capacity
to
maintain
that
repo,
if
it
just
is
endlessly
growing.
B
D
Yeah,
so
that's
the
general
idea
behind
how
the
collector
contrib
operates,
I'm
not
sure
if
anything's
ever
actually
been
removed
for
not
having
an
owner,
but
it's
it's
the
idea
at
least,
and
to
to
this
point
you
know
things
that
haven't
been
removed,
that
don't
have
owners
are
at
least
stable,
and
you
know
the
maintenance
burden
isn't
excessive.
But
if
you
know
something
comes
up,
tests
start
failing
and
nobody's
around
to
fix
them.
D
Theoretically,
they
will
get
removed.
There's
been
discussion
recently
of
github,
adding
abilities
to
add
permissions
at
a
per
directory
level
like
more
fine-grained
permissions.
I
think,
which
is
a
thing
that
was
really
missing
in
that
ownership
model,
because
it
still
required
maintainers
to
merge
prs
into
into
those
theoretically
owned
components.
D
If
we
could
get
to
that
point
where
we
could
have
people
wholly
owning
their
components
and
all
the
way
up
to
merging
pr's
into
them,
then
the
maintainers
will
be
responsible
for
release
management
effectively
or
the
the
components
that
the
maintainers
are
the
owners
of
as
well.
F
One
more
difference
between
potentially
this
repo
and
the
collector
is
that
the
being
included
in
the
contrib
build
is
a
really
big
deal.
So
that's
a
big
lever
that
they
have
to
sort
of
not
remove
the
code
but
potentially
like
if
something
isn't
secure
or
has
other
issues
that
aren't
being
addressed.
Then
it's
one
lever
that
they
have
that,
potentially
we
don't
have
as
much
control
over.
B
C
I
guess
that
makes
it
similar
to
having
its
own
on
a
personal
account
and
then
maybe
very
busy,
being
forked
and
archived,
with
the
additional
visibility
of
it
being
on
the
open,
telemetry
organization.
B
Yeah
and
in
that
respect,
we've
tried
to
push
people
to
just
hosting
their
own
and
then
registering
it
in
the
open
telemetry
registry.
I'm
fine
doing
that
as
well
yeah.
That
might
be
a
good
way
to
start.
I
would
like
to
have
a
better
answer
in
total
to
having
you
know
like
stuff
hosted
in
the
contrib,
so
I
guess
I'm
using
your
example
as
a
way
to
like
start
that
conversation,
I
think
you
and
xm
and
exams
hotel
sql.
I
can't
remember
the
package
are
two
good
candidates.
B
You
know
to
to
potentially
include
but
yeah.
So
maybe
maybe
that's
a
really
good
answer
damian
for
you,
it's
just.
I
would.
I
would
recommend
hosting
it
on
your
own
and
then
registering
it.
Maybe.
B
I'll
do
that
yeah,
yeah
yeah,
that's
cool
yeah!.
B
Well,
okay,
I
think,
with
that,
then
we've
got
through
the
agenda
got
through
some
user
stories.
Introductions
cool!
I
think
we
can
end
the
meeting
at
this
point
thanks
everyone
for
joining
and
appreciate
all
the
contributions,
see
y'all
asynchronously
or
same
place
same
time
next
week,
bye,
bye,
bye,.