►
From YouTube: 2021-08-18 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
B
Hey
amir
before
the
meeting
starts,
since
it
doesn't
really
affect
anyone
else,
your
pr
for
upstreaming,
the
testing
utilities.
A
B
But
it's
not
the
permissions
issue.
That
was
originally
like
the
note
16
hoisting
pr
had
like
a
permissions
problem
before
and
it
just
seems
like
it's
a
different
issue.
D
E
E
B
B
Okay,
first
thing
I
want
to
mention
is
the
automated:
releasing
with
release
please
for
those
that
don't
know
you
can
see
an
example
of
what
the
prs
will
look
like
here.
The
files
that
are
changed.
B
One
of
the
big
differences
is
that
change
logs
are
now
per
package,
so,
instead
of
having
one
big
change,
log
in
the
root
will
have
change
logs
on
individual
packages,
but
other
than
that,
it's
all,
basically
the
same
as
what
we're
used
to
seeing.
But
it's
automated.
B
We
will
probably
want
to
talk
about
how
to
keep
at
least
the
sdk
packages
all
locked
together,
but
in
general
this
is
what
they
look
like
for
now
we're
waiting
on
the
easy
cla
exemption
liz
opened
a
support
ticket
with
the
cncf,
but
we're
still
failing
the
cla
checks.
So
we
can't.
C
B
To
merge
releases
yet
so,
for
now
I
created
a
manual
one
yesterday,
so
this
is
for
version.
25
of
the
core
repo
contains
many
changes,
so
please
take
a
look
at
it
and
once
we
get
it
merged,
we
will
also
release
the
contrib.
B
Yeah,
oh
yeah,
speaking
of
faster,
thank
you
to
amir
and
your
co-worker,
whose
name
I'm
not
remembering
for
speeding
up
the
contrib
builds.
That
was
a
huge,
huge
win
for
us
and
I
basically
just
copied
your
work
into
the
main
repo
too,
so
they're
both
much
much
faster
and
we
we
appreciate
that.
B
I
did
want
to
say
congratulations
to
the
various
component
owners
that
we
have.
A
handful
of
people
have
stepped
up
to
maintain
some
of
our
packages
and
I'd
like
to
say
thank
you
to
those
people.
I've
listed
everybody
here
so
far,
that
is
in
the
component
owners
file.
That's
in
maine
right
now,
but
there's
at
least
one
more.
That
rano
is
contributing,
I
believe
the
nest
instrumentation.
B
So
this
last.
This
list
is
starting
to
grow
and
thank
you
to
those
that
have
stepped
up
in
the
same
vein
as
the
component
owners.
I'm
looking
for
someone
to
help
me
to
co-maintain
the
github
action.
B
We
moved
it
over
to
open
telemetry.
So,
instead
of
being
in
my
personal
repository
or
my
personal
github
user,
we're
going
to
control
it
underneath
the
open
telemetry
organization,
but
as
part
of
that,
I
need
at
least
one
other
person
to
be
a
maintainer,
because
I
can't
review
my
own
pr's
and
I
can't
merge
anything
without
a
review.
B
Okay,
perfect
and
if
anyone
else
wants
to
work
on
that
all
are
welcome
for
now.
I
guess
part
I'll
contact
the
tc
and
let
them
know
that
you
and
I
will
be
the
maintainers
of
that.
B
I
don't
expect
it
to
be
a
lot
of
work
or
anything
like
that.
Once
it's
done,
I
don't
think
there
will
be
too
many
changes
with.
F
Regards
to
github
actions
just
think
about,
I
think
one
extra
action,
but
this
is
something
you
can
discuss
like
if,
if
anyone
false
push
revoke
all
approve
so
accidentally,
nothing
is,
being
you
know,
injected
without
noticing
anyone,
because
if
you
force
push
it's
hard
to
see
what
was
strange.
B
Also
in
a
similar
thing,
I
know
we
talked
about
this
last
week
a
little
bit,
but
I
did
want
to
get
an
explicit
set
of
rules
for
owners
down
and
what
does
ownership
mean
so
I've
written
a
few
things
down
here,
but
I
want
everybody's
input
on
it.
These
are
not
just
I'm
not
just
gonna
make
the
rules
and
tell
everybody
that's
what
the
rules
are
unless
you
want
me
to,
but
this
is
sort
of
you
know
a
base
for
discussion
here.
B
I
think
what
we
talked
about
last
week
was
one
owner
from
each
like
owned
component
must
approve,
I
think,
we're
all
still
happy
with
that
right.
Are
we
going
to
require
an
additional
reviewer
or
not?
So
if,
if
a
component
owner
reviews
and
says
yes,
should
we
just
merge
it
or
should
we
wait
for
any
other
reviewer?
F
I
mean
I
would
rather
like
to
avoid
the
situation
when
someone,
for
example,
fix
something
two
hours
later,
it's
approved
advantage,
and
just
considering
you
know,
that's
that's
so
I
would
say
like
wait,
24
hours,
so
everybody
can
see
in
the
respective
time
zones
and
then
match
it.
So
at
least
it
would
be
some
visibility
for
people
you
know
to
step
in
and
maybe
maybe
they
see
something
that
you
know
yeah
you
didn't
see
for
yourself
yeah.
C
I
I
see
where
that's
coming
from.
However,
I
would
not
support
the
idea
per
se
because,
because
we
kind
of
pre-approve
the
owners
so
the
so
we
they
are
already
like
trusted
maintainers
for
those
packages.
C
F
I
mean
we
have
the
same
movement
as
a
maintainer.
In
theory,
we
could
do
like
create
something
wait
for
a
proof
method,
but
I
always
tend
to
to
like,
let's
say,
keep
some
pr,
I'm
not
talking
about
some
some.
You
know
typo
or
anything
like
this,
but
if
there
is
a
change
that
can
influence
something
just
keep
it
for
like
24
hours,
so
you
know
someone
can
see
and
spot
something,
because
I
mean
we
just
humans.
F
We
do
all
that
bugs
and
it
would
be
quite
inconvenient
to
basically
match
something
quickly
and
then
you
know
some
people
will
be
affected
by
this
one
I
mean
in
the
end
there
will
be
more
and
more
companies
that
are
using
this
one.
So
I
mean
it
doesn't
really
harm
if
we
can.
No,
unless
this
is
like
urgent
fix,
that
really
needs
to
be
pushed,
because
I
don't
know
that
there
is
a
company
that
is
dying
because
of
this
particular
bug.
F
C
Yes,
as
a
soft
rule
or
a
guideline,
I
would
support
this,
but
not
that's
a
hard.
A
Me,
too,
I
think
that
we
should
at
least
keep
the
option
to
to
merge
something
urgent
quickly
like
if
there
was
an
undefined
exception,
is
their
throne
and
crushes
the
applications
or
something,
and
we
need
to
fix
it
fast.
A
F
F
If
it
is
for
some
time,
and
you
know
if,
if
there
is
a
bug
obvious,
then
then
then
of
course
you
want
to
fix
it,
and
so
this
is
understandable,
but
I'm
talking
about
the
situation,
that's
you
are
changing
something
and
because
of
you
know,
it
was
done
quickly.
That's
the
potential
risk
that
can
you
know.
F
B
What,
if
we
do
this,
we
do
bugs
merge
after
owner,
approves
features
owner
approval
plus
24
hour,
wait
and
then
breaking
changes
owner
approval,
plus
24-hour
weights
plus
one
more
you
know,
two
people
minimum
approving,
so
just
a
single
owner
doesn't
approve
a
breaking
change
or
is
that
going
too
far.
F
A
F
C
C
Yeah,
I
would
basically
I
I
do
agree
with
all
of
the
points
here.
I
would
just
keep
the
rules
very
simple
and
trust
the
owners,
because
they
are
like,
like
yeah.
You
know
they
are
trusted
people
to
maintain
those
packages
they
are
just
under
the
the
packages
are
just
under
the
one
repo
and
that's
why
we
have
to
do
this
stance
around
this
thing,
but
essentially
they
are
the
maintainers
of
those
packages,
and
I
think
we
it's
better
to
treat
them
with
trust
and
and
give
them
the
responsibility
of
actually
maintaining
those
well.
B
Yeah,
I
agree
if
we
don't,
if
we
don't
trust
the
component
owners
to
maintain
them
effectively,
then
why
are
we
making
their
voters
to
begin
with.
B
Okay,
similar
topic
to
that
what
things
can
block
a
pr,
even
if
the
owner
has
approved
it,
so
I
think
we
may
decide
nothing,
but
we
need
to
talk
about
it.
At
least
so
is.
Is
there
anything?
Do
we
think
components
that
are
in
violation
of
the
specification?
Should
they
be
allowed
in
the
contributor,
and
we
should
just
say
that's
contrib,
and
it
is
what
it
is
or
should
that
block
a
component
even
if
it
violates
spec.
B
Do
you
guys
understand
what
I
mean
here
so
if,
if
somebody
makes
a
change
to
an
instrumentation
that
uses
semantic
conventions
wrong
or
something
like
that
or
puts
put
some
invalid
value
in
there
as
a
maintainer?
Should
I
block
that
pr
or
if
the
component
owner
says
I'm
allowing
this?
Do
we
do
we?
Let
that
through.
C
I
don't
see
a
reason
to
do
that
to
let
it
through,
basically
because
we
do
require
all
of
those
components
to
be
by
the
spec
right.
The
same
goes
with
the
security
problems.
If
we
are
aware
of
that,
like
again,
I
I
don't.
I
don't
see
this
coming
up
very
often,
but
it's
good
to
have
those
like
hard
rules
like
hey.
C
We
need
like
the
standards
for
each
of
those
instrumentations
is
that
and
one
of
them
is
like
it
has
to
follow
spec
and
it
that
does
it's
not
allowed
to
have
any
like
known
security
issues
with
it
like,
so
the
packages
have
to
be
reasonably
up-to-date
and
something
in
the
lines
of
those.
I
cannot
come
up
with
any
any
other
rules,
but
probably
those
will
come
up
over
time.
B
The
one
that
I
think
is
the
most
likely
to
come
up
would
be
a
potential
like
private
information
leak
so
like
if,
if
somebody
contributes
an
instrumentation
for
a
database
and
they
want
to
add
the
entire
database
statement
to
the
attributes
all
the
time,
no
matter
what
that's
not,
I
think
explicitly
disallowed
by
the
spec,
but
database
calls
obviously
have
a
lot
of
potential
for
leaking
private
data
or
if
they
wanted
to
put
like
the
whole
http
payload
on
the
the
attribute
or
something
like
that.
A
A
And
it
was
stocked
and
agreed
upon.
Then
it's
okay,
but
if
someone
does
it
without
communicating
it
also
for
the
spec
violation,
sometimes
the
spec
can
state
something,
but
when
you
implement
it,
you
see
that
you
cannot
follow
the
spec
exactly
or
you
run
into
edge.
Cases
will
need
a
little
flexibility.
B
So
I
think
the
only
one
I
I
I
do
see
your
point-
that,
where
even
violating
the
spec
could
potentially
be
required
in
some
cases,
I
don't
think
it's
very
likely,
but
to
happen
very
often
or
anything
like
that,
but
I
can
see
how
it's
possible
I
could
see.
Maybe
if
we
have
something
that's
a
security
concern.
B
B
F
I
mean
it's
also,
I
think,
required
by
the
cnn,
but
generally,
if
you
are
because
currently
we
have,
we
are
above,
but
if
more
people
will
be
adding
the
the
instrumentation
one,
they
will
drop
below
80
percentages
and
with
every
request
it
will
be
complaining
that
the
coverage
dropped
down
here.
B
F
A
B
B
B
Okay,
the
next
question
is:
should
all
new
packages
be
required
to
have
an
owner?
B
I
think
I
would
say
yes,
I
I
think
it's
just
an
easy
rule
to
have,
and
whoever
contributes
a
package
should
be,
should
contribute
a
package
with
the
understanding
that
they're
going
to
be
expected
to
to
maintain
it.
C
I
would
generally
agree,
but
if
you
put
people
in
a
position
where
they
actually
don't
want
to,
you
know
it
it
again
promising
chance
to
ever
get
there.
But
but
if
there
is
a
package
contributed
and
the
owner,
you
know,
doesn't
actually
have
the
interest
to
maintain
it
long
term,
then
probably
we
don't
want
to
force
them
to,
because
that
would
just
get
us
into
trouble
down
the
line
because
they
wouldn't
do
possibly
do
a
good
job
if
they
aren't
interested
in
it.
In
the
in
the
responsibility.
B
B
I
think
we
don't
need
to
make
a
hard
requirement
for
now,
at
least
unless
it
becomes
a
problem.
I
guess,
but
I'd
like
to
at
least
suggest
on
each
first,
each
package
that
gets
contributed
I'd
like
to
at
least
suggest
hey.
B
Can
you
would
you
like
to
be
an
owner
of
this
package
as
sort
of
a
recommendation,
but
maybe
not
a
hard
requirement,
but
I
do
not
want
to
release
any
packages
1.0
without
it
having
an
owner
or
if,
if
we
really
want
to
release
a
package
as
1.0
and
no
one
wants
to
step
up,
I
guess
the
maintainers
will
have
to
take
it.
F
Maybe
it's
worth
to
mention
that
there's
going
to
be
a
spec
for
the
for
the
instrumentation,
there
is
a
music
that
is
formalizing,
so
I
mean
we
need
to
have
just
bear
in
mind
that
one
day
it
will
be
some
spec
and
then
we
can
think
of
you
know
refactoring
the
instrumentation
to
to
be
aligned
with
with
with
some
spec
and
some
common
things.
B
B
It's
also
worth
mentioning
right
now,
as
we're
speaking
about
packages
going
to
1.0.
The
tc
has
said,
has
asked
all
sigs
not
to
release
any
instrumentation
packages
as
1.0,
yet
so
they're
they're
all
being
held
at
zero
dot
versions.
B
While
we
determine
what
are
the
guarantees
that
we
will
make
when
we
go
to
1.0
so
for,
for
instance,
what
can
what
constitutes
a
breaking
change?
If
I
add
an
attribute,
is
that
to
a
semantic
convention?
Is
that
a
breaking
change,
or
if
I
change
the
value
of
an
existing
attribute?
Is
that
a
breaking
change
and
things
like
that
and
until
those
are
decided,
we
can't
make
any
packages
1.0
or
we
can't
make
any
instrumentations
one
that
up.
D
A
B
Last
item
here,
as
far
as
merging
once
these
requirements
are
all
met,
who
can
merge
a
package?
Are
we
waiting
for
maintainers
to
do
it
or
if
somebody
with
right
access
sees
that
something
has
met
the
met
the
requirements?
Can
they
can
anyone
urge
it.
F
I
would
say,
but
just
making
sure
that
profit
is
the
component
or
not
right.
No,
the
approver
is
sorry.
I
I
mean
currently
all
the
component
owners
are
already
approvers.
Yes,
so
they
can
do
this
yeah.
C
F
G
C
C
A
If
someone
is
the
component
owner,
can
he
merge
prs
on
his
components
like
approve
them
and
then
merge
them?
I
think
no
like.
We
need
a
second
eye
just
to
yeah.
B
B
C
So
yeah,
I
would
basically
leave
the
baseline
the
same,
so
the
component
owner
rules
so
say
are
like
just
below
what
we
have
right
now.
So,
even
if
the
owner
is
on
inactive
and
the
maintainers
like
the
and
the
package
goes
through
the
same
process
as
it
does,
you
know
last
week
or
like
as
it
has
been
until
now,
then
it
should
be.
C
You
know
the
business
as
usual,
so
the
maintainers
by
themselves
can
merge
and
release
packages
that
they
are
not
necessarily
owners
of,
so
that
the
maintainer
kind
of
permissions
are
still
above
everything
else.
If
the.
A
F
Something
else,
maybe
we
say
like
three
days
and
if
they're
all
better,
but
if
the
owner
can
simply
right,
then
okay,
I'm
I'm
busy.
Please
wait
additional
two
days.
I
don't
see
a
problem,
we
can
wait,
but
I
would
also
like
to
avoid
the
situation
when
you
ask
the
owner
and
you
have
to
wait
the
entire
week
just
to
see
the
that
he
didn't
respond
to
right.
F
F
B
I
don't
think
I'm
on
one
pr,
I
think,
in
order
to
be
removed
as
an
owner.
I
think
you
need
to
show
a
pattern
of
not
being
you
know,
of
not
being
responsive,
because
if
I
go
on
a
week,
if
I
go
on
vacation
for
a
week
and
forget
to
tell
everybody
and
I
come
back
and
somebody
has
merged
to
change
and
removed
me
as
the
owner,
I
would
be
really
mad.
F
F
B
A
B
I
don't
think
it's
going
to
happen
that
often
that
a
component
owner
is
unresponsive,
but
you
know
if,
if
it's
been
a
day
or
two
and
the
owner
hasn't,
you
know
it's
been
two
or
three
days
and
the
owner
hasn't
made
a
review
or
comment
or
anything.
Yet,
just
we'll
add
a
comment
on
the
pr
to
say:
hey
have
you
seen
this
and
maybe
reach
out
on
slack
to
those
that
are
on
the
cncf
slack
and
after
a
week
or
whatever?
B
If,
if
there's
been
no,
not
even
a
comment,
that's
like
I'm
busy
and
I'll
get
to
this
later
then.
At
that
point
we
will
consider
merging
a
pr-
and
this
is
not.
This
is
not
like
punishing
the
owner
or
anything
like
that.
It's
just
that
if
there's
a
pr
that
we
want
other
contributors
to
be
able
to
feel
like
they're
not
being
ignored.
A
B
Okay,
that
was
kind
of
a
long
topic.
We
do
have
a
list
of
prs
in
here.
I
guess
please
review
them.
If
there
are
pr's
that
you
want
reviewed,
please
add
them
to
the
list
bart.
I
did
want
to
ask
you
about
this
one.
You
did
not
add
yourself
as
a
component
owner
on
the
fastify
instrumentation
yeah.
F
B
C
Sorry,
what
sorry,
what's
the
criterion
currently
for
merging
stuff,
because
the
nest
one
has
at
least
like
three
approvals.
B
Yeah,
oh
you
know,
I
remember
why
it
was
because
valentine
made
a
comment
but
never
approved,
and
I
wanted
to
see
if
he
was
going
to
join
the
meeting.
I
was
going
to
merge
it,
but
I
just
was
waiting
until
after
the
meeting
to
see
if
there's
any
reason
not
to
I.
This.
C
B
Okay-
and
I
guess
please
review
at
least
the
the
release
pr
so
that
we
can
get
these
releases
out
since
there's
been
quite
a
few
changes
and
hope
everybody
has
a
good
week
and
I'll
talk
to
you
next
week.
Oh
I'm
out
tomorrow
and
friday,
by
the
way
for
those
that
don't
already
know.