►
From YouTube: 2021-04-22 Governance Committee private 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
no
problem
at
all-
hopefully
it's
merged
soon!
I
I
haven't
looked
at
it
yet
this
morning,.
A
B
A
A
I
am
trying
to
figure
out
how
to
get
the
0
19
release
candidate
that
you
have
going
into
my
app,
so
I
can
test
it,
but
that
turns
out
to
be
hard.
A
It's
it's
merged
and
released.
B
A
C
B
Sorry
I
missed
the
meeting
last
week
without
warning.
I
should
have
sent
you
guys,
an
email
and
I
didn't
remember
until
it
was
already
too
late.
B
B
E
Yeah,
it's
a
minor,
so
we
want
to
in
dot
net
3.3.
We
have
google
exporter
and
we've
been
thinking
to
move
it
to
a
google
org,
and
I
wonder
if
we
can
change
copyright
back
to
google
from
open
telemetry
authors,
I
don't
know
like
I
think,
open
telemetry
and
has
a
like
cla
that
allows
to
change
copyright
whatever
they
want.
So
I
like,
I
wonder
why
I
need
to
ask
permission
to
change
this:
copyright
back
to
google
or
like
scrum
to
copyright.
C
I
think
I
think
I
mean
in
the
past,
I've
at
least
had
to
reach
out
to
cncf
to
just
you
know,
make
sure
that
they're
aware
of
it.
You
know
for
any
copyright
changes,
but
in
general
right
now
it's
all
hotel
authors
right
for
any
any
code
that
is
on
you're,
hosted
on
hotel
repos.
F
True
for
some
of
the
files
we
do
have
the
initial
open.
F
D
D
D
C
D
But
sergey
I'm
curious:
why
do
you
want
to
move
the
the
exporters
out
of
open
telemetry.
E
This
is
a
discussion
right
now
and
I
think
one
of
the
reason
is
to
make
sure
that
we
can
provide
proper
guarantees
on
this
expert.
That's
my
understanding
right
now,
but
I
know
I.
A
I
can
speak
to
our
experience
with
honeycomb
as
to
why
we
kept
the
honeycomb
exporter
out
of
the
hotel
contributors
and
the
reason
was
we
wanted
to
be
able
to
move
faster.
Potentially,
we
didn't
want
people
to
have
to
sign
the
cla
if
they
wanted
to
contribute
right
like
because
we
weren't
intending
to
bundle
it
right,
because
you
can
just
dynamically
link
it
in
okay.
E
Yep,
I'm
pretty
much
this
reason,
but
I
don't
know
like
I
don't
see
big
problem
with
that,
but
maybe,
like
exporter
supposedly,
will
be
quite
stable,
going
forward
and
eventually
you'll
all
move
to
otlp.
So
it
wouldn't
be
needed
at
all.
So
I
don't
know
like
whether
you
want
it.
But
if
you
wanted,
I
probably
need
to
just
create
a
ticket
with
cncf
and
ask
them.
C
Yeah
yeah,
I
mean
that
would
be
the
first
step,
but
again
so
I
can
tell
you
you
know
we,
we
deliberately
added
the
aws
exporters
into
open
telemetry,
because
we
wanted
everything
to
be
under
the
same
umbrella,
even
though
we
maintain
it
and
and
the
pace
of
merging
code
and
reviewing
code
is
slower.
But
you
know
again
it's
just
unifying
everything
under
one
umbrella
until
we
have
a
good
discovery,
you
know
on
the
project
for
finding
the
different
components.
C
So
that's
the
counter
argument,
for
you
know
why
you
would,
rather,
you
know,
support
the
project
and
keep
things
under
one
umbrella.
But
again
that's
just.
That
was
just
the
initial
assumption.
C
E
Maintain
repository
right.
C
D
C
Sega
is
it?
Is
it
just
that
you're
you
guys
are
also
looking
at
velocity
as
well
as
the
guarantees,
as
you
said,
or
is
that
something
that
yeah.
E
I'm
trying
to
understand
what
team
decided
it
just.
I
wasn't
part
of
this
discussion,
but
I
want
to
clear
up
the
possibility
of
that
like
if
we
can
move
with
that.
Thank
you.
D
G
Yeah
I
mean
I
was
this
came
up
during
one
of
those
diligence
like
incubation
things,
but
I'm
just
curious.
I
mean
I
I
wasn't
there
when
we
decided
that
the
tagline
would
be
an
observability
framework
for
cloud
native
software.
G
I
don't
like
that
tagline,
I
think
it's
incredibly
misleading
like
this
is
just
the
whole
point
is
that
telemetry
is
like
just
the
ingress
to
observability
and
I
think
it
produces
confusion
and
probably
some
like
actual
fud
from
other
projects
that
are
like
wait
but
we're
doing
observability.
It's
like
really
open.
Telemetry
is
not
an
observability
project.
It's
a
telemetry
project,
so
I
mean
I'm
happy
to
have
the
debate
about
the
tagline,
but
in
as
much
as
people
agree
with
that.
G
Like
I
mean
I
guess
the
short
question
is
like:
can
we
change
it
and
then
the
second
question
is
like
how
do
we
change
it,
which
is
probably
like
the
bigger
one?
And
then
this
really
just
ties
into
like?
I
don't
think
we
have
like
a
concise
mission
and
vision
statement
that
we've
actually
signed
off
on
as
the
gc
I
don't
mean,
like
the
full,
like
three
page
doc.
G
I'd
actually,
rather
it's
just
like
one
sentence
mission,
which
is
kind
of
what
I'm
talking
about
here
and
then,
like
maybe
a
short
paragraph
of
a
vision
for
what
we're
trying
to
accomplish
over
the
next
several
years
and
like
I
just
don't
think
that
we've
gotten
that
over
the
line
either,
which
is
making
it
hard
to
come
up
with
the
tagline.
So
that's
a
lot,
but
I
just
that's
the
topic.
I'm
open
to
feedback
about
how
to
proceed.
I
guess.
D
D
I
do
agree
that,
like
coming
up
with
this
as
the
gc
and
then
going
over
to
the
communication,
sig
or
just
opening
an
issue
there
and
saying
like,
but
you
know,
we've
come
up
with
a
mission
statement
and
a
tagline
we'd
like
to
change
would
be
better
than
trying
to
bring
it
up
in
the
communications
sig.
Frankly,
yeah.
G
Should
reverse
these
bullets?
Like,
I
don't
think
we
finished
the
mission
vision
thing.
I
think
it
got
scope
creeped
into
a
much
longer
thing
that
I
don't
actually
think
we
need
to
do
right
now,
but
I
would
argue
that
it's
actually,
we
really
need
to
have
it.
For
the
incubation
stuff,
I
mean
in
my
mind
anyway,
it'll
make
it'll
clarify
I'll,
clarify
and
I'll
put
to
rest
a
lot
of
potential
concerns
about
the
project,
but
like
that,
tagline
is
exactly
the
sort
of
thing
that
would
give
people
concerns
about
conteleventry.
G
I
think
in
terms
of
scope.
So
so
I
guess
I'm
suggesting
that
we
actually
do
that
exercise.
I'm
happy
that
I'm
not
saying
I'll
write
the
thing
by
fiat,
but,
like
I'm
happy
to
like
run
the
exercise
to
like
do
the
mission
vision
thing
in
public
or
whatever
I
think
the
gc
should
should,
like
you
know,
vote
on
it
and
and
whatever,
but
would
that
be
helpful?
Any
objections,
that's
the
question.
D
Do
we
want
to
like
plan
on
like
using
our
next
gc
meeting
to
to
take
something
you
wrote
or
do
you
have
a
different
idea.
G
I
I
would
propose
that
we
I
mean
I'm
open.
I
actually
honestly
had
just
from
the
experience
of
doing
the
lifestyle
version
of
this,
like,
I
think
the
process
that
ended
up
actually
working
was
like
kind
of
a
call
for
call
for
missions
and
visions
from
you
know,
whoever
and
then
to
put
them
all
in
in
a
place
like
you
know,
give
people
a
chance
to
look
at
them,
maybe
rewrite
their
own
based
on
what
they
see
and
then
and
then
do
kind
of
an
anonymous
poll
on
what
resonates
with
people.
G
And
then
the
gc
can
like
have
final
can
can
make
the
final
decision,
but
I
don't
mind
for
the
the
except
for
that
last
part.
I
think
it's
appropriate
to
do
it
in
the
open
just
on
github
and
docs
and
stuff
like
that,
and
then
and
then
the
gc
just
gets
to
make
the
decision.
But
that's
what
I
propose.
I
think
if
we
try
to
talk
it
through
a
half
an
hour
meeting,
it's
going
to
be
difficult
to
to
like
it's
just
going
to
be
loudest,
wins
kind
of
thing.
A
G
Let's
try
to
get
it
done
before
incubation.
How
about
that
like?
I
don't
think
it
needs
to
be
done
tomorrow
or
something
but.
C
Sounds
good,
I
also
sorry,
so
I
just
wanted
to
quickly
give
an
update
on
the
incubation
process
selena.
I
chatted
with
her
yesterday
and
she
mentioned
that
you
know
they
hadn't
made
good
progress.
They're
almost
done
with
all
the
interviews,
so
we
should
be
reviewing
the
talk
once
more
to
make
sure
all
the
answers
you
know,
questions
are
answered
so
just
a
request
to
everybody
to
take
a
look
at
the
incubation
off
again
and
if
there
are
any
answers
you
guys
can
provide
I'll.
Also,
you
know
I've
also
been
looking
at
it.
D
Yep
cool:
is
there
a
link
link
to
any
of
that?
Where
do
we
find
it.
C
D
G
Hopefully,
everyone
will
like
do
something.
I
think
just
the
process
itself,
just
defining
what
that
is.
C
G
C
D
C
G
H
C
Not
see
any
issues
and
also,
as
you
did
see
for
those
of
you
who
are
tracking
the
the
ncf
incubation
process
issue,
the
the
toc
has
been
changing
the
process
and
streamlining
it,
but
just
fyi.
You
know
it
did
help
in
in
streamlining
the
process
further
and
also
just
you
know,
taking
more
responsibility
for
different
parts
of
the
process.
C
J
Is
there
a?
Is
there
any
update?
Okay?
Last
time
we
discussed
this,
I
think
ted
and
morgan.
We're
gonna
talk
about
that
at
the
maintainers
meetings
and
see,
if
there's
a
sort
of
like
proposal
to
to
do
something
about
it.
In
discussing
the
public
issue,.
C
Yuri
I
can
give
an
update
on
that.
I
mean
there
was
a
discussion
in
the
maintainers
meeting,
but
I
think
what
needs
to
be
done
is
having
more
of
a
formal.
You
know,
proposal
right
and
and
then
having
a
discussion,
because
there's
no
there's
no
strong
consensus.
B
B
C
D
The
the
core
issue
is:
if
the
core
maintainers
don't
have
the
bandwidth
to
manage
those
repos
who's
going
to
own
him
right
and
how
do
we
find
those
owners
essentially.
A
Yeah
one
thing
that
we
have
not
necessarily
done
is:
we
have
not
necessarily
done
code
ownership
for
parts
of
the
code
base.
Right
like
we
can
delegate
you
know,
maintaining
the,
for
instance,
express
integration
to
some
people
who
are
more
familiar
with
express
without
giving
them
everything.
B
B
No,
the
code
owners
on
github
doesn't
work
unless,
in
order
to
mark
someone
as
a
code
owner,
they
have
to
have
right
access
on
the
repo.
So
if
somebody
only
owns
the
express
instrumentation
or
something
like
that,
then
they
have
to
have
right
permission
for
the
full
repo.
C
B
As
an
example,
log
stash,
I
know,
has
they
created
an
entirely
separate
org
called
logs
plugins
and
they
create
a
repository
per
plug-in
with
a
different
ownership,
and
they
did
that
specifically
to
work
around
this
issue.
C
D
Yep
yeah
there's
just
an
issue
of
of
meta
maintenance,
which
is,
we
would
accept
things
into
open,
tracing
contrib
and
then
in
some
cases
you
have
maintainers
and
they're
doing
a
fine
job.
Okay,
in
other
cases,
those
maintainers
just
disappear,
or
people
are
posting
issues
and
they're
not
really
responding
to
it,
so
that
so
the
situation
hasn't
improved
and
there
wasn't
really
like
a
fallback
mechanism,
we're
gonna
brand
this
stuff
as
open
telemetry.
I
think
that's
just
that's
the
rest
of
this
is
fine
and
I
think
it's
straightforward.
C
A
There
are
two
reasons
why
it
matters
for
things
to
be
in
the
open,
telemetry
repos.
The
first
reason
is:
it
enables
bulk
updating
right
like
if
we
release
a
new
api,
a
new
api
or
sdk
rev,
to
make
it
automatically
use
the
the
latest
api
rev.
If
it's
scattered
across
multiple
repos,
it's
a
lot
harder
to
do
that
right.
So
we
are
trading
off
a
lot
different
panes
here.
G
Yeah,
I
I
just
did
less
compelled
by
the
second
argument.
Liz
I
mean
not
that
the
mission
shouldn't
be
high
quality
telemetry,
but
there's
nothing
to
suggest
that
I
don't
know
it
doesn't
really
matter,
but
that,
like
amazon,
couldn't
host
high
quality
telemetry
on
amazon's,
github
repos,
or
something
like
that
I
mean,
if
or
or
whatever
I
mean,
that's
just
an
arbitrary
example,
but
I
mean
there's
nothing
about
high
quality.
That
forces
us
to
host
it
ourselves
and
I
think,
like
we
could
address
that.
G
I
think
more
scalably
by
having
different
levels
of
validation
or
verification
for
the
quality
of
telemetry
that,
hopefully,
can
even
be
automated.
I
know
white
stuff's
done
a
bunch
of
stuff
with
instrumentation
quality
reports
and
things
like
that
where
we
automate
the
process
of
assessing
instrumentation
quality.
I
think
that's
a
much
better
solution
than
having
all
the
telemetry
centralized
all
the
instrumentation,
centralized
and
repos
that
we
have
to
maintain
because
yeah
I.
A
D
Yeah
and
providing
tooling,
I
think
it's
going
to
really
help
it's
just
that
we,
you
know
we
we
can't
just
make
this
thing,
go
out
of
sight
out
of
mind
like
it's
critical
to
to
make
this
work,
and
I
would.
G
Almost
say
it's
sort
of
that's
essential
too,
because
the
the
critical
path
resource
for
open
telemetry
are
the
maintainers.
As
I
understand
it
right
now,
and
they
are
literally
underwater
and
part
of
the
problem
is
that
they
have
to
maintain
contribute
and,
like
I
mean,
I
think
we
would
be
better
off
in
my
mind
anyway.
G
Just
I
mean
I
mean
this
is
easy
for
me
to
say
this:
I'm
not
going
to
be
able
to
do
the
work
but
like,
but
I
think
just
saying
like
there
is
no
working
we're
not
doing
contrib
and
we're
not
doing
anything
like
contrib
in
our
repos.
We're
using
the
registry,
we're
using
github
tags
to
discover
things
that
are
open,
telemetry
compliant
to
get
it
into
the
registry,
and
the
only
thing
in
open,
telemetry
post
is
stuff.
G
That
has
to
be,
which
is
to
say,
like
things
that
you
know
are
part
of
the
spec
or
are
co-dependent
with
the
spec
or
whatever.
And
then
we
push
everything
out
to
the
sort
of
diaspora
of
github
and
wash
our
hands
of
it.
Just
from
a
bandwidth
standpoint,
because
I
I'm
worried
about
the
maintainers
just
already
being
run
out
of
time,
so
I
mean
that's
a
sort
of
a
strong
point
of
view,
but
I
would
be
perfectly
happy
if
they
got
that
point.
Then.
D
It
just
runs
into
a
bunch
of
issues,
though,
which
is
open.
Telemetry
only
works
if
we
can
install
this
stuff,
and
so
if
we
just
make
the
diaspora
with
no
rules
or
anything
understanding
about
like
how
is
like
our
auto
installer,
going
to
install
this
like.
How
does
this
stuff
get
installed
in
python
like?
How
does
that
discoverability
mechanism
work?
How
do
we
define
trust
to.
G
Understand
you're
saying,
I
think
what
I'm
trying
to
get
at
is
that
sorry?
This
is
the
thing
that's
missing
my
statement.
If
we
decide
the
maintainers
the
open
telemetry,
like
the
the
official
maintainers,
the
project
level,
don't
have
to
vet
this
stuff,
I
think
we're
fine.
It's
I
think,
I'm
assuming
that
we're
coupling
that
to
being
part
of
our
organization
if
there
is
a
place
where
that
those
decisions
could
be
pushed
to
the
people
doing
the
work,
and
there
wasn't
this
dependency
on
this
like
scarce
resource.
A
My
viewpoint
is
that
the
maintainers
should
be
responsible
for
kind
of
release
management,
but
I
think
that
you
know
if
someone
wants
to
make
a
contribution
to
instrumentation
right
like
I
think
that
it
should
be
fine
to
proceed
with
that
without
them.
Containers
yeah.
A
Let
us
talk
about
the
problems
that
we're
trying
to
solve,
and
then
let
us
look
at
potential
solutions
right
like
I
worry
that
we
are
jumping
as
a
solution
of
kick
out
everything
out
of
the
hotel
org,
without
necessarily
defining
the
problem,
seeing
whether
there
are
less
disruptive
ways
of
doing
it
first.
So
well,
nobody
agreed
with
me
anyway,
so
it's
all
good,
I
mean,
but
I
think
you're
right
liz.
C
D
There
is
like,
I
think,
a
a
core
basic
path
that
I
think
is
emerging
from
talking
to
the
maintainers
and
the
people
in
the
instrumentation
group,
and
if
people
want
to
help
draft
this
statement,
we're
looking
for
people
to
help
so
please
come
say:
hi
that
hotel
instrumentation
channel
but
like
if
we
can
just
like
there.
The
fact
is,
we
probably
can
get
people
to
maintain
some
of
this
core
instrumentation
that
we
think
is
important.
D
It
shouldn't
be
the
core
maintainers
and
the
core
maintainers
were
fine,
with
handing
that
permission
out.
Broadly
speaking,
we
were
just
honestly
just
blocked
by
code
owner
sadness,
and
so
it's
just
a
question
of
taking
what
is
essentially
contrib
right
now
and
unfortunately
having
to
explode
that
into
a
bunch
of
repos
or
using.
D
A
Right,
like
we
can
figure
out
financial
solutions.
I
think
the
other
interesting
thing
is
the
qualities
that
make
someone
a
good
maintainer
of
the
core
stuff
do
not
necessarily
translate
to
being
a
maintainer
of
the
contrib
stuff,
and
vice
versa.
Right,
like
I
imagine
that
all
of
us
who
work
at
vendors
like
have
a
ton
of
sales
engineers
who
would
love
to
like
work
on
these
things,
but
would
not
make
for
good
maintainers
for
the
core
repo
yeah
yeah,
the
maintainers
are.
D
A
C
D
D
A
D
Mandate,
like
the
whole
reason,
open
tracing
was
created,
and
this
project,
as
well
partially,
was
to
like
solve
this
instrumentation
issue
of
everyone
having
to
deal
with
it.
So
so
we
do
have
to
figure
it
out.
The
one
problem
is
that
just
the
maintainership
of
this
stuff
we
found
in
open
tracing
is
just
a
little
bit
different.
You
don't
tend
to
get
people
who
are
necessarily
invested
in
the
long
term
to
maintain
this
kind
of
stuff.
D
The
way
other
open
source
projects
tend
to
be
somebody's
baby,
like
this
instrumentation
stuff
is
kind
of
like
tends
to
be
nobody's
baby,
so
there's
just
some
higher
level
management
of
just
keeping
track
of
which,
which
ones
actually
like
have
contributors
and
like
have
people
owning
them
and
and
which
ones
don't
like.
We
just
found
this
with
open
tracing
right,
is
that
people,
even
people
who
are
willing
to
do
it
for
a
time
like
they're?
D
G
D
Right,
that's
where
like
testing
infrastructure
and
and
making
it
more
turnkey
helps
new
maintainers
show
up.
D
So
there
is
this
hotel.
Instrumentation
group
nikita
has
been
working
on
a
proposal
if
people
want
to
help
draft
a
proposal
for
like
how
to
re-split
out
contrib
and
like
how
to
like
just
nuts
and
bolts
how
to
manage.
That
is
helpful.
That
would
be
a
helpful
proposal
to
for
somebody
to
draft,
so
I
would
say
like
that,
is
great,
and
then
finding
people
who
are
willing
willing
to
maintain
this
stuff
is
the
other
thing
like
the
sooner
we
can
get
cooking
on
that
the
better.
D
Around
just
general,
like
concept
of
like
how
should
we
be
managing
this
stuff,
but
also
from
the
perspective
of
like
third-party
stuff
as
well
like
there's,
also
this
broader
question
of
how
do
our
auto
installers
and
all
that
stuff
work
with
with
things
that
are
going
to
be
hosted
elsewhere.
C
D
Yeah
yeah
do
me
a
favor
and
maybe
have
that
conversation
that
hotel
instrumentation
channel
just
so
people.