►
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
During
committee
meeting
for
september,
16
2020
we'll
follow
the
agenda,
which
was
as
tagged
in
issue
number
922
in
the
tse
repo.
A
And
I
don't
think
that
there's
anything
in
our
board
in
the
admin
board
in
terms
of
of
actions
for
things
to
be
taken
to
the
board.
Let
me
know
if
there's
anything
that
you
do
think
should
be
going
on.
That's
not
there
in
terms
of
the
cpc
mary,
I
guess
that's
sort
of
old
news,
but
mary
is
taking
over
from
mateo
on
that
front.
A
A
Yeah,
nothing,
I
think
that
comes
to
mind.
So
unless
there's
questions,
let's
move
on
to
the
tagged
issues
there.
A
A
This
is
a
result
of
work
from
the
team
working
on
looking
at
the
next
10
years
of
node.
What
will
make
us
successful-
and
you
know
as
a
basis
for
that
we
thought
we
needed
to
agree
on
the
the
technical
values
shared
by
the
project
and
what
we've
seen
used
to
to
make
trade-offs.
A
So
this
is
a
pr
that
that
reflects
that
work.
There's
been
a
number
of
people
chiming
in
just
think.
It's
it's
good
that
we
have,
as
many
people
ensure
that
it's
consistent
with
you
know
what
they've
seen
and
believe
as
well.
So
I
think
there's
like
one
two,
three,
four:
five:
six,
seven,
eight
nine
there's
about
20
approvals
so
far,
but
you
know
I'll
I'll.
Take
it
off
the
agenda
for
now,
but
just
want
to
make
sure
everybody
was
aware
of
that
and
has
a
chance
to
take
a
look.
A
On
no
okay,
so
the
next
one
is
35037
change
requirements
for
object,
objection.
Dismissal
this
is
was
tagged
for
the
agenda.
Let
me
take
a
look
who
tagged
that
for
the
agenda.
A
I
think
it
was
rich
who
added
it
to
the
agenda,
he's
a
bit
early
for
him
today
I
know:
does
anybody
else
have
any
have
enough
context
to
bring
that
one
up
for.
C
Oh
yes,
yes,
it's
essentially,
I
am
objecting
because
I
think
it's
it
will
completely
remove
the
tse
for
it's
its
role
of
arbiter
for
off
when
the
concession
singing
approach
fails
so
essentially
the
removing
the
the
some
of
the
changes
that
are
being
put
forward
to
our
governance
as
the
result
of
making
an
objection
to
a
change
to
appear
coming
in
completely
redundant.
C
D
C
This
doesn't
I
I
agree
that
there
is
a
problem
to
solve,
though
okay,
so
I
I
agree
that
there
is
a
problem
to
to
solve
and
we
need
to
make
smooth
to
improve
the
path
of
prs
that
are
easy
to
land
and
that
are
non-controversial
so
that
they
don't
wait
forever.
Even
the
24
48
hours
is
too
long,
I
agree,
and
but
on
the
other
side
it's
not.
A
E
A
Yeah
sure,
for
sure
I
can't
it's
here's
the
link,
and
I
think,
like
this
is
the
the
change
was.
You
know.
The
ejector
is
unresponsive
for
seven
days
after
the.
C
A
A
A
A
That
you
shouldn't
be
able
to
just
say
I
object
and
then
not
participate
in
a
discussion.
A
C
That's
my
that's
my
as
long
as
it's
clear
that
an
opinion
is
final
right
as
long
as
it's
clear
that
an
opinion
is
final
and
there
is
nothing
to
move
that
forward.
It's
no.
C
You
know
it's
clear
that
the
next
step
will
be
go
to
the
tsc
and
ask
for
a
vote
right.
There
is
no.
F
If
I
can
interject
one
one
thing
there
like,
I
think
what
one
of
the
challenges
with
that
approach
becomes
and
I'm
not
saying
that
I
have
a
solution,
but
it's
you
know
when
we
have
objections
that
are
in
a
pr
and
then
let's
say
it
takes
like
one
or
two
weeks
to
get
to
the
point
or
like
okay,
we
have
like
a
single
objector
and
we're
not
getting
over
that.
Then
we
take
it
to
the
tsc.
F
You
know
like
something
that
could
have
hopefully
maybe
been
resolved
in
two
days,
because
there's
a
single
objection,
or
maybe
we're
close
to
rough
consensus,
now
takes
us
like
two
or
three
months
to
reach
a
conclusion
that
99
of
the
time
like
reflects
the
conclusion
we
probably
could
have
come
to.
If
we
just
overrode
the
loan
objection
and
and
so
to
me
that,
like
I'm,
not
saying
that
this
is
the
right
solution,
but
that's
the
problem,
I
would
love
to
see
us
try
to
fix
and
I
don't
want
to.
C
D
I
mean
just
to
kind
of
reword
that,
with
different
way
miles
from
what
you
just
said
is
you
know,
because
we
have
a
problem
with
dealing
with
objections,
we're
we're
we're
just
going
to
disincentivize
people
to
object
at
all
and
when
the
actual
problem
is
our
process
for
dealing
with
the
objection
and
right.
Yes,.
C
D
Recognize
that
this
pr
is
trying
to
make
steps
in
that
direction,
but
I
think
I
think
it
needs
to
be
worked
through
a
little
bit
more.
F
It
almost
always
ends
up
going
punting
back
to
the
person.
Who
knows,
I
would
say,
streams
is
like
that
with
you
or
http
2.
That's
you
james.
So
if
we
all
kind
of
trust
each
other,
maybe
there's
a
way
in
which
we
could
minimize
the
need
for
a
committee-wide
consensus
or
vote
and
allow
people
to
be
more
autonomous
on
the
tsc
to
make
these
decisions
and
if
other
tsc
members
disagree
with
that
like
we
can
have
things
in
place,
but
maybe
we
could
fast
track
this
process.
D
The
allusion
to
fast
track
is
actually
good.
Maybe
the
approach
would
be
rather
than
forcing
it
automatically
to
a
vote
we
can
have.
It
can
allow
a
tsc
member
within
the
the
github
thread,
to
propose
that
an
objection
be
dismissed
and
as
long
as
there
are
no
objections
to
that
dismissal
and
at
least
two
people,
two
other
two
members
agreeing
to
it
in
the
in
the
github
thread.
D
Yes,
you're
back
yeah,
sorry,
sorry,
it
switched
from
mobile
data
to
wi-fi.
What
I
was
saying
is
you
know.
Maybe
we
can
follow
approach
similar
to
the
fast
track
model
where,
within
the
github
thread
itself,
if
a
tsc
member
proposes
to
that
an
objection
can
be
dismissed.
D
It
would
require
two
other
tsc
members
to
agree
to
that
and
no
objections.
Just
like
we
do
with
the
fast
track
model,
and
then
we
and
then
we
can
dismiss
it
if
the
person
making
the
objection
if
they
want
to
appeal
that,
then
they
can
appeal
that
to
the
tfc,
you
know
posting
a
comment
in
the
thread
and
escalating,
but
that
would
at
least
give
us
a
way
of
kind
of
streamlining
the
process.
D
You
know
for
the
folks
that
are
actively
following
the
conversation.
The
csc
members
that
are
involved
can
make
that
decision.
A
Yeah,
I
I
certainly
think,
like
I've
had
some
similar
thoughts.
That,
like
is
there
a
way.
We
can
trust
our.
You
know
other
tse
members
to
do
the
right
thing
and
therefore
not
have
it
come
back
to
the
full
tsc.
So
having
something
like
you
know,
some
number
of
tse
members
be
able
to
do
that
on
their
their
own
makes
a
lot
of
sense.
A
A
You
know
the
case
where
collaborators
say
object,
but
there's
no
clarity
on
why
and
then
people
try
and
ask
for
clarification
and
they
don't
respond.
So
it's
kind
of
the
the
the
you
know
non-responsive
after
making
a
you
know,
not
a
final
objection
like
mittal
says.
I
think
you
know.
I
definitely
agree
that
once
it's
like
hey
we've
had
a
discussion,
that's
the
end
of
it.
A
You
know
you
don't
want
to
have
the
every
week
you
have
to
like
basically
say
yeah.
I
know
I
still
object
right,
like
that's.
That's
a
totally
different
thing,
it's
more
than
it's
more
like
if
somebody
says
I
object,
no
other
information
and
I
think
what
this
was
intended
to
do
was
to
say.
Oh
and
now
somebody
said
well
how
about
we
do
this
or
here's
a
compromise
and
there's
no
interaction
to
you
know
on
that.
So
anyway,
a
little
bit
different.
But
maybe
we
need
to
just
deal
with
the
larger
problem
versus
smaller.
C
Problem
where
the
actual
thing
what's
not
working,
it's
bigger
and
it's
on
the
possibly
in
the
tsc
charter
itself
right
and
that's
where
what
we
should
change
now
fixing
this
is
just
adding
a
sentence
to
what
is
proposed.
An
objection
can
mark
an
objective,
can
mark
his
decision
as
final
and
then
the
only
path
forward
for
the
pr
should
be
to
be
escalated
to
the
tsc
or
something
similar
it's
actually.
C
It's
actually
would
resolve
my
objection,
yep
and
as
long
as
there
is
a
way
to
say,
I
don't
want
to
be
engaged
anymore.
This
is
wrong.
Okay,
yeah.
D
C
C
D
C
C
A
G
So,
overall,
this
is
a
more
like
actually
writing
down
what
has
already
happened
before
multiple
times,
because
I
have
reviewed
so
many
pr's
and
also
ping
people.
If
and
there
were
some
concerns,
and
there
were
multiple
cases
where
concerns
were
resolved,
even
though
the
person
never
responded
again.
This
has
been
like
after
a
couple
of
weeks.
F
I
I
want
to
just
start,
I
think
one
of
the
things
with
the
sentence
with
me,
perhaps
even
like
a
different
way
that
we
can.
We
can
frame
it
like
thinking
about
rough
consensus,
like
that
is
kind
of
the
point,
that
there
is
no
more
debate
and
it's
like.
F
Are
we
going
to
override
this
objection,
or
is
this
objection
substantive
enough
to
stop
the
progress,
and
I
think
I
don't
even
think
it
needs
to
be
just
the
objector
who
can
risk
like
if
we
can
generally
reach
content
that
we
have
kind
of
debated
something
to
the
end,
and
we
just
know
like
here
is
a
clear
objection
and
either
we
agree
that
this
objection
is
enough
to
stop
the
work
or
it
isn't
like.
We
shouldn't
continue
to
debate
on
it
mateo.
Would
you
say:
that's
like
a
good
characterization
as
long.
C
As
more
or
less
yes,
as
long
as
the
decision
for
this
is
going,
is
not
done
by
the
people
involved,
but
it's
gold
back
to
the
dsc.
Essentially
so
it's
whenever
there
is
a
situation
when
consent,
so
by
our
the
way
that
the
charter
is
set
up.
We
have
that
resolving
consensus-seeking
problems
falls
on
the
tsc
right
now
and
it's
as
long
as
the
tsc
in
one
form
or
another.
The
way
james
proposes
it
or
something
else
is
in
the
loop
of
removing
the
objection
that
it
should
be
something
that's
taken
very
seriously.
C
A
A
Proposals
to
change
have
been
made,
the
the
pr
may
have
already
been
updated,
but
then
there's
no
response
from
the
objector
to
say:
yeah
you've
addressed
what
I've
I've.
What
I
was
worried
about
or
no
I
I
still
want
to
object
right,
and
so
I
think
the
you
know
if
you,
if
you
object
but
then
just
totally
forget
about
it,
it's
not
necessarily
unreasonable
that
you
know
the
at
some
point.
We
need
to
move
forward
and
it
gets
removed
automatically.
C
It's
already
covered.
This
is
already
covered,
michael,
so
the
the
sentence,
what
you
the
case
that
you
mentioned
is
already
covered.
If
you,
if
somebody
says
I
object
because
of
this
thing,
and
then
somebody
says
okay,
I
have
that
the
author
of
the
pr
says
I
have
addressed
this-
that
objection
with
in
this
way.
F
F
It
seems
like
it's
been
taken
care
of,
I'm
gonna
override
it.
I'm
doing
this
objection
override
fast
track
thing.
They
open
an
issue
on
the
tse
repo,
letting
other
tfc
members
know
which
one
objects
to
it
within
48
hours.
F
It
could
be
like
a
fact
that,
like
if
we,
if
we
can
normalize
and
document
fast
tracking,
removing
objections
that
also
covers
kind
of
any
case
where
there
would
be
an
objection,
including
the
case
where
someone
vanishes
and
it
kind
of
falls
on
us
as
tsc
members
to
operate
in
good
faith
and
be
good
stewards,
and
I
think
that,
like
as
long
as
we
are,
you
know
if,
on
paper
it
looks
good
like
if
someone
press
it,
I
don't
think
that
there
should
be
problems
there,
and
I
think
that
I
trust
the
members
of
the
tse.
E
And
just
to
just
to
support
your
point
miles,
I
think
I
think
we
tend
to
work
a
lot
better
in
issues
than
we
do
at
meetings
right,
because
you
know
we
we
are
not
able
to
make
it
at
that
time
and-
and
somebody
earlier
pointed
out
that
this
can
drag
on.
But
I
think
I
think
this
proposal
is
good
because
we
do
work
better
in
the
issue
tracker
and
we
can
just
leave
our
comment
in
the
tsc
issue
for
that
right
and
it
seems
like
it
might
work
faster.
D
Yeah,
so
I
I
can
take
a
stab
it
it.
It
is
a
it's
some
comments
describing
this
kind
of
alternative
approach
in
thread
for
this
particular
pr,
but
yeah
it
would
work
very.
It
would
work
very
similar
to
the
what
we
currently
do
with
fast
tracks,
with
the
exception
that
only
a
csc
member
could
do
it
and
we
yeah,
and
then
we
can
go
from
there,
I'm
not
sure,
there's
much
more.
We
can
say
right
now
about
it,
but
but
yeah
there's.
A
That
sounds
good
to
me.
Does
anybody
have
any
concerns
or
things
they
want
to
discuss
further
on
that
before
we
move
on
to
the
next
issue,.
A
Okay,
let's
move
on
to
the
next
one,
which
is
number
35015,
util,
add
util.parsergs.
A
This
is
one
that
I
added
and
basically
you
know
it's
there's,
there's
a
disagreement
which
looks
like
it's
in
the
in
the
pr.
It
looks
like
it's
gotten
to
the
point
where
you
know
further
discussion
isn't
going
to
help
move
it
forward.
A
A
But
basically
the
the
disagreement
seems
to
be
over
whether
to
add
you
know,
with
the
parameters,
take
an
array
of
strings
or
take
an
array
of
strings
and
a
single
string
as
a
way
to
make
it.
You
know
easier
to
use
the
api.
A
A
So
I
know
this
is
one
where,
like
separately,
we've
had
discussions
about,
how
do
we,
you
know
perhaps
not
push
things
back
to
github,
is
often
to
try
and
resolve
these
kinds
of
things.
Is
it
something
we
can?
You
know,
spend
10
minutes
now
in
the
meeting
and
actually
try
and
come
to
a
decision
versus
pushing
off
until
next
week.
D
Or
I
I
think
I
think
part
of
the
challenge
here
is
the
amount
of
time
like
this
particular
issue.
I
mean
I've
known
it's
taken
a
while
to
land,
but
because
I've
been
doing
other
things,
I
have
not
been
able
to
actually
follow
it,
so
you
know
like
like
right
now,
given
like
a
five
minute.
Ten
minute
conversation,
I'm
not
sure
I'd
have
enough
context
to
be
able
to
weigh
in
on
it.
A
F
A
I
mean
basically,
the
objection
is
that
is
that
the
api
includes
you
see.
It
says
it
says,
string
or
array
of
strings,
so
is
that
param
listed
there
can
take
us
an
array
of
strings
or
a
string.
C
H
A
A
Can
we
come
up
with
ideas
that
make
sure
that
says
yeah
I
understand
james
haven't
had
a
chance
to
look
at
it.
We
don't
have
enough
context,
but
you
know
our
current
course
in
speed
has
been
okay,
well,
yeah,
we'll
we'll
talk
about
it
next
week,
and
then
we
have
a
different
set
of
people
in
the
meeting.
G
So
in
most
cases
and
where
things
like
that
have
happened
before,
as
far
as
I
see
it,
most
of
the
api
is
agreed
upon
and
it's
more
like
a
minor
indifference
and
that
people
cannot
yet
agree
upon,
and
in
that
case
we
mostly
did
it
that
we
first
went
with
an
implementation
that
did
not
include
and
the
part
that
was
difficult
to
decide
upon,
and
then
we
had
a
second
pr.
That
would
improve
the
situation
as
such
with
a
second
pr.
To
only
have
that
case,
and
then
it's
sometimes
easier
to
work
out.
A
G
C
C
E
It's
worth
we,
we
have
a
precedent
for
taking
both
an
array
and
a
string
for
the
same
parameter
and
it's
standard
io.
For
for
child
process.
You
can
either
specify
the
the
what
should
be
done
with
each
file
descriptor
in
particular
or
or
you
can
just
say,
inherit
and
that's
a
string
and
then
that
will
basically
pass
everything
through
to
the
parent
process.
So
we
already
have
an
example
of
this:
it's
in
a
in
like
an
option
property,
so
it
wasn't
confusing
there.
C
It's
from
what
it's
worth,
I
find
those
multi-type
things
really
really
hard
in
general.
So
if,
if
it's,
if
it's
needed
for
some
reason,
let's
add
it,
but
I
don't
given
that
process
dot
arc
v,
it's
an
array
already
segmented.
C
C
So
I'm
not
you
know
it's
for
the
sake
of
legacy
happy
to
maintain
this
type
of
stuff,
but
for
new
api,
maybe
now,
but
I'm
also
lgtm
in
the
code
as
it
is
because
I
think
it's
a
great
condition.
So
it's
not
I'm.
I
don't
know
it's
not
a
matter.
It's
not
a
big
deal.
I
don't
know
that's
my
personal
take
on
this,
but
other
people
might
disagree.
A
I
If
I
may,
I
just
want
to
add
one
more
point.
I
did
not
request
changes
on
the
pr
simply
because
someone
else
already
had,
and
I
don't
really
feel
strongly
about
the
feature
to.
I
I
don't
feel
strongly
enough
about
the
feature,
but
I
don't
consider
its
default
behavior
to
be
safe
and
I
think
we
shouldn't
add
apis
for
convenience
that
are
not
safe
by
default,
so
in
particular
the
behavior
that
bothers
me
is
that
if
you
specify
a
flag
which
does
not
take
a
value
and
add
equals
false
to
the
argument,
then
the
api
will
silently
convert
that
false
into
a
true.
I
No
sorry
it's
just
if
I've
got
two
requested
changes
if
they
hadn't
requested
changes,
I
probably
would
have
requested
changes
on
those
grounds,
but
I
didn't
expect
this
to
come
to
a
conclusion
soon,
so
I
didn't
want
to
really
add
the
burden.
A
I
A
G
A
Okay,
I
am
concerned
a
little
bit
that
that
will,
like
you
said,
just
delay
it
sort
of
dragging
out
the
it'll
be
another
week
before
that
happens,
and
we
haven't
the
new
issue
on
our
agenda
to
discuss.
But.
G
C
I
personally
find
those
things
hard
to
really
hard
to
work
with
right.
Those
type
of
those
type
of
overloads
does
not
really
fit
like
they
make
the
implementation
of
the
code
convoluted
and
they
cause
potential
performance
issues
down
the
line
and
so
on
and
so
forth.
So
it's
not
something
that
I
would
encourage
encourage
on
the
other
side.
In
this
specific
case,
there's
not
enough
ground
to
block
it.
If
somebody
really
wants
to
block
it.
A
Right,
so
if
we,
if
we
look
at
the
future,
then
we're
unless
there's
other
people
who
would
who
would
block
it
we'll
be
back
to
the
same
situation.
If
we
say
hey,
can
you
can
you
break
it
into
two
pr's?
The
new
pr
is
created,
we'll
now
be
back
into
the
same
situation,
with
the
same
objection
that
we
need
to
resolve,
and
I
don't
think
it's
clear
how
the
tse
would
resolve
that.
Yet
this,
I
think
ruined.
G
G
My
personal
opinion
is
similar
to
the
one
from
mateo,
for
example,
because
it's
also
error
prone
and
in
general,
it's
best
to
have
one
way
to
use
an
api.
That
way
you
are
certain
you're
using
it
correct
and
there
there's
a
lot
of
code
out
there.
That
does
not
do
that
because
there
are
many
overloads
and
then
there
is
a
lot
of
buggy
code,
because
there
are
so
many
different
ways
of
doing
something
and
people
just
don't
know
which
one
is
correct
in
a
specific
situation
and
which
one
is
not.
G
Therefore,
it's
unlikely
to
land.
We
should
probably
and
provide
some
statement
that
it's
that,
even
if
the
pr
is
split
into
two,
it's
unlikely
to
be
accepted
later
on.
A
Like
if
we
think
that's
the
way
it's
trending
like,
if,
if,
if
the
tc,
you
know,
we've
got
the
question,
I
I'd
feel
bad.
If
we
say
we'll
go,
do
some
extra
work
and
then
we'll
later
come
to
a
conclusion
that
says
you
know
no
versus
having
just
being
able
to
say
that
without
asking
for
that
extra
work,
that's
that's
kind
of
my
feeling
on.
A
I
I
am
I'm
unsure
to
be
honest,
I
don't
want
to
block
it,
but
I
really
feel
like
we
shouldn't
have
this
kind
of
unsafe
behavior
in
core
as
a
convenience
tool,
so
I'm
really
unsure
whether
I
should
block
it
or
not.
A
Right
so
that's
a
separate,
that's
a
separate
issue,
which
is
probably
you
know,
that's
not
one.
That's
come
to
come
to
an
impasse
right,
it's
probably
just
something
that
hasn't
been
brought
up
and
hopefully
there's
a
way
to
address
it
so
that
it
does
it
in
the
right
way
right.
A
A
A
F
Take
that
even
a
step
further
james,
we
have
quorum
right
now.
I
would
love
to
propose
that
as
a
tsc,
we
actively
defer
to
the
subset
of
people
right
now
who
say
that
they
have
strong
opinions
about
this
pr
to
manage
the
rest
of
the
process
here,
including
override
objections
and
kind
of
see
it
through.
F
F
A
F
Sorry,
my
connection
has
a
delay.
So
apologies
for
speaking
over
you,
michael
yeah,
no
go.
A
F
I
think
you
were
just
about
to
say
what
I
was
about
to
say,
which
was
who
wants
this
pr
moving
forward
so
that
like,
unless
that
subset
itself
cannot
reach
consensus?
There
isn't
really
a
reason
to
bring
this
to
the
full
tsc.
A
Okay,
okay
sounds
good.
We
will.
I
will
write
up
a
little
something
in
the
minutes
on
that
front
and
we'll
let
matteo
and
tobias,
engage
and
we'll
you
know
basically
bring
it
back
to
the
tc
if
necessary.
Otherwise,
it
should
be
resolved,
drop
minimum
waiting
time
as
a
hard
guideline.
This
is
33
879.
D
James
yeah
I'll
take
this
one.
So
on
this
one
I
mean
yeah.
This
is
a
proposal
by
anna,
following
the
contribution
survey
that
I
did
in
spring
to
basically,
the
idea
is
to
completely
eliminate
the
the
minimum
time
to
land
guideline
all
other
conditions
to
land.
A
pr
would
remain
the
same,
and
I
have
to
pass
ceo.
I
would
have
to
get
the
sign-offs
just
eliminate
the
time.
D
The
the
minimum
time
limit
there's
been
some
objections
in
the
thread
from
from
multiple
people
indicating
that
the
the
time
limit
at
least
makes
it
easier
for
people
internationally
to
review
changes.
D
A
compromise
proposal
has
been
put
forth
to
greatly
reduce
the
timelines,
making
the
minimum
24
hours
and
with
with
with
multiple
sign
ups
and
then
four
to
get
72
hours,
with
with
only
one
sign
up
that
would
be
down
from
48
hours
and
in
seven
days
for
the
for
those
two
cases,
but
the
people
that
have
objected
have
not
despite
multiple
pings
and
requests
have
not
weighed
in
on
whether
that
compromise
approach
is
is
sufficient
for
them.
D
So
you
know
it
really.
Just
kind
of
you
know
comes
down
to
csc
to
figure
you
know
to
decide
this.
There's
there's
right
now.
Three
basic
proposals
on
the
table:
three
options:
one
option
is
keep
everything
the
same
as
it
is
now
status
quo.
D
The
second
option
is
exactly
what
that.
What
what
anna's
pr
suggests
is
completely
eliminate
the
time
and
the
third
option
is
reduce
the
times
to
24
and
72.
A
Right
with
with
the
sign
off
from
the
code
owners-
which
I
think
is
the
the
key
thing
right
like
because
currently
it's
it's
a
72
hours
with
one
sign
off
so
and
currently
the
time
limit
remind
me,
is,
I
think,
it's
48
or
72
hours
right.
D
D
So
what
the
compromise
proposal
would
be
is
if
there
are
at
least
two
sign-offs,
it
could
land
in
24
hours,
and
I
think
that
the
the
caveat
is
that
is
at
least
one
of
those
have
to
be
from
a
code
owner
if
your
code,
if
it
has
coverage
right
otherwise
it
can.
You
know
it
has
to
wait.
72
hours
to
land.
A
D
A
A
If,
in
some
specific
areas
you
really
want
to
have
a
code
owner
have
a
chance
to
take
a
look
right,
so
I
don't
know
if
you
know
I'd
be
you
know,
I
don't
know
mateo
if
you
think
72
hours
long
enough
versus
seven
days
like
are
you
I
guess
I'm
asking.
Are
you
happy
if
72
hours
is
long
enough?
It's
just
any
sign
off.
C
I
would
need
to
to
think
some
of
it
it's
again
if
a
subsystem
like
on
certain
cases,
probably
no
on
the
other
end,
it's
it's
probably
going
to
be
fine,
so
I
it
would
be
it's
going
to
be
very
strange
if
a
pr
on
something
lands
that
is
not
on
something
critical,
that
get
reviews
only
by
one
person
get
skipped
by
everybody
else,
and
then
somebody
like
if
it's
complex
enough
and
change
something
complex.
I
suspect
somebody
said
well
wait
a
minute.
Let's
just
use
this
properly
right.
B
C
You
know
it's,
I
find
it
very
very
hard
to.
I
find
it
a
very
hard
case,
so
that's
probably
happens
for
something
trivial.
That's
not
you
know,
don't
get
much
attention.
I
don't
know
I'm
just
it
that
I
am
this
with
the
72
hours,
I'm
probably
fine.
F
So
one
thing
I
want
to
bring
up
really
quickly.
That's
part
of
this
discussion
is
there
was
a
feedback
about
code
owners,
specifically
that
not
all
of
the
code
owner
groups
or
teams
that
we
have
were
have
the
same
degree
of
vetting
to
get
people
on
those
code
on
our
lists,
and
so
you
know
I
have
not
actually
reviewed
or
audited
all
those
lists,
and
I
can't
really
speak
to
to
that
comment.
F
But
there
was,
you
know,
like
definitely
a
concern
about.
You
know
an
equal
quality
of
review
from
all
of
those
different
code
owner
lists,
so
I
would
just
add,
as
a
as
kind
of
a
quick
aside
there,
that
if
we
do
want
to
explore
code
owners
as
being
a
gate
there
we
may
want
to
you
know,
do
an
audit
of
those
lists
and
you
know
make
sure
that
the
people
who
are
in
those
lists
truly
do
own
that
code.
A
That's
kind
of
a
it's
almost
a
separate
problem
like
if
we
only
have
one
person
who
can
actually
act
as
a
code
owner
that
doesn't
mean
we
shouldn't
delay
the
pr
to
get
them
to
review
it.
Right
like
we
have
a
problem,
but
it
doesn't
in
my
mind
it
wouldn't
say
we
should
let
things
land
faster,
because
we
don't
have
enough
people
to
review
a
critical
area
like
that's
something
we
should
fix,
but
it
doesn't
mean
we
should
land
things
that
shouldn't
land
right.
A
So
on
this
one,
you
know
one
of
the
suggestions
or
one
of
the
things
thoughts
I'd
had
is
like
if
we,
as
a
group
here,
think
that
the
proposal
for
overriding
the
objection
is
three
with
a
code
owner
on
it.
You
know,
maybe
the
path
is
to
you
know
either
either
we
can.
Although
we
haven't,
you
know
agreed
on
that,
the
the
you
know,
subsets
of
tsc
members,
making
overriding
the
objections.
We
could
either
go
with
that
or
we
could.
A
You
know,
open
an
issue
in
the
tse
repo
that
says
this
is
what
we
think
the
proposal.
This
is
the
proposed
path.
If
there
aren't
any
objections
from
tsc
members
by
the
you
know
the
end
of
the
week
or
sometime.
This
is
what
you
know.
The
we'll
basically
use
consensus
seeking
where,
if
we
don't
hear
objections,
this
is
a
proposal
we
move,
we
say
we're
moving
forward
with
on
this
one.
A
So
we'll
do
that
for
this
one
I'm
at
this
point
we
did
want
to
reserve
some
private
time.
We
only
have
five
minutes
left
the
last
three,
I'm
not
sure
like
there's
the
proposed
the
the
proposed
to
rename
the
default
branch
which
we've
talked
and
is
really
ongoing.
So
I
don't
think
we
necessarily
need
to
talk
about
that.
There's
the
the
process
to
change
the
default.
A
A
G
Not
really
urgent,
out
of
my
perspective,
okay
in
general,
at
some
point
and
yes,
it
would
be
nice
about
the
15
version,
but
in
the
end
it's
not
really
something
important
and
that
it
has
to
go
into
15.
So
that's.
A
Just
so
we'll
we'll
leave
that
on
the
agenda
for
the
next
meeting.
If
people
can
chime
in
take
a
look
offline,
we'll
do
that
and
I'm
going
to
take
close
out
the
meeting
for
today.
So
thanks
to
everybody,
who's
been
watching.