►
From YouTube: 2021-04-12 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
Yeah
the
exporter
and
then
we're
trying
to
use
it
internally
too,
to
generate
our
own
observability.
B
Now
I
work
for
influx
data,
so
we
just
want
to
be
a
platform
and
flex
tv
is
more
of
a
platform
to
store
time
series
than
it
is
a
particular
apm
or
sas
for
anything
other
than
general
time
series.
D
D
D
All
right
good
morning,
everybody
welcome
to
our
weekly
maintainers
call.
We've
got
a
few
topics
today,
but,
as
usual,
we
will
start
with
the
sig
check-in.
Carlos.
I
see
you're.
Currently
writing
the
spec
one,
but
if
you
wrote
first,
you
want
to
talk
about
it.
At
the
same
time,.
E
Yes,
so
sorry
yeah,
I
was
meant
to
release
last
week.
It's
it
was
it's
a
minor
version
anyway,
but
you
know
we
wanted
to
keep
the
cadence,
so
I'm
gonna
do
it
right
today
it's
going
to
include
just
minor
stuff,
but
still
we
want
something.
C
Yeah
no,
it
does.
It
doesn't
keep
some
fairly
significant,
potentially
breaking
stuff
around
semantic
convention
generation,
so
anyone
who's
generating
semantic
inventions.
There
are
changes
that
that
will
break
potentially
break
the
generator
code.
C
About
apr
in
the
java
repo
to
fix
issues
that
are
broken
with
the
current
system,
I
don't
know
the
details.
Okay,
interesting.
F
The
syntax
change,
not
the
content
itself,
so
the
semantic
conventions
there
are
very
few,
I
think,
even
breaking
changes,
but
this
is
about
the
the
number
to
ind
and
double
syntax
and
that
stuff,
but
yeah
people
will
have
to
upgrade
to
the
latest
generator
version,
which
was
released
in
the
build
tools
repository
and
might
have
to
upgrade
their
templates.
But
I
don't
think
we
have
that
many
code
generators
anyway
in
place
only
java
and
javascript.
I
think.
E
Right:
okay,
yeah
thanks
for
thanks
for
that.
I
will
add
a
note
there
then,
and
I
will
mention
this
in
slack
yeah.
I
was
asking
about
janna's
changes
because
we
will
be
using
lowercase
and
that's
a
breaking
change.
What
I
was
postponing
that
after
the
release
like
you
know
like
we
were
using
like
a
lot
of
upper
keys
for
values,
and
we
want
to
just
go
simple
with
a
lowercase
but
yeah
thanks
for
the
heads-up.
G
G
I
would
suggest
that
we
discuss
this
in
the
spec
meeting,
but
we
should
my
understanding.
H
E
That's
an
interesting
one.
Okay,
in
that
case,
we
can
hold
the
the
the
release
for
tomorrow
weekends.
Tomorrow
I
mean
somebody
conventions
are
still
experimental
part
but
yeah.
That's
a
good
call.
So
let's
discuss
that
tomorrow
and
then
we
can
yeah
and
then
whether
it's
a
yes
or
no,
we
can
release
so
tomorrow
for
sure
will
be
happening.
The
release.
D
All
right
next
up,
we
have
php
nothing
new
to
report
so
we'll
move
on
to
java
yeah
as.
C
Right
there
we
released
last
1.1.0
last
week,
not
anything
gigantic
in
there,
but
there
was
a
significant
reduction
in
the
cpu
overhead
of
the
bass
band
processor,
there's
an
extremely
lengthy
blog
post
from
the
doordash
engineer
who
drove
that
change.
That's.
D
I
No
we'll
be
releasing
one
one
zero
this
week
on,
based
on
the
java
sdk
one
one.
D
C
Yeah
so
that
we
have
canceled
the
wednesday
java,
only
sdk
api
meeting
merge
that
into
the
two
the
thursday
morning,
instrumentation
meetings,
note
there's
also
two
other
java
open,
telemetry
related
meetings
in
the
week
as
well.
There
are
more
asia
pacific
friendly,
so
this
is
reducing
four
meetings
down
to
three,
which
I
think
is
a
good
thing.
Nice.
E
All
right,
javascript
up
by
the
way
before
we
go
yeah,
sorry
small
thing.
Thank
you
so
much
for
the
blog
post,
john!
Well,
you
didn't
write
it,
but
you
know
like
I
think
you
were
very
involved
with
this,
and
actually
this
just
call
out
for
everybody,
please,
when
you
are
doing
something
like
this,
please
try
to.
If
you
have
time
to
write
a
blog
post,
it's
very
interesting
and
I
think
that
as
community
we
could
get
a
lot
of
you
know
like
a
lot
of
attention.
E
You
know
by
having
this
stuff,
because
I
think
that
a
lot
of
stuff
is
happening
in
private
and
we
have
to
you
know
to
try
to
communicate
more.
G
D
And
plus
one
for
me
as
well,
and
certainly
you
can
write,
certainly
it's
great
to
post
on
your
own
blog
or
if
you
have
a
company
blog
and
if
you're
interested
in
writing
on
the
project
blog
you
can
reach
out
to
myself
or
ted,
or
I
think
el
alita
there's
a
number
of
the
governance
committee.
Members
all
have
the
ability
to
authorize
posts
there,
so
just
write
up
a
draft
and
send
it
our
way.
G
J
Okay,
we
resolved
the
dependency
issue
that
I
talked
about
last
week,
so
I
believe
our
rc
should
be
ready
this
week.
If
not
then
certainly
next
week
and
the
api
rc
has
gone
well,
we
are
looking
for
a
tc
member
to
do
a
spec
audit.
If
any
tc
members
have
experience
with
javascript
or
anything
like
that,
that
would
be
nice.
E
Separately,
I
have
been
doing
that
for
a
pair
of
languages,
so
I
guess
I
can
do
that
since
I
kind
of
know
what
things
to
look
out
for
so
yeah.
Let's
do
it.
That
sounds
great.
Thank
you.
Thank
you.
I
guess.
F
C
K
Yeah
we're
just
we're
planning
to
do
our
4.1
release
later
this
week.
There
were
some
changes
after
our
1.0
release
and
yeah
there
was.
We
also
released
our
experimental
api
sdk
packages
this
week
as
well.
So.
L
Yeah,
so
we
have
completed
our
internal
audit
of
the
spec
yeah,
so
we
think
we
have
identified
all
the
issues
we
need
to
complete
to
get
to
compliance.
Our
rc
milestone
currently
has
13
issues
to
go.
That's
only
down
one,
but
we
are
up
10
in
the
completed
column.
So
we
we're
starting
to
make
progress
there
finishing
a
bunch,
but
we
are
adding
less
to
the
to-do
than
we're
finishing,
which
I
think
is
good,
so
that
progress
will
continue.
M
Oh
yeah,
so
we
still
are
targeting
for
the
release
candidate
for
the
day
end,
but
I
think
it
looks
like
with
the
progress
we
had
from
past
couple
of
weeks.
Maybe
we
have
to
revisit
it
still.
Our
sdk
is
not
finalized.
You
are
still
doing
some
changes
in
sdk
for
multiprocessor
support
baggage.
Api
is
still
not
there
in
place,
so
there
are
some
some
stuff
which
I'm
missing.
M
So
probably
we
may
have
to
revisit
our
release
candidate,
maybe
further
from
me
and
yeah,
and
apart
from
that,
we
are
definitely
looking
for
some
good
c
plus
developers.
So
that's
something
we
ask
which
is
coming
from
past
couple
of
weeks.
So
if
somebody
is
there,
please
come
forward
for
that
and
yeah.
That's
all.
D
Great
thanks
for
the
update,
I
saw
someone
just
write
in
an
update
for
net.
If
you
want
to
speak
up,
whoever
that
was
otherwise
we'll
move
on.
G
Okay,
sorry
morgan.
I
just
had
a
question
on
the.net
instrumentation
work.
Riley,
do
you
have
an
update
on
on
the
instrumentation.
N
I
I
think
most
of
the
instrumentations
are
in
the
country
like
in
the
country
report,
there's
some
core
instrumentation
library
like
asp.net,
which
is
released
at
the
same
schedule
as
donald,
so
those
are
currently
inside
the
the
main
repo.
The
idea
is
once
the
semantic
convention
is
released,
that's
stable,
we'll
release
the
stable
version
and
and
then
move
all
the
instrumentations
to
the
control
variable.
G
Okay,
okay
and
then
would
you
have
a
timeline
for
that
is
that
in
the
1.1.0
or
beta
or
the
next
release,
I.
N
O
Yeah
we're
we're
still
working
towards
rc.
I
linked
the
milestone
there.
There's
there's
two
issues
in
it.
As
we've
kind
of
done,
some
audits,
we've
turned
up
some
more
things.
One
one
of
the
issues
has
an
open
pr.
The
other
issue
is
kind
of
an
open
discussion
around
a
convenience
method
that
we
have.
I
will
probably
start
a
discussion
in
the
hotel
slack
channel
about
that.
O
D
H
Swift
yeah
we're
still
working
towards
a
1.0
release.
I
think
we've
resolved
the
majority
of
the
issues
that
carlos
brought
up
in
terms
of
the
hotel
spec.
D
Okay,
I'll
catch
up
with
them
later,
okay,
so
we're
done
with
the
sig
check-ins
looks
like
the
first
topic
for
discussion
is
by
nikita.
How
can
we
include
third-party,
auto
instrumentation
into
the
hotel
registry
and
contribute.
P
I
think
that
question
is
very
related
to
them
yeah
the
next
topic
as
well,
the
specific
the
specific
case.
The
why
I
brought
the
topic
here
is
that
we
discovered
the
third
party,
auto
instrumentation
or
third
party
instrumentation,
and
when
we
asked
why
that
instrumentation
is
hosted
by
the
application
developers
themselves
and
not
part
of
open
telemetry
javascript
country
people.
P
The
answer
was
that
they
tried
to
contribute
that
instrumentation
into
hotel
country
prepa,
but
review
process
took
more
than
a
month,
and
they
are
very
scared
that
in
the
future,
if
they
would
need
to
make
some
bug,
fixes
or
improvements,
that
review
process
will
again
take
so
long
time,
and
because
of
that,
they
decided
that
they
will
host
that
outside
of
open,
telemetry
and
just
well.
We
we
will
not
contribute
that
to
hotel,
because
hotel
is
not
taking
that.
D
Yeah,
this
is
a
you
don't
mind.
We've
probably
just
moved
this
into
the
next
discussion,
because
this
was
this
was
very
related
and
it
was
how
do
we
want
to
handle
code
contributions
to
the
hotel
registry
and
to
contrib?
So
this
is
one
example.
D
I've
heard
through
the
grapevine
that
other
other
maintainers
are
underwater,
just
reviewing
contrib
contrib
prs
and
so
there's
a
challenge
where
there's
people
submitting
code
to
the
project
where
they're
saying
hey
this
is
taking
a
month
to
get
reviewed
and
by
then
I
want
to
make
changes,
and
this
is
kind
of
ridiculous
and
the
maintainers
themselves
saying
hey,
I'm
completely
swamped.
D
I
can't
actually
like
do
a
lot
of
core
commitments
to
the
project
that
I'd
like
to,
because
I'm
so
busy
reviewing
code
donations
to
contrib,
and
so
I
don't
actually
have
a
strong
opinion,
but
I'm
curious
amongst
the
maintainers,
like
historically
we've
followed
a
model
where
we've
tried.
If
we
can
to
get
as
much
code
as
as
much
code
as
we
can
inside
of
the
open,
telemetry,
org
and
and
review
it
with
a
certain
level
of
quality
is:
do
we
think
this
model
is
sustainable?
D
Do
we
prefer,
if
things
were
hosted
elsewhere,
like
like
this
example,
that
nikita
brought
up?
Do
we
prefer
that
we
had
maybe
made
the
contrib
repos
more
of
a
wild
west
where
they're
not
reviewed,
and
we
we
basically
take
anything
that
comes
in.
I'm
curious,
like
what
people's
opinions
are
in
the
current
state
and
ideas
they
have
for
fixing
it.
P
P
One
is
provided
by
core
maintainers
because
because
they
think
that
this
library
or
framework
is
very
important
for
this
language
ecosystem,
so
we
are
going
to
provide
them
ourselves.
Two.
We
may
have
a
country
people
where
third,
the
external
contributors
can
be
code
owners
for
like
a
subtree
or
their
specific
contribution,
but
we
still
have
to
provide
some
kind
of
not
exactly
tck
but
some
guidelines
and
test
hardnesses
and
verification
that
these
corresponds
to
open
telemetrics
monthly
conventions.
P
But
maintenance
burdens
is
less
because
we
are
explicitly
saying
these
are
maintained
by
external
contributors
and
then,
and
the
third
tier
is
totally
out
external
contributions
hosted
by
external
repos,
but
even
for
them.
We
need
to
have
some
kind
of
process
when
we
can
include
them
in
open,
telemetry
registry,
because
for
me,
open
telemetry
registry
should
be
that
kind
of
stamp
of
approval.
This
is
somehow
reviewed
by
open
telemetry.
It
uses
our
processes,
it
patches,
security
problems,
fast
enough,
etc,
etc.
P
G
Yeah,
so
nikita
just
to
clarify
so
this
this
doc
was
specifically
focused
on
instrumentation,
but
in
general
the
ability
for
the
project
to
absorb
you
know,
review
and
absorb
any
components.
Landing
into
contrib
has
been
a
bottleneck
right.
Just
that's.
That's
just
been
something
that
you
know
the
last
year.
As
you
know,
more
more
contributors
have
come
and
added
you
know
and
contributed
to
the
project,
and
especially
when
we
get
a
surge
of
interns
in
the
bummers.
You
know.
G
P
So
I
think
that
I
think
that
the
instrumentations
will
be
the
main
concerns
because
they
are
essentially
unlimited
or
insertionally.
Unlimited
number
of
instrumentations,
as
opposed
to
quite
limited
number
of,
like
exporters
or
core
components
that
that
may
come
in.
G
P
G
P
D
I
I
think
this
point
probably
still
stands
right,
like
the
challenge
is:
if
we
have
a
repo
where
there's
a
lot
of
contributions
for
additional
instrumentation
or
exporters,
or
what
have
you,
the
the
maintainers
and
and
the
approvers
are
going
to
be
tasked
with
with
a
high
volume
like
high
throughput
of
things
they
have
to
vet.
I
I
will
say
like
we,
I
I
do
think
we
have
to
balance
this
intent.
I
didn't
have
a
chance
to
do
doc,
but
I'm
guessing
this
is
in
there.
We
do.
D
We
do
want
to
balance
this
where,
if,
if
we
had
everything
external,
where
we
just
said,
yeah
people
go
write
instrumentation
in
your
random
personal
repos,
all
over
github.
We
have
this
like
not
just
a
potentially
quality
problem
where
things
will
get
out
of
date,
but
also
the
problem
of
people
potentially
like
doing
duplicate
triplicate.
Work
on
on
sort
of
competing
is
the
wrong
word,
but
like
duplicative
instrumentation,
so
I
I
I
I'm
curious,
like
what
other
solutions
people
think
are
available.
J
One
thing
I
guess
that
does
make
java
different
where
nikita
just
did
just
say
java
doesn't
really
have
this
problem.
They
also
have
separated
instrumentation
to
be
handled
by
a
separate
set
of
maintainers.
J
Who
are
what
I
understand
from
the
outside
solely
responsible
for
that
coming
from
javascript,
where
you
know
obviously,
js
is
the
is
the
the
issue
in
the
dock
here
that
people
have
brought
up,
I
can
say,
as
one
of
the
gis
maintainers,
I
know
that
I'm
bottlenecking
contrib,
like
I
know
it's
a
problem
and
I
just
have
other
priorities,
and
I
can't
spend
as
much
time
as
I
would
like
to
on
contrib.
J
So
if
we
had
a
separate
set
of
maintainerships
for
contrib,
that
would
take
a
lot
of
load
off.
I
think.
L
Yes,
we're
really
focused
on
hitting
the
the
rc
and
trying
to
get
the
api
and
the
sdk
into
shape
and
having
been
able
to
dedicate
the
attention
to
the
incoming
work
in
the
sd
or
in
the
contrib
repo.
I
know
we've
had
a
number
of
pr's
that
have
been
closed.
We've
had
some
like,
for
instance,
the
the
database
instrumentation,
where
we've
explicitly
said,
hey
we're,
not
sure
how
we
want
to
handle
this
going
forward.
L
Please
go
put
this
in
a
personal
repo
so
that
we
can
get
some
experience
out
in
the
community
and
figure
out.
You
know
which
of
there
are
several
approaches
that
could
be
taken,
which
of
them
are
our
best
and
then
we'll
talk
about
bringing
something
into
contribute.
Yeah.
G
Also
long
term
I
mean
you
know
there
will
be
more
additions
to
the
project
and
surges
that
are
predictable
or
unpredictable
of
contribution
right,
so
I
mean
how
do
we
increase
the
pool
of
approvers
and-
and
you
know,
reviewers
and
maintainers
in
general,
when
the
collector
has
the
same
bottleneck
right?
So
it's
it's
just
that
we
need
to
be
able
to
figure
this
out.
B
Yeah,
I
mean:
let
me
share
something
from
the
perspective.
I
guess
a
vendor
influx
data.
Would
we
have
a
couple
of
products
that
that
we
would
also
like
to
be
consistently
compatible
with
open
telemetry
like
telegraph,
and
I
keep
trying
to
get
ahead
of
people
just
throwing
things
into
open,
telemetry
or
outside
it?
Would
that
would
generate
a
different
schema
going
into
line
protocol
for
influx
db
or
telegraph,
and
I
would
happily
happily
own
that
sub
directory
of
the
collector.
B
That
is
the
line
for
the
influx
data
line,
protocol,
exporter
and
receiver,
because
because
that
gives
me
the
opportunity
to
give
everybody
in
that
community
a
consistent
experience
within
open
telemetry
and
within
other
communities.
G
Yeah
yeah
absolutely
and
case
in
point
again.
You
know
we
had
to
do
the
same
with
the
prometheus
work
that
is
ongoing
for
the
in
the
prometheus
work
group,
where
we
actually
requested
a
separate
repo
to
be
able
to
work
through
and
build
experimental
versions
of
you
know
the
operator
or
the
changes
or
the
receiver
changes
or
text
water
changes.
So.
P
J
It
seems
like
there's
little
problem,
giving
them
access
to
maintain
that
where
we
run
into
trouble
are
more
on
the
instrumentation
side
less
on
the
exporter
side,
just
I
think,
due
to
the
nature
of
instrumentation
tending
to
be
written
by
someone
who
is
not
related
to
the
underlying
project
that
the
instrumentation
targets-
and
this
also
is
true
for
interns.
J
You
also
have
the
problem
with
instrumentation,
which
is
the
it
rots
on
the
vine,
because
the
target
is
moving
consistently.
So
every
piece
of
instrumentation
we
take
on
is
going
to
be
a
consis,
consistent
amount
of
future
work.
It's
not
just
the
work
today
and
fixing
bugs
or
adding
features
or
config
options.
J
Here's
how
you
can
add
it
to
the
registry
and
then
sooner
rather
than
later,
come
up
with
a
schema
like
you
were
mentioning
nikita
around
being
able
to
at
least
identify
like
gold,
star
partners,
or
something
like
that.
So
there
at
least
is
a
way
to
identify
the
difference
between
stuff
that
we
think
is
maintained
in
a
way
that
that
we
feel
is
is
reliable
versus
stuff.
J
That
we
think
is
fine,
but
we
just
don't
know
the
people
who
are
offering
it
right,
so
we
just
need
a
way
to
communicate
that
to
the
community
where
that
gets
tricky,
and
this
is
my
last
point-
and
this
is
where
I
think
it's
actually-
the
trickiest
isn't
around
the
registry.
J
It's
easy
enough
for
people
for
us
to
make
this
work
in
the
registry
registry
is
just
a
website
where
this
becomes
tricky
is
actual
discovery
and
installation.
A
lot
of
these
languages
have
some
kind
of
auto
installation
tool,
and
that
is
very,
very
useful
for
end
users.
Any
situation
anytime,
we
can
provide
automatic
installation
of
all.
The
instrumentation
is
a
huge
boon,
especially
to
new
users,
because
that
stuff
is
so
confusing
and
if
you
fail
to
install
some
of
this
stuff
context,
propagation
breaks,
it's
a
silent
error.
J
So,
even
in
the
case
where
stuff
is
being
hosted
by
third
parties,
we
need
to
figure
out
how
we're
going
to
offer
that
to
people
with
our
installation
tools,
and
that
to
me
is
actually
the
crux:
if
we
can
figure
out
a
way
to
do
that
across
languages,
or
at
least
in
each
language,
have
a
way
that
we
feel
is
reasonable
for
people
to
put
things
in
the
registry
or
otherwise
put
them
somewhere
discoverable
or
have
a
way
to
register
it
with
that
auto
instrumentation
and
then
possibly
have
some
kind
of
rule
set.
J
Where
you
can
say
well,
I
only
want
the
core
stuff,
or
I
only
want
the
the
trusted
stuff.
Then
maybe
we've
split
the
difference
between
offering
ease
of
use
and
accessibility
versus
a
kind
of
security
consciousness
and
informing
the
users
about
where
this
stuff
is
coming
from,
but
that's
where
I
think
it's
actually
trickiest.
J
P
But
that
why,
why
is
why?
Do
you
sound
like
this?
Auto
installation
is
very
hard.
I
mean
again
looking
from
java
perspective,
these
auto
installations.
It
just
means
package
manager,
like
main
central
for
jar
file
and
our
auto
instrumentation
java
agent
be
able
to
load
external
jars
runtime.
That's
it.
J
I
I
don't
think
it's
hard
like
in
terms
of
implementing
this
necessarily
in
different
languages.
We
just
have
to
decide
what
we're
going
to
do
right.
It's
it's
straightforward
when
all
the
stuff
that
gets
loaded
up
is
stuff,
that's
in
a
repo,
that's
controlled
by
this
organization.
As
soon
as
we
start
adding
stuff
controlled
by
other
people.
J
That
doesn't
mean
not
installing
this
stuff
for
people,
because
at
the
end
of
the
day,
if
they
need
the
kafka
plug-in
and
the
only
person
providing
the
kafka
plug-in
is
some
untrusted
or
unknown
third
party
they're
gonna
install
that
so
hiding
that
from
people
doesn't
doesn't
do
a
lot
of
good,
but
I
think
that's
just
the
tricky
tricky
wicket
that
is,
whenever
we've
proposed
in
the
past,
installing
third-party
stuff.
That
is
the
the
issue
that
people
bring
up,
so
I
think.
J
Figure
out
what
our,
what
our
policy
is,
if
we're
gonna
do
that,
so
how.
D
About
how
about
this
for
a
policy-
and
this
is
just
one
proposal-
I
need
to
add
it
to
that
doc,
because
it's
for
the
first
chance
I've
had
to
see
it
would
be
for
for
sigs
that
think
they're
they're
underwater
they're
not
able
to
review
contrib
code
right
now.
We
tell
people
keep
it
under
third
party
repo
or,
alternatively,
we
set
up
like
a
contrib
contrib
repo,
that's
basically
the
wild
west,
one
or
the
other
for
sigs
that
are
able
to
keep
track
of.
D
This
like
it
sounds
like
java,
is
then
great,
keep
putting
it
in
contrib
they'll
keep
reviewing
it.
Everything
seems
fine
and
then,
when,
when
thing
when
the
cigs
that
are
currently
underwater
eventually
are
able
to
come
up
for
air,
perhaps
we
take
some
of
those
gold
star
ones
and
and
look
to
bring
them
into
contrib,
because
I
I
do
think
long
term.
We
want
to
have
like
as
many
high
quality
ones
in
the
in
the
main
project
org
or
at
least
under
some
control
of
the
project
as
many
of
those
as
possible.
D
Just
because
then
we
can
maintain
consistent
quality.
We
don't
have
the
issue
where
maybe
somebody
someone
builds
a
really
great
instrumentation
for
like
express
in
javascript
in
their
own
repo
and
everyone
uses
it
and
then
that
person
stops
updating
it
and
stops
merging
prs.
So
now
it
has
to
get
forked
over
here
and,
and
so
like.
I,
I
do
think,
there's
massive
long-term
benefits
to
keeping
this
in
our
house,
but,
as
you
pointed
out
ted,
it
seems
like
for
some
sigs.
That's
a
real
challenge.
Right
now,.
G
Yeah
and
then
the
other
thing
that
is
you
know,
kind
of
the
elephant
in
the
room
is
really
that
the
tc
needs
to
have
more
muscle
in
order
to
be
able
to
support
a
process
of
graduation
from
say.
If
we
had
and
wild
west
contrib,
you
know
org
and,
and
we
wanted
to
graduated,
you
know
specific
components
to
gold
star.
You
know
integrated
in
maine
now.
How
would
that
work?
Because
I
don't
think
that
that
muscle
actually
exists
in
the
tc
today.
J
Yeah,
it
does
feel
like
both
the
tc
and
the
maintainers
are
responsible
for
writing
a
lot
of
code
right
now,
and
if
that
group
of
people
has
to
be
writing
a
lot
of
code
or
the
code's
not
going
to
get
written,
then
that's
what
we
got
to
do
to
get
over
the
1.0
finish
line.
But
that
clearly
means
if
those
are
the
people
tasked
with
writing
the
code
they're
not
going
to
have
time
to
review
other
people's
code
yep.
J
D
D
J
I
don't
think
we
should
have
a
contribution
trip,
just
just
to
be
clear.
Like
the
the
idea
is
like,
should
we
have
a
place
for
people
to
donate
stuff
that
we
are
saying
we
are
not
going
to
maintain
it,
but
it's
going
to
be
in
our
order.
I
don't
we
shouldn't
do
that,
because
it'll
it'll
reduce
maintenance
right.
B
And
maybe
in
my
earlier
proposal
about
influx
data,
writing
one
for
the
you
know
this
exporter
for
open
telemetry.
Maybe
it's
the
organization
influx
data
that
owns
that
subfolder
and
not
you
know
jacob
marvel
that
one's
the
subfolder
something
like
that,
but
but
but
I
just
I
feel
like
getting
something
into
the
open.
Telemetry
contrib,
open,
telemetry,
collector
control
repository
feels
like
a
lot
of
work
and
I'm
confused
by
well.
L
Well,
so
I
think
there's
a
difference,
though,
because
I
don't
think
that
a
lot
of
at
least
coming
from
an
sdk,
we
don't
expect
instrumentation
to
land
in
the
main
repo,
and
I
think
that
there's
probably
some
view
of
that
with
with
the
collector
as
well
right.
There
are
things
that
that
are
not
expected
to
be
part
of
the
core
repository
in
the
core
distribution
and
are
add-ons
or
extensions
for
an
sdk.
I
think
that
line
is
much
clearer.
L
It's
instrumentations
and
exporters
and
propagators
that
aren't
part
of
the
the
specification
for
the
collector.
I
think
that's
a
little
different,
but
I,
I
think
either
way
the
the
point
you
make
about
having
an
organization
that
is
willing
to
sponsor
people
who
are
going
to
maintain
a
subsection
of
the
contrib
repo
is
an
important
one.
As
as
a
maintainer,
I
wouldn't
feel
comfortable
just
saying:
okay,
I'm
gonna,
you
know
push
merge
on
any
pr
that
comes
across.
It's
got,
somebody
saying
yeah!
L
This
looks
good
because
that
feels
like
a
delegation
or
a
an
abrogation
of
my
responsibility
right.
I
have
a
responsibility
to
ensure
that,
what's
in
that
repository
is
quality
and
it's
you
know,
my
name
is
a
sample
of
approval
on
that.
But
if
I
knew
that
there
was
an
organization
who
was
putting
resources
behind
ensuring
that
that
quality
would
be
maintained
for
their
portion
of
it
and
their
name
was
on
it,
I
would
be
much
more
comfortable
having
less
oversight
over
some
portion
of
that
repository.
J
Yeah,
I
think-
and
this
gets
back
to
this
concept
of
trusted
partner
jacob.
I
think
you've
identified
it
very
clearly,
which
is
if
a
group
comes
to
us
and
they
say-
and
it
looks
reasonable
to
us
that
not
only
are
they
going
to
contribute
it
today,
but
they're
going
to
maintain
it
over
time,
and
we
can
trust
them
to
be
the
maintainers,
in
other
words
like
they
have
the
ability
to
push
code
review
other
people's
prs
and
hit
merge
on
the
stuff.
J
If
we
feel
like
like
that's
the
situation,
we're
in,
then
we
should
say:
yes,
absolutely
sign
them
up
quickly
and
give
them
access.
So
that's
more
about
changing
our
community
guidelines
for
those
situations
where
it
becomes
harder
is
the
situation.
That's
that's
less
like
that
and
more
like
people
showing
up
where
they've
written
some
instrumentation
code
or
something,
but
it's
not
clear
to
us
why
or
how
they
would
maintain
it
and
in
those
situations
I
think
it's
better
to
say
you
should
just
continue
to
maintain
it
in
your
own
repo
because
that's
cleaner.
G
Exactly-
and
I
think
today
ted
I
mean
just
to
be
clear-
I
I
really
feel
that
the
registry
you
know
as
hotel
has
it
is
not
adequate,
obviously,
because
of
just
being
disconnected
from
the
you
know,
actual
core
development
org
and
and
unless
we
automate
you
know,
discoverability
and
and
have
a
bot
that
goes
and
looks
for
everything
yeah.
You
know
and
re-updated
goes
and
updates
the
registry
regularly.
That's
not
a
sustainable
model.
G
J
But
it
seems
to
me
we
need
to
do
this
work
because,
no
matter
how
many
contr
contributions,
we
think
we
can
manage,
there's
going
to
be
more,
there's
always
going
to
be
a
set
of
stuff
out
there,
where
we're
gonna,
just
ask
other
people
to
maintain
it
or
other
people
should
have
this
low
bar
to
entry
where
they,
if
they
write
a
thing,
that's
like
we
should
be
an
open
community.
If
someone
writes
something
for
open
telemetry,
we
should
say
right
on.
You
can
list
it
in
the
registry
and
people
can
get
access
to
it.
G
H
J
In
that
relationship
elite,
I
think
that's
where
having
this
some
kind
of
partnership
level,
there
needs
to
be
a
way
for
people
to
filter
out
stuff
or
like.
We
know
that
this
is
well
maintained.
We've
confirmed
that
this
is
going
to
be
well
maintained,
but
I
do
think
there
should
be
a
low
bar
to
entry
just
in
terms
of
growing
the
community
like
if
we
have
that
bar
there
can
be
a
like
someone
just
made
it.
It's
open
source
right
people
make
stuff
for
open
source
all
the
time.
J
Rubygems
lists
all
the
gems
and
doesn't
like
care
about
maintenance.
Node.Js
lists
all
the
things
they
don't.
They
don't
care
about
maintenance.
I
think
we
need
to
have
a
layer
like
that,
so
that
people
don't
feel
frustrated
like
they
came
to
us
with
their
thing,
and
we
just
like
couldn't
get
around
to
dealing
with
it.
Q
Yeah,
I
agree
with
that.
I
think
this
is
very
critical
work
that
needs
to
happen
with
the
registry,
and
then
we
should
really
promote
the
registry
as
much
as
possible
so
like
rather
than
telling
people
oh
look
there
is
this
country
instrumentation
repo,
with
a
bunch
of
like
a
monorepo
style?
Q
No,
don't
look
there
first,
like
look
at
the
register
first,
and
maybe
we
can
automate
stuff
such
that,
like
everything
from
the
monorepo
gets
pulled
into
the
register
automatically
in
case
some
other
new
package,
but
then
people
can
always
add
manual
stuff
to
the
registry
and
then,
as
far
as
the
api
like
api
is
defined,
it's
the
yaml
files
in
the
register
right.
It's
like
everyone
can
consume
them
and
search
them.
G
Yep,
I
agree.
Q
Q
Add
some
sort
of
I
don't
know
certification
to
some
of
the
packages
if
we
want
to
say
like
oh,
yes,
this
is
like
approved
by
hotel
maintainers,
that
this
is
high
quality
and
we
can
give
like
a
gold
star
or
something
to
that
specific
things,
and
then
assignment
of
those
will
be
curated
right.
But
I
agree
with
that.
It
has
to
be
like
low
barrier
to
entry
for
anything.
J
Okay,
well
this
this
is
good
work.
I
think
we
should
move
this
to
that
hotel,
instrumentation
channel.
If
someone
wants
to
write
this
up
as
a
proposal,
I
would
encourage
them
to
do
it,
I'm
going
to
try
my
best
to
stay
on
top
of
this
stuff,
but
I
I
need
help
my
first.
P
D
Okay,
so
move
the
discussion
there
lots
of
good
thoughts
and
we'll
we'll
put
all
these
details
into
the
dock
next
question.
This
was
for
me,
quick
question
are
all
repositories
following
semantic
versioning
I
know
most
of
ours
are.
My
impression
was
that
all
of
ours
are
elena
from
the
cncf
who's
reviewing
open
telemetry
for
movement
to
the
incubation
stage.
I
had
mentioned
that
she
found
ruby
and
I
think
one
or
two
others
that
weren't
and
I
need
to
get
a
response
back
to
her.
G
Yeah
morgan,
I
don't
think
all
all
of
our
reapers
are
following
semantic:
versioning,
okay,.
G
Yep
I
mean
the
ted's
versioning
dock,
you
know
which
was
then
reviewed,
and
you
know
added
to
by
the
me
all
our
maintainers
have
have
requirements
identified,
but
I
don't
think
everybody's
implemented
all
the
requirements
yet.
J
D
G
Yeah
I
mean
maybe
morgan.
We
could
also
state
that
you
know
some
of
the
languages
are
not
at
the
state
where.
D
D
E
D
Okay,
any
other
topics
for
today.
D
D
G
Yep
go
ahead,
morgan,
just
just
a
question
ted.
Is
there
a
need
for
filing
a?
I
think
you
mentioned
in
otep
for
the
registry
improvements.
Should
that
be
something
that
we
formally
work
on.
J
Yeah,
let's,
let's
so
in
that
slack
channel
in
this
project,
doc
it'd
be
great
to
get
ideas
jotted
down
there
and
then
let's,
let's
move
from
that
to
making
an
otep.
D
Alrighty
and
with
that,
I
think
we're
done
for
the
week
or
at
least
for
the
maintainers
meeting.
So
thank
you
very
much
and
we'll
see
you
throughout
all
the
other
sick
meetings.
Later
this
week
see
you
later.