►
From YouTube: 2021-07-01 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).
A
E
I
actually
have
to
leave
this
meeting
in
like
10
minutes
too.
I
have
some
conflict,
but
I
thought
I
at
least
be
here
from
the
beginning,
but
I
hope
we
get
seven
people,
so
we
don't
lose
our
quorum
whatever.
When
I
have
to
drop
so
not
like,
we
have
any.
I
don't
think
we
have
any
critical
decisions
to
make.
C
Good
good
point:
when
what
is
on
the
agenda,
maybe
we
can
even
wrap
up.
I
know.
E
B
No,
I
was
just
it
looked
very
blank,
so.
C
Yeah,
I
was
just
going
to
add
an
update,
a
very
quick
update
on
the
on
the
metrics
on
the
collector
updates,
for
you
know
where
we're
going
with
tracing
ga
and
metrics
thereafter.
Just
wanted
to
give
a
quick
update
to
the
dc.
C
Good,
all
right,
so
just
you
know
to
make
sure
that
everybody
is
tracking
this.
I
have
been
working
with
our
collector
maintainers
closely
to
identify
very
clearly.
C
You
know
what
the
items
for
completion
are
for
stability
of
the
core
collector
api
and
the
core
collector
code
base
for
for
tracing
ga
to
be
announced
or
tracing
stable
release
to
be
done
at
the
end
of
july.
So
this
is
something
that
we
are
tracking
on
and
we
do
have
a
very
clear
backlog
at
this
point,
which
is
let
me
just
share
that
with
with
you
so
that
you
have
that,
and
then
you
can
look
at
that.
C
You
know
I
have
been
working
closely
with
bogdan
and
tigran,
who
are
the
maintainers
to
make
sure
that
we
have
a
clear
delivery
point
and
right
now
we
have
some
two
milestones
that
we
are
tracking
with,
so
just
so
that
folks
can
track.
Everybody
should
be
on
the
same
page.
We
have
a
can.
I
just
share
my
screen.
Maybe
that's
easier
I'll
just
share
my
screen
and
walk
you
through
it.
C
This
is
the
tracing
ga
road
map
phase
one
and,
as
you
can
see
you
know,
bogdan
is
working
on
a
couple
of
these
refactoring
areas
that
are
in
progress
almost
done
and
then
anthony
from
my
team
as
well
as
pony.
I
have
been
helping
on
a
couple
of
these
issues.
So
again
these
are
almost
done
and
then
we
have
phase
two.
C
You
know
of
the
milestones
which
are
in
progress.
There
are
not
too
many
left,
but
we
are
aiming
to
complete
this
by
july
15th
so
that
we
can
actually
build
out
a
do
a
release
on
the
15th
and
then
on
at
the
end
of
july,
and
that
will
land
the
tracing
1.2
to
be
stable.
C
So
we
do
plan
to
communicate
that,
as
in
the
last
part
of
the
1.0
work
that
needs
to
happen
for
tracing
stability,
and
we
have
been
actually
also,
you
know,
having
a
discussion
in
parallel
for
moving
out
some
of
the
components
that
are
for
metric
support
into
contrib
for
the
time
being
and
then
moving
that
back
into
core
as
as
components
stabilize.
C
So,
just
just
for
your
understanding,
you
know
again
that's
a
huge,
fair
bit
of
work
happening
right
now
on
the
collector,
which
is
the
last
part
in
the
tracing
stability
effort
and
and
and
then
the
obviously.
The
second
part
of
this
whole
process
is
to
get
metrics
to
the
point
where
metrics
can
be
done.
C
You
know
also
released
stably
for
the
collector
there's
a
fair
bit
of
work
to
be
done
on
the
collector,
given
the
number
of
receivers
and
processors
and
exporters
that
there
are
there's
a
bunch
of
redesign,
you
know
efforts
where
we
have
we
plan
to
add
engineering,
as
well
as
other
teams
who
are
working
closely
from
other
stakeholders
on
this.
But
it's
it's
a
big
effort
and
we're
hoping
that
you
know
with
the
metrics
work
we
will
be
able
to
land
stable
by
august
end
or
september.
C
You
know
again,
that's
that's
in
line
with
what
the
sdk
metrics
work
is
ongoing
right
now,
the
api,
as
you
know,
on
the
metric
side
as
well
as
the
data
model,
has
already
been
done,
declared
stable.
C
So,
just
just
for
you
all
of
you
to
you,
know
kind
of
have
a
good
understanding
of
what's
what's
in
flight.
So
that's
all
again.
Everything
is
tracked
through
these
backlogs.
So
if
you
want
to
really
track
what's
happening,
I
am
maintaining.
C
E
A
E
This
kind
of
naive
question
I
apologize
for
not
knowing
the
answers
myself
but
like
this
has
been
such
a
moving
goal
post,
it's
starting
to
feel
like.
Maybe
it's
not
moving
as
much,
but
what's
your
confidence
level
in
our
ability
to
stick
to
some
of
the
timelines,
or
I
mean
our
being
the
collective
open
telemetry
product.
Not
just
you
know
you,
but.
C
I
think
I
think
we've
been
you
know
pretty
bad
at
sticking
to
timelines.
So
far,
we've
missed
every
single
goal,
first
that
we
have
set
up
by
at
least
a
month.
If
not,
you
know,
if
not
by
six
weeks
or
so,
but
I
do
think
that
you
know
it
is
a
tangible
and
and
a
measurable
amount
of
work
that
needs
to
be
done.
It's
just
that.
C
I
think
the
project
is
struggling
with
the
balance
of
you
know
enough
maintainers,
we
don't
have
enough
maintainers
in
one
sense,
you
know
to
be
able
to
maintain
velocity
and
we
are
not
graduating
other
engineers
fast
enough
to
become
maintainers.
So
that's
that's
a
struggle
that
you
know
each
all
components
have
in
in
and-
and
you
know,
daniel
being
a
maintainer
of
js
can
attest
to
that
and
and
sega
you've
been
watching
dot
network.
So
you
know
again,
you
guys
have
seen
this,
but
we
really
do.
C
You
know
become
like
a
pyramid
at
the
top
right
there.
There
aren't
enough
maintainers
to
actually
load
be
load
bearers,
and
I
think
that
that
seriously
you
know
slows
down
our
velocity.
C
So,
even
if
we
have
you
know
very,
very
concrete
goal
posts,
we
don't
have
enough,
you
know
load
bearers
if
you
will
in
terms
of
maintainers
on
the
on
on
each
of
these
components.
C
So
the
confidence
level
I
would
say
is,
I
would
say
in
medium
to
you
know,
media
cautiously
optimistic.
I
would
say,
because
I
do
think
we
can
hit
them
and
we
have
been
actually
from
aws,
adding
serious
amount
of
engineering
to
get.
You
know
to
the
1.0,
you
know
for
tracing
so
that
at
least
you
know
there
is
a
1.0
and,
and
then
and
and
and
we
will,
you
know,
announce
thereafter-
a
dot
which
is
aws
distro
for
open,
telemetry
being
1.0
also.
C
C
B
B
So
then,
the
rest
of
these
people
are
some
either
sometimes
active
or
they
used
to
be
active
and
they
haven't
been
around
in
a
while,
and
we
were
just
talking
at
the
last
sig
meeting
about
purging
this
list
because
there's
some
people
that
have
not
been
around
long
enough,
but
then,
if
we
cut
it
down
to
what
six
people,
including
three
who
are
maintainers-
and
you
know,
there's
there's
really
not
a
lot
of
people
to
honestly
approve
prs,
which
is
still
I
say,
that's
our
biggest
bottleneck
and
yeah
that
hasn't
changed.
C
It's
the
same
on
the
collector.
You
know,
I
mean
the
collector.
Is
such
a
huge
conglomeration
of
components
and
we'd
hardly
have
two
active
approvers.
You
know
beyond
the
maintainers
and
there's
we
we
sit
in
weeks
worth
of
backlogs
on
pr's
because
of
yeah.
B
C
C
B
I
can't
make
anyone
do
anything,
but
I
also
can't
promise
velocity
if
I
don't
have
the
bandwidth
to
yeah.
C
Yep
and-
and
that's
exactly
you
know
what
we're
seeing,
because
you
have
an
average.
You
know
30
plus
folks,
joining
it
into
the
sick
discussions
on
the
collector
or
you
know
almost
30
folks,
joining
in
into
the
prometheus
discussions
and
many
of
the
prometheus
community
folks
join
in,
which
is
awesome
because
you
know
they
are
actually
actively
helping
on
stabilizing
the
prometheus
pipeline,
but
again
in
terms
of
folks
actually
rolling
up
their
sleeves,
and
you
know
submitting
pr's
as
well
as
approving
or
just
participating
in
the
development
process.
They're
way
fewer.
C
Folks,
that's
one
of
the
reasons
why
we're
not
being
able
to
guarantee
velocity,
because
you
know
with
the
with
the
maintainers
that
we
have
right
now.
We
just
don't
have
enough
maintainers
to
be
able
to
deliver
at
the
dates
that
we
would
like
to.
E
Yeah,
that's
definitely
the
impression
that
I
mean
that's
how
when
you've
heard
this
before-
and
it
certainly
appears
like
that
would
be
the
case.
It's
given
the
amount
of
activity
and
the
number
of
people
who
are
actually
legitimately
maintaining
is
just
so
small
compared
to
the
level
of
activity.
It's
a
little
bit
like
if
we
had
an
engineering
organization
and
we
hired
a
couple
hundred
people
and
then
have
like
five
managers.
It's
that's
what
it
feels
like
and
it's
really
difficult
to
operate
in
that
in
that
model.
E
Well,
I
have
nothing
to
offer
that
we
haven't
already
discussed,
I
mean
more
maintainers
would
be
good
and
less
scope
would
be
good,
but
I
think
we
just
have
to
say
no
a
lot
more
about
about,
like,
I
think,
a
lot
of
the
what
I
saw
in
the
materials
you
shared
is,
you
know,
trying
to
kind
of
refactor
and
move
things
around,
that
weren't
actually
essential
to
get
to
tracing
ga
yeah,
and
that
was
supposed
to
be
the
priority,
and
I
think
we
just
have
to
continue
to
say
not
yet
to
things.
E
Maybe
that's
better
than
saying
no,
because
we're
gonna
like
just
it's
such
an
unwieldy
thing
that
we're
trying
to
move
around
right
now.
So
I
don't
know.
C
D
I
just
wanted
to
echo
that,
like
I
think
it's
important
to
get
into
ga
because
it
may
be
some
chicken
dynamic
problem,
and
my
question
is
how
much
the
use
you
see
is
individuals
versus
how
much
is
vendors,
adapting
it
for
their
backends
by
ban.
D
C
I
think
I
I
think
there
are
a
very
healthy
number
of
individuals
from
different
customers
or
users
if
you
will,
as
well
as
from
vendors
right
and
and
though
what
is
happening
is
that
you
know
there
is
a
large
gap
between
the
folks
who
are
already
involved
as
maintainers
versus
folks
who
are
just
coming
in
into
the
project
and
figuring
out.
C
A
way
to
you
know,
participate,
get,
started
and
then
contribute
right,
because
there
are
a
lot
of
engineers
who
are
coming
in
and
are
interested
in
participating,
but
one
of
the
things
you
can
also
go
and
see-
and
this
is
why
you
know
everybody
on
the
project
has
to
be
reasonably
hands-on.
C
Is
that
right
now
in
the
phase
that
the
project
is
in,
we
cannot
afford
not
to
be
hands-on.
You
know
there
is
no
position
in
this
project
that
actually
can
afford
to
be
assaulted
and
at
the
same
time
we
also
don't
have,
for
example,
good
fast
issues
on
most
of
our
repos.
We
just
don't
have
enough
triaging
happening
even
in
the
project.
C
You
know
project
repos,
there
are
some
maintainers
who
are,
you
know
actively
take
the
time
to
do
it,
but
by
and
large,
if
a
new
engineer
is
coming
in
like
we're
adding
you
know
10
engineers
to
the
project.
Where
do
they
get
started
because
they
haven't
they're
not
coming
in
as
experts
to
open
telemetry
or
to
observability,
but
they're
good?
You
know,
go
engineers
or
good
javascript
engineers
or
c
plus
plus
engineers
right
and
where
do
they
get
started
right?
So
there
is
that
issue.
Also
and
again
you
know.
C
Maybe
we
need
to
be
a
little
bit
more
proactive
to
see.
Could
we
actually
take
you
know
the
approvers
and
activity
of
approvers,
as
a
measure
of
you
know,
graduating
folks
to
become
approvers
actively,
maybe
roll
folks
off.
If
people
don't
have
availability
for
three
months,
ask
others
to
actually
step
up
and
start
approving
and
and
kind
of
have
that
active
maintenance.
Even
off
of
you
know
those
parts
of
the
process.
C
But
but
sega
I
mean
one
of
the
things
I
would
propose,
though,
is
that
I
think
there
are
a
couple
of
urgent
needs
and-
and
I
would
request
that
you
know-
maybe
we
consider
having
a
group
under
the
tc
or
you
know.
However,
we
want
to
structure
this.
Is
that
having
more
active,
you
know,
discussion
of
tools
tooling,
for
the
project
in
terms
of
standardizing
the
automation.
For
you
know,
integration
deployments,
releases,
security,
scans,
etc,
which
is
infrastructure
right.
D
C
Okay,
because
there
are
a
whole
bunch
of
us
who
are
working
on
that
right
on
the
tooling,
so
this
is
something
that
you
know
given
the
complexity
of
the
collector,
especially
is
being
discussed
very
actively
right
now,
where
you
know
how
do
we
actually
do
separate
out
releases
and
the
flexibility
of
building?
You
know
a
release
from
where
the
code
actually
is
located,
for
example,
right
which
repo
does
it
sit
in
next
yeah
and
and
just
having
a
dependency?
C
You
know
scripts,
which,
which
can
easily
be
reused
for
building
specific
types
of
releases.
So
there
is
a
whole
discussion,
that's
ongoing,
but
it's
not
at
the
tc
level.
It's
not
it's!
It's
not
even
at
the
maintainer
level.
It's
actually
an
additional
group
of.
A
Would
it
help
if
we
maybe
did
like
a?
I
don't
know
like
a
questionnaire
to
someone
like
to
all
the
main
projects
be
like
hey?
What
tooling
do
you
think
is
missing
to
like
make
you
more
effective
and
stuff
like
that?
Like
do
you
think
we
need
more
information
to
figure
out
what
tooling
we
need
to
make
it
some
of
that
stuff
process
easier.
A
C
Figure
out
the
design
yeah
in
terms
of
what
works
and,
and
then
you
know
again,
working
with
maintainers
from
each
each
repo
yeah.
I.
B
Most
of
the
people
that
I
see
that
really
want
to
get
involved
want
to
write
instrumentations
yeah,
that's
that's
what
people
want
to
do
and
when
you
tell
them
well
that
would
be
great,
but
we
need
this.
They
say
well,
I'm
going
to
write
an
instrumentation
and
they
don't
work
for
me
and
I
can't
make
them
do
anything.
So
I
you
know
I
say
thanks
and
they
move
on
and
that's
that.
C
Yeah
exactly,
but
I
mean
there
are
also
other
folks
who
are
interested
in
it.
You
know
I
mean
I've
worked
actively
on
all
the
building
out,
all
the
github
workflows
for
every
repo.
So
you
know
we've
got
to
do
all
this
stuff
in
order
to
make
sure
that
we
have
security
scans.
We
have
you
know
ci
cd
and
everything
standardized
over
time.
Right.
C
No
totally
and-
and
you
know
it's
just
that
they
all
like
we
have
made
it
a
point-
that
anything
that
we
can
do
on
that
layer
which
is
easy
to
go
after,
and
you
know
kind
of
build
out
proposal
design
and
build
it
out.
It's
it's
valuable
to
the
project
so
that
matters,
but
my
point
being
that
tooling
is
important
and-
and
you
know
it
really
helps
in
maintaining
velocity-
and
you
know
our
maintainers
not
having
to
do
all
this
heavy
lifting.
D
B
That
would
be
really
helpful
for
me,
but
there
is
you
know
I.
I
hope
that
we
have
enough
people
that
are
interested
in
doing
work.
On
that
I
know
some
people
have
worked
on
it
in
the
past,
but
I
don't
know
if
enough
people
are
willing
to
work
on
it
every
week
to
have
a
work
group,
but
if
you
think
that
that
there
are
people
there,
then
I
would
be
fully
in
support
of
that
yeah.
C
I
mean
what
what
I
was
thinking
of
so
I
discussed
this.
Obviously
with
you
know,
I've
discussed
it
with
the
collector
maintainers
with
the
go
maintainers
because
that's
you
know
an
area
that
we
are
working
on
right
now,
but
I
have
also
discussed
it
with
the
maintainers
at
the
maintainers
meeting
and
and
what
we
were
thinking
of
is
so
there
is
jurassie
anthony
from
my
team
me
and
then
there
are
other.
C
You
know
folks,
who
are
working
on
the
home
charts
the
operators,
the
builder
tools
you
know
who
are
who
have
been
working
on
this
area,
so
kind
of
pulling
everybody
on
just
regular
design.
You
know
discussions
for
you,
know,
building
these
tools
out
and
at
the
same
time,
then
reporting
back
into
the
maintainers
meeting
on
mondays
to
you
know
again
make
sure
everybody
is
all
maintainers
are
on.
You
know
aware
of
what's
what
is
ongoing
and
then
working
with
each
maintainer
group
to
you
know
in
instrument
on
each
repo
right.
C
C
B
Yeah.
Thank
you.
Let's
move
on
to
sergey's
thing,
because
we
only
have
five
minutes
left
and
I
do
have
stuff
sorry.
D
Worries
so
flow
meal
contributions.
It
is
a
technical
due
diligence
document.
We
discussed
it
on
gc
meeting
yesterday.
I
like
yuri,
already
support
like
I
feel
like
formally
sign
up
for
this,
and
I
believe
we
have
more
people
who
agree
with
this
assessment.
D
There
is
a
summary
on
on
the
bottom,
so
right
now
what
happened
is
datadog
just
replied
back
that
they
want
to
discuss.
So
I
may
hold
off
on
like
making
this
decision
like
a
suggestion,
gc
to
make
a
decision.
So
maybe,
after
day-to-day
conversations
will
happen,
we
can
proceed
but
the
main
point
of
our
technology
due
diligences.
There
is
a
big
question
with
flowmill
collector
and
backhand.
D
They
suggest
to
use,
and
we
really
looking
for
somebody
who
will
step
up
and
start
contributing
beyond
colomeo,
otherwise
changing
communities
don't
believe
we
can.
We
can
make
sure
that
whole
meal
contribution
will
be
vendor
neutral.
C
Yeah
and
sega
I
mean
again,
we've
also
from
aws,
been
evaluating
flo
mill
and
definitely
you
know,
are
interested
in
contributing.
The
question:
is
you
know
again
having
an
active
and
clear
design
path
on
how
to
maintain
a
neutral?
You
know
otlp
based
interface,
for
you
know
being
able
to
work
with
any
other
any
back
end
and
make
it
vendor
agnostic.
D
D
Okay,
I
mean
the
issue
is
that
the
formula
collector
is
very,
produces
a
lot
of
data
and
this
data
really
useful
if
you
have
a
back
end
with
lots
of
features-
and
this
feature
needs
to
like
massage
this
data
and
present
in
the
right
way.
Suggestion
is
to
have
an
extra
component
created
that
will
do
the
same
like
similar
data
processing
on
agent
side,
but
mine
is
saying
that
whole
meal
team
doesn't
really
need
this
component.
D
They
will
just
propose
to
build
it
to
make
open
telemetry
and
we
need
to
find
somebody
who
actually
will
become
happy
with
this
tool
or
use
this
component.
Otherwise,
how
do
you
know
whether
it
is
vendor
neutral,
just
something
that
barely
can
be
used.
C
D
D
C
D
Are
two
more
prerequisites
that
we
recommend?
First
is
trademark
flow
milk
is
a
registered
trademark
for
splunk.
We
want
to
either
transfer
it
or
do
something
like
rename
it
plus
we,
this
technical,
due
diligence
isn't
like.
We
compared
it
a
little
bit
with
pixie,
but
we
didn't
make
deep
comparison
and
we
don't
make
any
suggestion
was
what's
better
in
long
term.
So
if
we
accept
this
donation,
we
need
to
make
it
clear
from
end
users
that
by
picking
flow
meal
we
don't
make
a
recommendation
or
definitive.
C
Yeah,
that's
very
important
to
communicate,
because
I
think
that
it's
very
easy
to
actually
create
confusion.
You
know
in
terms
of
why
only
flowmail
versus
you
know
the
other
ebpf
solutions
which
are
different
projects
are
working
on.
I
mean
there
are
at
least
two
others,
including
pixie.
D
We
don't
have
any
timeline,
so
I
mean
from
gc.
We
need
to
either
accept
the
donation
or
not
accept
this
donation
like
postpone
it
or
like
decline.
Completely
technical
media
just
gave
a
recommendation
and
technical
details.
C
Okay,
okay,
all
right
cool,
so
maybe
we
can
I'll
definitely
get
back
to
the
gc,
and
then
we
can
figure
out.
You
know
what,
when,
when
it
lands,
because
there
should
be
some
communication-
also
around
this-
which
the
dc
does.
B
I
have
a
quick
question
about
this
document.
You
have
contributor
sergey,
signed
off
by
yuri
that's
in
your
capacity
as
tc
members
right
not
at
that
you're
not
asking
for
gc
to
sign
off
on
it,
you're,
just
making
sure.