►
Description
[SIG ContribEx] GitHub Administration Subproject Bi-Weekly Meeting for 20210401
A
B
Yeah
I
just
wanted
to
like
touch
base
on
the
remaining
items
that
need
to
be
done
for
the
most,
like
broadly
announcing
the
master
to
my
main
migration.
I
know
there
are
a
bunch
of
things,
but
just
wanted
to
talk
about
it,
because
it's
all
over
the
place
and
I'm
a
little
confused
where
we
stand
at
right
now,.
C
Assuming
that's
done,
then
it's
basically
sort
of
a
lot
of
coordination
toil.
I
was
really
hoping
to
try
and
reduce
some
of
that
by
updating
any
jobs
that
use
bootstrap
and
any
jobs
that
use
pod
utils.
They
many
of
them
are
both
hard-coded
to
the
master
branch
name
and
in
an
ideal
world.
We
would
update
both
of
those
utilities
to
support
cloning
from
the
default
branch
and
just
have
it
magically
work.
C
C
I
think
I'd
also
expressed
some
concerns
about
having
sort
of
like
the
key
or
core
repos
whatever
in
a
mismatched
branch
state.
Maybe
that's
just
me
being
a
little
obsessive,
but
in
terms
of
in
terms
of
muscle
memory,
I
have
found
it
frustrating
in
the
past
to
bounce
between
repos,
one
of
them's
on
main
and
one
of
them's
on
master,
and
so
that
was
really
the
only
the
main
reason
I
was
pushing
back
on
renaming
kubernetes
communities
branch.
But
if
you
don't
think
that's
a
problem,
we
could
totally
do
that.
C
B
C
C
C
A
M,
my
suggestion
would
be
number
one.
I
don't
think
we
can
going
back
to.
The
original
question
is
like
broadly
announcing
the
docs.
I
don't
think
we
should
do
that
until
we've
done
the
confirm
that
we're
not
going
to
launch
a
ci
store
with
anything
once
we've
once
we've
done
that
and
confirmed
that
what
github
has
told
us
is
like
correct
and
we're
not
going
to
re-trigger
every
job.
By
doing
this,
then
sending
the
docs
out
there,
as
is
with
the
caveats
of
hey.
A
A
I
think
I'm
interested
where
those
hard
codings
are
because
that
might
that
might
be
something
that
I
could
figure
out
a
few
cycles
to
go
and
correct,
because
I
dug
into
those
those
pieces
of
testing
for
before
on
the
user
standpoint
and
like
syncing
up
all
the
repos
together,
I
don't
think
we
necessarily
need
to
do
that.
I
put
somewhere
now
I
put
it
in
a
gist,
and
I
think
I
linked
that
just
from
the
other
docs
and
then
I
was
gonna
like
eventually
put
it
in
our
migration
dots.
A
A
The
last
point
being
on
core
repos,
so
repos
that
are
delivered
as
part
of
the
kubernetes
release,
bundle
or
are
tagged
as
part
of
the
kubernetes
release
process.
So
I'm
thinking
the
core
repo
and
all
the
staging
repos
at
the
very
least,
but
any
repo
that
kind
of
fix
that
criteria
has
either
released
as
part
of
the
release,
bundle
or
tagged
as
part
of
the
release
process.
I
think
those
should
move
all
together
and
the
timing
around
when
we
move
those.
A
I
think
we
should
like
set
a
set,
a
a
target
date
and
then
start
announcing
over
and
over
what
that,
what
that
date
is
and
make
sure,
and
and
through
that,
solve
the
unknown
the
unknown
dependencies,
because
I
know
yeah
like
go
to
that
to
that
example.
I
know
my
employer
also
on
a
regular
basis,
clones
down
and
replicates
the
main
kubernetes
repos,
but
we
can't,
I
would
say
we
can't.
We
can't
predict
in
all
the
different
ways
that
everybody
might
be
doing
this
like
some.
A
C
D
C
Activity,
it
could
be
yeah,
I'm
sorry!
I
don't
want
a
solution
here
here.
I'm
just
trying
to
sort
of
give
give
us
a
gut
check.
I
do
think
a
good
healthy,
honest
conversation
with
sick
release
is
necessary.
So
quick
data
point
yeah
brow
doesn't
get
retriggered
anymore
yay,
so
that's
one
big
technical
block
down.
I
could.
I
could
potentially
see
how
we
could
look
into
having
like
a
post
submit
job
in
the
world
where
we
migrate
to
a
new
branch.
C
We
could
have
something
continue
to
keep
the
old
branch
around
and
just
sort
of
sync
it
with
maine.
I
don't
know
if
it'd
be
too
weird
and
racy,
but
that
might
allow
us
to
act
with
some
sort
of
deprecation
window
for
that
big
old
repo,
while
allowing
everybody
upstream
to
continue
to
develop
against
the
branch
name
that
we
as
a
community
have
agreed
upon,
and
that's
all
I'll
say
about
that.
A
I
would
caution
against
that
from
the
perspective
of
like
if
people
are
developing
like
or
a
scripting
against
a
branch
that
we're
no
longer
accepting
prs
for
then
like
it
just
gets
tricky
when
people
are
opening
prs
like
do
I
open
against
master,
do
I
open
against
maine?
I
I
don't
know
I
don't.
I
don't
know
whether
the
potential
contributor
pains
there
would
be
worth
it
as
far
as
like
fixing
other
folks,
automation,.
C
A
The
one
other
action
that
I'd,
maybe
call
out
would
be
like.
Maybe
we
just
send
an
email
to
sig
release
and
say,
like
hey,
sig
release,
you
know
we're
thinking
about
timelines
here.
Do
you
have
any
suggestions,
like
122
123,
like
what?
What
what
what
is?
What
is,
what
is
the
thing
that
got
checked
or
I
think
bob
was
suggesting
end
of
year,
so
124.
A
Can't
operate
in
a
three
release
world
until
we're
actually
there
which
we're
not
there
yet
so
until
everybody
agrees
on
a
pre-release
world,
we're
in
a
four
release
mode
right
now,
so
124
calling
yeah,
that's
24.!
So
but
like
for
this
initiative,
are
we
looking
at
a
122,
a
123,
a
124
or
beyond,
like
how
does
a
release
team
feel
about
that
and
get
their
pulse.
C
A
My
suggestion
would
be
to
start
the
conversation
by
email
get
the
gears
turning
over
there
allow
sid
release
an
opportunity
to
like
the
stuff
that
themselves
and
then
we
can
kind
of.
If
we
need
to
do
like
high
bandwidth
things
between
our
group
and
their
group,
we
we
can,
but
at
least
get
it
like
hey.
This
is
the
thing
get
it
on
your
agenda.
Talk
about
it
because
we
don't
know
whether
we're
talking
about
this
again
in
a
three
month,
a
six
month,
a
nine
month
or
a
longer
time
frame.
A
B
C
B
D
E
C
Yeah
real
quick,
the
only
other
thing
that
is
falling
off
of
my
cube,
where
I'm
trying
to
get
it
back
up
is
reviewing
the
sort
of
go
rewrite
of
the
org
member
pruning
tool.
I
know
I
dropped
an
earlier
view,
so
I
probably
owe
a
follow-up
review
bob.
Have
you
had
a
chance
to
take
a
look
at
it?
Do
you
want
to
take
a
look
at
it.
D
C
Fine,
it
might
be
for
me
too,
but
I
I
really
don't-
enjoy
a
new
contributor's
first
experience
with
this
project
being
the
latency
that
it
is,
but
it's
also
kind
of
the
way
this
project
runs
for
really
highly
bandwidth
stretched
people.
So
I'm
trying
to
be
like
a
little
nitpicky
about
operational
concerns
and
maintenance
concerns,
but
I'm
trying
not
to
go
overboard
and
sort
of
compromise
towards
a
merge
and
iterate
type
of
thing.
For
me,
it's
like
I
want
to
under.
C
I
would
be
comfortable
enough
running
this
tool
myself.
I
just
feel
like
since
you're
the
author
of
the
original
script-
bob.
Maybe
you
should
have
a
saying,
but
if
you're
comfortable
not
having
that
say,
that's
that's
fine
by
me
too.
I
just
want
one
more
pair
of
eyes
to
say
yeah,
it's,
let's
air,
towards
virgin
area.
A
If
it's
something
that
you
know
if
we're
dealing
with
a
whole
bunch
of
like
bandwidth,
strapped
maintainers,
if
the,
if
the
iterations
are
things
that
are
going
to
be
painful
down
the
road,
then
it
might
not
be
worth
merging.
I
don't
know
if
that
applies
to
this,
this
particular
pr
but
yeah.
It
depends
on
like
how
painful
those
those
iterations
will
be
and
how
how
soon
somebody
will
have
time
to
look
at
any
iterations
that
might
need
to
happen.
D
C
I
wonder
what
that
is.
I
think
that
was
still
the
meaning
that
shouldn't
yeah,
I
I
did
kind
of
want
to
get
to
the
bottom
of
that
because,
like
it
shouldn't,
I
wonder
if
that
means
the
ammo
is
formatted
in
a
way
that
the
tooling
doesn't
expect
and
then,
when
the
tooling
renders
out
the
ammo.
If
we
could
do
like
that,
big
re-render
first.
C
Right,
I'm
really
trying
to
approach
this.
From
the
perspective.
I've
been
gaining
as
I've
been
iterating
on
k-10
for
tooling,
where
I
just
really
want
sort
of
a
concise,
here's,
what's
being
removed
and
here's
what's
being
added
output,
ideally
as
a
dry
run
feature
and
then
also
when
running
live.
So
as
long
as
the
output
kind
of
makes
sense.
Within
that
context,
I
don't
have
large
concerns,
but
I'll
figure
out
how
to
get
us
there.
C
The
other
thing,
I'm
thinking
of
as
I'm
looking
at
the
blocked
column
of
the
board,
is
sort
of
the
repurposing
of
kate's.
Merge
robot
is
kate's
github
robot.
We
did
rename
an
account
to
get
kate's
github
robot
a
long
time
ago,
but
I
don't
currently
know
what
the
password
is
to
log
in
as
that
account
we
talked
about
this
at
case
info
the
other
day,
I'm
gonna
see
if
I
can
figure
that
out
worst
case.
B
C
I
would
maybe
throw
label
sync
under
this
as
well,
but
any
of
the
things
that
currently
show
up
on
the
org
dashboard.
I
want
all
those
jobs
to
run
over
in
kate's
intro.
I
think
that's
a
reasonable
confirmation
that
we
got
sort
of
a
gh
proxy
instance
set
up
and
we
can
handle
that
kind
of
load.
And
then
you
know,
management
of
the
community
is
done
from
community-owned
resources.
B
B
C
Will
try
to
connect
with
you
about
the
detail,
details
of
that
because
at
this
point
I
just
will
just
run
that
on
the
community
cluster
too,
and
that's
something
where
I
do
have
access
to
the
secrets
and
I
can
sort
of
troubleshoot
it
the
testing
for
online
folks.
Don't
necessarily
have
the
time
to
take
us
deeply
into
this
stuff.
Sometimes.
A
A
But
to
enable
this,
it
basically
means
we
need
to
rotate
all
of
the
tokens
in
our
automation,
which
is
a
lift,
especially
if
we
don't
have
access
to
all
the
accounts
offhand
for
a
plugin,
but
just
some
some
something
to
think
about
like
if
we're.
If
we're
getting
into
these
accounts,
if
we're
doing
maintenance,
it's
probably
a
good
idea
to
like
invalidate
all
the
current
tokens
and
do
a
rotation
anyways
because
of
this
added
benefit.
C
C
So
I
broke
the
I
poked
the
proud
channel
and
I
think
if,
if
we
need,
if
we
need
discussion
about
this,
I
would
say,
try
and
get
it
on
this
testing
meeting
or
just
I
don't
know,
make
sure,
there's
an
issue
open
in
the
testing
for
repo
and
we
can
we
can
sort
of
iterate
on
whether
that
changes
anything.
You
might
be
aware
at
some
point.
In
the
past
we
updated
prowl,
the
the
proud
team
updated
it
so
that,
like
it
automatically
rotates
hmac
tokens.
C
I
can't
remember
if
it's
also
automatically
rotating
github
tokens
or
not,
but
maybe
that
is
a
thing
that
it
could
do
so
let
them
know
because
I
agree
this
would
be
cool
and
I
am
at
time
I
have
to
go
now.
It's
been
really
wonderful
to
see
you
all.
I
will
try
to
start
milestone
things
over
to
v122
when
I
get
time
to
refresh
the
board,
I'm
going
to
try
to
do
that
today.
As
I
wrap
up
the
slacking
for
thing-
and
I
can
see
you
all
online.