►
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
Hello:
everyone
welcome
to
the
february
25th
2021
edition
of
the
contributor
experience,
github
administration,
subproject
meeting
a
reminder
that
this
meeting
is
being
recorded
and
we
abide
by
the
cncf
code
of
conduct.
Please
be
excellent
to
each
other.
A
We
got
one
item.
That's
currently
on
the
agenda:
github
master
to
main
updates,
I'm
not
sure
who
specifically
wants
to
kick
off
that
discussion
go
for
it.
Bob.
B
So
we
we
have
an
update
from
github.
The
big
blocker
has
been
the
fact
that
when
we,
when
it
goes
to
the
rename
process,
it
literally
deletes
the
master
branch
and
recreates
everything
under
whatever
branch
you're
you're,
creating
which
causes
essentially
a
webhook
storm
and
causes
all
ci
to
re-trigger,
or,
I
should
say,
the
pre
and
post
submits
now
lci.
My
bad
github
engineering
supposedly
has
a
fix
in
coming.
B
We
should
hear
back
like
hopefully
within
the
next
week-
the
alternative-
I
don't
remember
which
pr,
but
I
believe,
aaron
outlined
him.
I
think
it
was
aaron
outlined
what
would
have
to
be
modified
regarding,
like
essentially
turning
proud
off
on
a
per
repo
basis.
To
do
that
switch
would
also
be
kind
of
a
pain
to
do.
A
I
just
pulled,
I
just
pulled
the
link
for
that.
The
like
I
had
left.
I
left
a
comment
on
that
issue
and
basically,
just
said
like,
I
was
always
looking
as
far
as
like
open
prs
and
things
like
that
on
on
the
different
repos,
at
least
in
kubernetes,
I
haven't
looked
through
kuber
86,
but
in
kubernetes
there's
four
key
repos
that
have
over
a
hundred
open
prs.
As
of
what
I
looked
over
this
yesterday
and
it's
the
main
kk
repo
test,
infra
a
website
and
enhancements,
everything
else
is
fine.
A
If
we
could
handle
like
100
right
three
test
pr's
at
once,
then
the
only
one.
That's
a
really
big
concern
is
the
main
kubernetes
kubernetes
repo,
because
that's
about
thousands
open
pr's.
But
if
github
is
going
to
handle
this
for
us,
we
could
potentially
look
at
like
hey
the
four
big
ones,
because
there's
also
like
there's
a
big
jump
between
like
the
four
big
ones
that
are
like
three
that
are
around
100
and
then
there's
like
a
big
drop
down
before
we
get
to
like
the
next
repo
as
far
as
open
pr's.
A
B
B
A
The
website
thing,
though
we
can
also
likely
shut
off,
like
we
could
temporarily
disable
the
hooks
website.
The
the
the
prowl
one
like
the
main
prowl
hook,
is
at
the
org
level,
so
that
makes
it
trickier
because
we
can
only
flip
it
on
and
off
at
the
org
level,
but
for
website.
If
we're
moving
website,
we
can
like
turn
down
the
hook
sending
for
website
move.
It
turn
the
hook
sending
back
up,
and
hopefully
things
will
work
still.
B
That
shouldn't
be
an
issue,
the
other,
the
other
showing
thing
is
like
for
any
netflix
site.
You
do
have
to
manually,
go
in
there
and
reconfigure
the
branch
when
you
rename
it.
It
does
not
follow
like
the
deploy
branch,
so
this
in,
in
generally,
shouldn't
be
too
much
of
an
issue,
but
we
like
just
in
our
checklist
of
when
repos,
are
migrating
like
if
they
have
a
netlify
site
that
has
to
be
coordinated.
A
Yeah
yeah
yeah,
and
it
sounds
like
it's
just
gonna,
be
like
I.
I
don't
think
we're
gonna
be
able
to
automate
and
do
a
mass
migration
all
at
once.
It's
likely
going
to
be
there's
enough
little
fiddly
knobs
with
things
that
will
want
to
make
it
like.
Okay,
there's
an
actual
human
process
behind
us
that
has
to
go
and
like
check
these
prerequisites.
C
Sounds
like
it
would
be
fine,
either
way,
because
if
the
netlify
stuff
is
configured
on
like
the
netlify
tunnel,
config
like
we'd
have
to
send
a
pdf.
That
part
is
not
gotcha.
B
D
B
Yeah,
so
I
think
at
this
point
it's
mostly
you
know,
essentially
writing
the
punch
list
of
the
the
process
that
people
need
to
follow
for
this
stuff.
Also,
you
know
looking
at
whatever
needs
to
happen
and
test
infrared.
If
you
have
like
branch
protection,
just
like
lots
of
little
conditionals
and
just
like
fyi
go
go.
Look
at
this.
C
So
so
aaron
has
you
know,
I
think,
a
certain
point
yeah.
I
think
at
this
point,
aaron
has
like
multiple
punch
lists
around
this
for
different
rebounds.
That
he's
tried
out.
I
was
going
to
run
forward
and
do
it
for
enhancements
in
the
sig
release
repos,
but
he
he
repeats
all
the
punch
on
the
testing
side.
So
I
think
he's
done
kate's
that
I
o
as
well
as
not,
I
don't
think
he's
done,
testing.
C
B
A
C
A
The
other
thing
that,
like
doesn't
block
us
like
hand
the
migrating
like
we
can
keep
moving
forward
with
hand
migrating
repos
that
that
are
are,
you,
know,
eager
and
ready
to
move,
but
something
that
I'm
still
concerned
about
and
likely
you
need
to
check
with
like
dims
or
nikita,
is
the
publishing
bot
for
staging
repos
and
how
we're
how
we're
handling
those,
because
there
may
be
some
extra
fun
config
in
there
as
far
as
handling
them
granted.
A
A
We're
publishing
we're
not
like
expecting
people
to
be
cloning
out:
the
default
branch
really
anyways
or
they're,
going
to
be
targeting
specific,
specific
release,
branches
or
tags
anyway.
So
leaving
that
to
the
near
the
end
of
the
process,
I
think
is
okay,
but
that's
still
something
that
comes
up
for
me
as
far
as
other
fun,
automation
that
we
need
maybe
need
to
take
a
look
at
and
see
how
it's
going
to
handle
that
use
case.
C
Well,
it's
it's
the
publishing
rules
in
in
staging
publishingrules.yaml.
I
think
that
there
are
some
defaulting
bits
that
you
can
do.
I
know
at
least
for
the
go
version
and
probably
for
the
branch
as
well,
because
they're
all
targeted
per
per
branch
right,
I
think
they're,
release
branches
and
then
and
then
configs
per
branch,
assuming
that
you
don't
have
a
default
config
or
for
overriding
a
default
config.
If
you
want
to
so
it
would
be
a
change
to
that
and
and
yeah
for
the
for
the
publishing
repos.
C
No
one
should
be
pushing
to
those
repos
manually
anyway.
So
I
think
I
think
we
should
be
fine
there.
I
would
almost
say
that
that
is
one
that
we
would
maybe
want
to
consider
in
the
middle
pool
of
like
okay.
This
has
some
special
caveats,
but
but
it's
another
good
test
case.
I
don't
think
it
needs
to
necessarily
wait
till
the
end.
A
You
know
when
it
you
know
clones
and
pushes,
and
that
kind
of
stuff
isn't
adopting
the
configurations
from
what
it's
getting
from
github,
because
if
it's
doing
that-
and
it's
just
like
doing
like
default
hit
configs
if
it's
like
recloning
and
using
what
github
is
giving
it,
then
it
should
just
adapt
just
fine.
But
if
there's
like
hard-coded
master
strings,
which
would
not
would
not
shock
me
if
there's
hard-coded
master
strings
in
some
places
that
we
just
need
to
adapt
those.
C
Yeah,
it's
and
so
for
rules.
Why
is
this
going
to
pull
from
that
that
staging
publishing
rules.yaml,
I
just
linked
it
in
the
chat
and
yeah
the
the
branches
are,
are
hardcoded,
so
it
would
be
a
it
would
be
a
change
to
that
config
and
then,
after
that,
it
should
be
good
to.
A
A
Yeah,
it's
figuring
out
like
how
often
runs
do
we
we
might
just
need
to
like
pause.
The
publishing
bot
do
the
changes,
because
there
it
takes
time
for
things
to
get
merged
into
into
kubernetes
kubernetes
wait
for
it
to
get
merged,
make
the
change.
Do
it
so
yeah,
but
there'll
be
probably
some
interesting
ordering
stuff
yeah
to
make
sure
that
we
don't
break
exams.
A
C
One
we
should
think
timeline
as
well,
because
if
we
want
to
move
forward
on
some
of
this
for
121,
you
know
code
code
freeze
will
be
march
9th.
If
I'm
remembering
everything
correctly-
and
this
is
probably
if,
if
it's
a
change
that
we
want
to
make
this
cycle,
then
it's
a
change
that
we
should
start
moving
towards
soon.
If
it's
not
and
I
feel
like,
we
probably
want
to
give
it
some
more
time,
then
we'd
want
to
kick
it
off
for,
like
the
beginning
of
122.,.
A
Yeah
for
for
the
main,
kubernetes
repo,
as
well
as
definitely
anything
that
touches
it,
so
I
would
also
kind
of
lump
in
the
like
publishing,
bot
and
and
staging
repos
and
that
kind
of
stuff
into
that
I'd
say
like
yeah.
Let's
wait!
I
would
also
group
in
the
other
three
big
repos
as
far
as
prs
so
test
infra
website
and
enhancements.
A
I
would
also
kind
of
lump
those
into
the
like:
let's
not
move
those
repos,
yet
until
we
get
more
from
github
as
far
as
how
we
handle
the
web
hooks
other
repos,
you
know
as
long
as
we
kind
of
like
collate
all
the
notes
together
in
the
punch
list
from
from
erin.
As
far
as
how
we've
gone
about
this
in
these
two
repos,
I
do
not
see
any
issue
with
us
like
continuing
to
chug
port,
it's
gonna.
A
C
I
wouldn't
say
that
I
would
say
that
we
may
want
to
consider
moving
on
enhancements,
given
that
there
is
less
going
on
in
the
repo
right
now
and
there
will
be
more
going
on
at
the
beginning
of
any
cycle.
So
the
the
reason
that
I
want.
A
Enhancements
in
there
was
specifically
pr
count,
there's
a
hundred
open
peers
about
100,
open
pr's
in
enhancements.
Last.
I
looked
yesterday
so
then,
and
like
the
jump
from
enhancements
and
like
enhancements
test,
infrared
website
were
all
around
the
100
mark
and
then
there's
like
a
big
jump
down
to
like
30
or
40
for
the
next
biggest
repo.
A
C
So
yeah,
so
what
I
was
what
I
was
saying
there
is
that
the
while
there
are
while
there
are
a
bunch
of
prs
and
k
enhancements
the
times
that
people
care
about
those
pr's
are
different
than
than
test
in
for
a
website
and
kk.
C
A
Right
but
I'm
saying
maybe
we
wait
till
this
time
next
cycle
to
do
enhancements,
I'm
strictly
from
the
number,
the
pr
account
and
the
web
hook
storm
and
we're
still
waiting
on
github
that
for
those
things
combined
together.
That's
where
I'm
saying
like
you
know.
Yes,
if
the
if
this
time
in
the
cycle
is
best
as
far
as
when
it's
going
to
be
the
low
mark
in
the
cycle
for
for
prs,
that's
great,
but
we
we're
not
ready
to
cycle
I'd
say.
B
Essentially,
for
any
of
the
ones
that
have
100
or
more
it's
at
least
wait
until
we
hear
back
from
github,
oh
for
sure
for
sure
yeah,
which
would
hopefully
be
soon-ish,
seemed
pretty
positive
in
the
email
that
they
had
a
solution
so
cool.
Maybe
next
week.
C
10,
gentle,
I
guess
slightly
so
we're
I
guess
announcement-wise
we're
and
you
y'all
are
a
few
of
y'all
are
staring
so
you
saw
the
email
as
well,
but
we're
kicking
off
the
the
ini
oss
work
stream
next
week,
so
these
kinds
of
things
will
be
discussed
as
well.
If
anyone
is
interested
watching
the
call
later
details
on
the
inclusive
naming
mailing
lists,
as
well
as
the
working
group
naming
slack
channel.
A
Sounds
great
thanks,
even
yeah.
I
also
think
that
like
if
we
like
we're,
obviously
not
the
only
project-
that's
looking
at
doing
this
there's
another
number
of
other
large
projects
that
have
looked
to
do
this,
but
I
don't
know
necessarily
like
the
order
of
magnitude
scale
wise
that
they
that
they
are.
A
I
think
that
if
we
write
up
our
experiences
and
like
here's,
here's
the
good
things
that
that
you
know
here's
the
ways
we
kind
of
got
lucky
going
through
this
process,
here's
the
ways
that
we
like
hit
road
bumps,
here's
the
things
that
we
waited
on
as
we
went
through
the
process.
There's
things
to
be
aware
of.
D
This
this
is
actually.
This
is
actually
important
because
plan
to
kick
off
and
audit
cncf
white
for
other
projects,
besides
kubernetes,
who
are
doing
who
are
like
well,
for
example,
my
grade
rename
their
main
day
master
branch
to
maine
and
so
on.
So
if
if
there
will
be
some
best
practices
and
like
lessons
learned
and
so
on
from
kubernetes,
it
would
be
great
also
for
other
communities,
even
in
the
cncs
umbrella.
I'm
not.
B
They
have
enough
integrations
with
github.
Are
you.
D
B
Pro
yes,
mostly
because,
just
as
a
fyi
for
because
I
know,
github
actions
is
being
used
much
more
by
other
cncf
projects.
Yep.
A
Okay,
if
there's
nothing
else
on
that,
that's
the
that's
the
end
of
the
agenda
that
we
have
right
now.
We
have
three
minutes
left.
Is
there
anything
else
that
anybody
wants
to
bring
up,
or
should
we
call
it
there.
A
Okay
sounds
good
thanks,
so
much
everybody.
We
will
see
you
next
month
all
right.