►
From YouTube: Kubernetes SIG Release meeting - 2019-09-23
Description
A
Already
I'm
going
to
not
share
again
since
again
I'm
on
my
laptop
and
don't
have
two
screens
feel
free
to
open
the
doc
and
follow
along.
Otherwise,
if
somebody
wouldn't
mind
sharing
their
screen
with
the
doc,
that
would
probably
be
a
call
and
as
well
if
we
could
have
a
volunteer
for
note-taking.
That
would
be
much
appreciated.
A
Make
sense
appreciate
that
Tim
I'll,
let
somebody
else
silently,
do
it
great,
so
welcome
to
part
2
of
the
retrospective
same
rules
same
process.
This
is
a
CAF
community
meeting,
so
we
all
are
bound
to
follow
the
community
code
of
conduct.
This
meeting
is
being
recorded
and
will
be
available
on
the
Internet's,
be
good
to
each
other
and
don't
do
anything.
A
You
wouldn't
want
your
mother
to
know
about
so
picking
up
where
we
left
off
I
think
we're
gonna
have
a
little
bit
of
a
challenge
on
a
couple
of
these
items,
because
locky
is
unable
to
join
us
today,
but
maybe
one
of
his
lead
shadows
could
step
in
and
talk
about
these
two
issues.
The
first
one
was
the
non
versions.
Job
changes
that
hit
master
causing
chair
picks,
you
know
making
it
so
the
cherry
picks
it
had
to
be
manually
identified
in
the
release
branch,
and
somebody
picked
that
up
to
discuss
I,
don't
know
little.
A
E
E
B
This
sound
like
two
different
things:
potentially
there
were
some
issues
with
the
configurations
of
the
test
in,
for
so
are
some
mismatches.
Basically,
we
have
a
config
Forker,
which
you
can
apply
an
annotation
to
attest
in
for
job
and
allow
it
to
be.
When
we
run
through
the
process
of
cutting
a
new
branch,
it
basically
takes
that
job
and
mirrors
it
to
to
another
branch
right
to
another
release
branch
right.
B
So
there
are
several
jobs
that
still
remain
that
get
forked
into
the
all
branches,
but
not
necessarily
the
the
all
the
sake
release
x,
dot
y,
all
dashboards
right,
but
not
necessarily
the
the
informing
or
blocking
words
which
which
are
the
ones
that
are
important
for
CI
signal
to
be
watching.
So
that's
one
piece
and
I
think
these
two
are
separate
things
actually
so
job
changes
that
it
thanks.
B
I
think
that
that
I
think
the
second
part
of
this
is
kind
of
status
quo.
Right,
like
you,
you
know
you
have
a
you,
have
a
job
I
mean
you
have
a
PR
that
needs
to
go
into
the
release
branch
and
it's
post
and
it's
post
our
fast
forward
period.
Basically,
then,
you
need
to
cherry-pick
it.
This
is
that's
not
new
to
the
process.
Really
so
I'm,
not
sure.
B
Yeah,
that's
essentially
what
happens
so
I
think
that
maybe
there
is
some
there's
some
space
for
more
clarity
in
the
I
guess
in
the
role
handbooks,
as
well
as
the
the
branch
manager
handbook
regarding
this,
because
at
you
know,
basically
at
the
point
that
we
stop
fast-forwarding.
We
should
also
essentially
become
temporary,
like
patch
release
managers
right
sort
of
kind
of
right,
where
we're
watching
the
cherry
picks
in
the
same
way
that
the
patch
release
team
would,
until
the
release
gets
cut
part.
C
Of
this,
too,
is
beyond
just
the
release
team,
the
released
who
needs
to
understand
what
is
proposed
for
cherry
pick,
but
that
at
the
point
that
that
has
happened,
it's
it's
identifiable
but
as
soon
as
master
starts
marching
forward.
There's
a
question
of
which
of
these
things
should
be
cherry
picked
and
that
part
was
maybe
less
clear
and
then
which
of
these
things
are
targeting
a
cherry
pick
on
the
dot
zero
release
versus
the
dot.
One
release
was
definitely
unclear.
We
don't
we.
We
did
a
good
job.
C
I
feel
like
of
triaging
those
as
they
came
up
saying
explicitly:
hey.
Is
this
targeting
that's
your?
Can
wait
4.1
how
urgent
it
is
because,
like
we're
talking
about
on
Thursday,
a
lot
of
these
things
were
just
marked
priority
important,
soon
versus
critical,
urgent,
so
understanding
that
level
of
distinction
at
the
cig
level
in
master
branch
is
a
gap.
There's
no
existing
process
around
that
yeah.
B
B
F
Something
else
a
lot
of
it
related
to
this
one
is,
for
example,
there
was
a
change
in
one
of
the
performance
scale
perform
a
performance,
kill
a
performance
jobs
from
Cisco
ability
they
broke
in
Africa
Africa,
oh
yeah,
it
actually
broke
the
prison
winds,
so
we
weren't
able
to
get
the
cherry-picks
in
and
what
the
action
item
from
SiC
scalability
was
to
person
their
performance
test
a
framework.
Do
we
have
anything
similar
in
any
of
the
jobs
or
anything
that
is
related
to
the
release
cycle?
B
So
so
two
places
right
so
the
release
the
release,
repo
itself
so
kubernetes,
slash
release
is
one
place
that
we
have
been
talking
about.
There's
and
there's
an
issue
up
and
for
this
regarding
having
the
release
repo
fall
in
line
with
the
way
that
we
cut
branches
for
kubernetes
kubernetes,
so
that
we
can
maybe
decide
that
we
want
to
cherry-pick
both
that
we
want
to
fast
forward
both
at
the
same
time
so
and
then
also
start
versioning
that,
similarly
to
the
way
that
we
do
kubernetes
kubernetes
kubernetes,
so
that's
an
open
discussion.
B
I
can
find
the
link
in
a
second,
the
second
one
that
I
didn't
know
existed
until
today
was
not
today,
but
this
release
cycle
was
kubernetes.
Perf
tests
and
kubernetes
perf
tests
is
the
one
that
I
believe
is
referring
to
that
that
something
was
changed.
Maybe
I
think
a
daemon
said
was
changed
or
something
and
and
and
it
broke
up
resubmit
so
that
so
yeah
we
should
look
at
and
I
know
that
there
might
also
be
an
issue
open
for
that
one.
But
that
will
take
me
a
little
bit
to
track
down
as
well.
F
A
B
Yeah,
that's
fine!
What
I
it'll
it'll
be
a
larger
discussion,
because
what
I
would
I
don't
want
is
to
necessarily
dictate
the
way
that
another
sig
handles
their
versioning,
though
I
agree
that
there
should
be
some
sort
of
gates
to
prevent
us
from
breaking
kubernetes
kubernetes.
If
we
depend
on
that
repo,
okay,.
B
A
G
C
Should
include
the
issue
triage
person
from
one
16
and
17,
because
part
of
this
is
that
we
don't
have
issues
required
I.
Think
if
there
was
a
an
issue
in
1/16,
RCE
critical
must
fix
for
one
that
16.0
at
that
level.
It
would
be
driving
conversation
and
decision
where
today
we
completely
short-circuit
that
and
have
a
PR
and
it
merges
in
the
master.
But
there's
no
discussion
or
artifacts
of
the
discussion.
C
D
A
B
E
C
C
E
F
Just
just
just
really
quick
answering
that
so
unless
I'm
getting
the
mixed
up
with
the
context
regression
bug,
it
usually
means
performance
regression
and
the
word
the
word
couple
towards
the
end
of
code
that
were
discover
always
by
Jordan.
In
being
someone
some
other
people.
There
was
also
the
issue
we
I
think
we'd
previously
discussed,
put
six
scalability.
They
actually
discover
they
actually
recover
another
regression
book
with
updating
called
113.
So,
like
it's
something
related
to
that
process,
we
we
can
discover
some
type
of
regression.
We
discovered
regression
box.
F
B
I
think
I
would
want
some
more
clarity
on
this,
because,
like
regression,
this
coin
was
suggesting
requestion
regression
could
kind
of
mean
anything.
There
is
also
a
regression
and
testin
for
and
was
a
plank
or
something
that
we
needed
to
revert
the
test
infer
needed
to
River
to
get
a
train
rolling
again
right.
So
there
are
sort
of
things
that
happen
towards
the
end
of
the
cycle
that
were
potential
regressions
in
different
places
that
that,
like
yeah,
this
needs
to
be
better
codified
is,
is
the
short
version
I.
C
C
A
question
for
the
team
park,
part
of
the
reason
I
believe
like
there
are
people
who
say
like
release
team.
We
should
automate
it
away,
and
this
is
one
of
those
questions
like
is
there
something
here
that
is
automatable
or
is
it?
Is
this
we're
having
the
group
of
humans
here?
Thinking
critically
in
those
final
two
weeks
is
just
required.
C
B
There's
there
that
there's
a
certain
human
touch
that
you
don't
get
with
the
bots.
You
know
somehow
people
have
mentioned
automating
away
the
need
to
bug
people
on
pr's
or,
like
you
know,
so,
like
a
bot,
doesn't
do
the
same
as
you
know,
signaling
that
something
is
still
wrong
and
then
pinging
someone
on
slack
and
then
maybe
emailing
them
and
having
a
zoom
call
with
them
like
they're
there,
certain
things
that
a
bot
doesn't
have
a
touch
to
do
same
with
enhancements
right
same
with
CI
signal,
CI
signal,
like
is,
is
essentially
reading.
B
E
A
B
B
It
would
be
interesting
and
nice
and
probably
required
to
try
to
codify
some
of
what
they
do
or
how
their
that
in
tune
to
some
of
this
work
and
and
capture
that
in
and
capture
that
in
in
some
set
of
handbooks
right.
So
there
BCI
signal
and
bug
triage
and
maybe
a
little
bit
in
the
in
the
release,
lead
handbooks
for
a
future
edification.
G
Betcha,
so
this
issue,
I
got
some
feedback
when
we
were
just
about
to
post
the
release,
116
release
blog-
and
there
was
a
little
bit
of
misunderstanding
this.
It's
always
a
communications
problem
for
me
enough
in
terms
the
communications
group
and
ciencia
that
when
401,
when
the
clock
struck
four,
oh
one,
that
that
release
plug
would
be
up
and
and
ready
to
go,
and
so
I
had
explained.
You
know
with
the
embargo
that
we
had
had.
You
can't
really
post
it
before
that
time,
because
that
allows
everyone
to
take
a
look
at
it.
G
G
Or
would
it
just
be
a
great
idea
to
set
the
expectation
with
the
CN
CF
that,
even
though
the
embargo
time
is
it
is
at
this
time
we
we
will
do
our
invested
as
quickly
as
possible,
get
it
through
all
the
approvals
and
and
kind
of
not
not
through
our
process
away
or
doesn't
make
sense
to
put
the
embargo
time
a
little
bit
later
and
then
post
it
with
the
understanding
that
we'll
be
posting
it.
You
know
several
hours
beforehand,
so.
B
In
general,
try
to
follow
the
process,
but
tight
loop
with
the
scenes
he
F
I.
Ideally
no
one
is
posting
anything
until
we
have
actually
posted
the
thing
that
we
need
to
post
right.
So
if,
if
it's
not
there
at
401
or
it's
not
there
at
450,
it's
not
there
at
6:20
right
like
we
should
not
be
the
the
the
Train
shouldn't
be
in
motion,
and-
and
you
know
until
that
happens,
I
know
from
core
OS
and
red
hat
and
and
VMware.
G
I
think
no
I
do
think.
It
was
just
a
misunderstanding
because,
when
I
had
gotten
reached
out
to
was
for
one
for
two
and
was
like
where
the
heck
is
this,
that
is,
you
know
little
bit
little
bit
of
anger,
a
little
bit
of
confusion
and
and
I
said.
Oh,
that's,
that's
that's
not
the
expectation.
Here's
that
typically
works
and
so
did
just
seemed
like
a
moment
of
Education,
but
wanted
to
see
if
there's
any
other
thoughts
on
ways
that
we
can
remediate
or
update
the
process
sounds
like
it's.
B
I
think
it's
I
think
it's
fine,
as
is
there
are
also
new
people
on
comms
who
have
not
have
have
not
been
part
of
on
the
CNCs
side.
They've
not
been
part
of
the
release
flow
before
so
that's
something
to
keep
in
mind
right,
but
but
yeah,
it's
I
think
our.
If
you
think
it's
fine
I
think
our
process
is
probably
fine
to
you.
It's
just
important
on
the
release
day
that
coms
and
CN
CF
are
like
tight
cool.
A
H
So
we
got
to
literally
the
morning
of
the
release,
and
there
was
no
release
note
for
what's
a
major
feature
and
a
lot
of
people,
like
me
had
assumed
you
know
had,
particularly
with
the
difficulty
of
tracking
six
different
PRS
and
assumed
the
future
just
didn't
make
it
in
so
so.
The
to
do
here
is
that
we
really
need
to
finish
that
document
and
address
cases
like
this.
You
know
and
address
the
case
that
hey
you
know,
given
that
we
have
automation
now
it
is
far
better
to
have
too
many
release
notes
than
too
few.
H
A
H
B
Right
so
this
I
mean
this
also,
this
is
not
just
release
notes.
This
is
this
falls
into
a
little
bit
of
the
enhancement
side
too
right,
you
know,
enhancements
end
columns
right
as
a
sig.
You
should
you
should
know
what
you're
landing
for
the
cycle
right
and
that
should
have
happened
as
a
result
of
planning
for
the
cycle.
So
this
shouldn't
be
a
last-minute
surprise
or
a
someone's
on
pto,
and
we
missed
this
part
right.
There
should
be
a
constant
thing
right,
so
this
goes
back
to
the
we
need.
Sig's
need
to
be
doing
planning.
H
H
H
B
C
H
H
H
B
So
I
don't
disagree,
would
I
worry
about.
There
is
that
this
is
again.
This
is
like
the
this
is
like
the
the
bug,
triage
issue
triage
and
moving
the
milestone,
no
clearing
the
milestone
where
this
is
the
responsibility
of
the
sig
right
and
and
not
the
responsibility
of
the
enhancements
team.
What
we're
essentially
asking
the
the
enhancements
team
to
do
at
this
point
is:
do
PR
triage
as
well
and
make
sure
PRS
have
release
notes
for
enhancements
that
should
have
release
notes.
This
is
something
that
SIG's
should
know.
B
B
B
B
Yeah
is
our
documentation
tight
as
it
as
it
stands
today?
Can
we
say,
and
I
and
I
and
I
want
to
say
the
answer
is
yes,
can
we
say
that
we
have
done
enough
in
terms
of
what
is
in
the
the
PR
template
for
for
adding
release,
notes,
the
the
instructions
on
adding
release,
notes
and
any
guidance
that
we
have
across
like
community
davell,
sig
release
notes
or
wherever
it
is?
Can
we
say
that
that
documentation
is
enough?
If
the
answer
is
yes
right,
then
it
becomes
a
well
SIG's.
B
Aren't
doing
this
right,
so
it's
an
email
to
kata,
if
it's
an
email
to
say
sig
leads
to.
Let
them
know
that
they
need
to
be
watching
this
stuff.
We
also
need
to
be
aware
of
the
fact
that
the
people
who
are
lending
lending
features
that
are
parts
of
enhancements
that
are
being
tracked
for
the
release
are
not
necessarily
people
who
are
who
are
consistent
members
of
anyone's
sake
right,
so
we
need
a
like.
B
We
need
a
process
that
is
amenable
to
those
people,
and
it
doesn't
cause
too
much
friction,
but
we
also
need
to
impress
upon
the
sig
chairs
that
that's
something
that
they
need
to
work
out
need
to
look
out
for
right
again.
This
is
not
something
that
I
want
strictly
on
the
enhancements
team
are
strictly
on
the
release,
notes
team,
it's
it's
not
fair
to
them.
It.
E
I
have
read
this:
I
have
always
inferred
I've
been
reviewing
some
of
the
PRS
lately
that
come
in
about
giving
better
bot
instructions
for
release
notes,
because
we
have
a
new
release,
notes
process
right.
The
way
that
I've
seen
it
I've
inferred
that
it
is
the
SIG's
job
to
make
sure
that
the
features
they
put
in
have
docks
so
I
would
I
would
basic
I
would
agree.
I
would
sign
an
in
agreement
on
this.
Is
this
is
making
sure
we
communicate
that
it
happens.
This
is
less.
We
need
to
make
it
happen.
B
And
it's
not
just
you
know
it's
it's
it's
sick,
it's!
It's!
The
the
chairs,
the
technically
it's
the
reviewers
approvers
right.
You
know
we
have
a
process
where
you
can't
get
a
PR
in
unless
you
explicitly
say
that
it
either
has
a
release
note
or
it
doesn't
so.
The
reviewers
and
approvers
of
those
PRS
need
to
be
making
sure
that
things
that
need
to
have
release
notes
actually
do.
A
I
B
Yeah,
so
this
is,
this
is
a
Trixie
one.
It's
simple,
but
it's
hard
and
part
of
the
reason
for
that
is
because
we
have
a
disconnect
in
the
process
between
the
time
that
a
release
is
published
on
github
and
all
of
the
artifacts
of
a
release
are
published
right.
So
when
a
release
is
published
on
github,
the
the
the
release
is
actually
there,
you
can
see
the
notes.
You
can
see
the
the
SHA
sums.
B
B
Someone
are
the
release
beforehand,
someone
opened
it
an
issue,
that's
you
know
that
the
release
was
published,
but
they
couldn't
see
the
Deb's
or
rpms
right
and-
and
there
is
a
natural
lag
in
that
process
as
a
result
of
the
hand,
the
hands
that
touch
it
before
it
actually
makes
it
out
the
door
right.
So
part
of
that
we're
we're
going
to
be
working
on
for
this
cycle.
B
So
this
can
only
be
done
by
a
Googler
today
right
if
we
can,
if
we
can
do
that
within
the
community-
and
we
have
some
ideas
for
this
already,
it's
just
a
matter
of
planning
an
execution.
If
we
can
do
that
within
the
community,
then
we
can
start
to
tie
this
process
together
right.
So
there's
no
longer.
B
But
you
know,
for
me:
I
feel
that
you
know
from
the
staging
side:
staging
can
kind
of
happen
anytime
that
day
and
I
think
it.
You
know
I,
think
young
did
it
in
the
morning
his
time
and
then
release
it
release
we
try
to
do.
You
know
that
the
question
is
like
does
it
matter
when
we
do
the
release?
If
we,
if
we
know
today,
there
is
already
that
disconnect
right.
B
If
we,
if
we
start
the
release
process
at
four
as
the
blog's
going
out,
then
we
know
that
there
is
about
a
two
hour
window
between
the
time
that
the
artifacts
are
published,
at
least
the
two-hour
window.
Between
the
time
the
artifacts
are
published,
the
standard
artifacts
that
we
control
are
published
and
the
debs
and
rpms
are
public
are
actually
published
right.
So
if
we
say
that
we're
okay
with
releasing
any
time
during
that
day
and
that
the
announcement
only
happens
after
four
that
I'm
fine
with
that
too.
I
B
A
J
B
B
A
So
I
think
we
are
ready
to
move
on
to
what
we're
going
to
do
differently
and
we
only
have
about
less
than
20
minutes
left.
Let's
try
to
get
through
quick,
so
six
capability
has
a
to
do
differently.
Adding
performance
engineering
wall
to
the
release
team
for
the
breed
out
are
there.
Any
action
items
are,
or
this
is
already
action
when.
A
B
Yeah,
these
are
two
things
that
we
need
to
discuss
because
I
think
the
common,
the
common
line
for
the
last
few
releases
has
been.
We
don't
do
this
because
it's
expensive,
we
as
a
community
I,
don't
think
actually
know
the
cost
of
doing
these
tests
and
we
were
unable
to
introspect
on
the
cost,
because
it's
in
a
project
that
we
don't
own
right,
that
might
I
think
yeah.
That's
still
true.
We
have
so
so.
B
Sig
release
chairs,
have
access
to
the
kubernetes
release,
test
project
or
just
the
one
that
makes
the
the
gears
go
for
the
staging
and
release
parts,
but
I
believe
the
kubernetes
release,
dev
or
kubernetes
CI,
or
something
GCP
project.
It's
not
one
that
we
we
can
touch
in
any
way
and
that's
the
one
that
that
some
of
these
tests
are
running
on.
So
yes,
that
is
this
is
an
action
for
cig
release,
shares
they're,
requesting
additional
funding
or
figuring
out
a
way
to
introspect
on
those
tests,
the
adding
and
performance
engineering
role.
It's.
B
B
Most
of
the
action
items
from
115
and
116
stuff
that
we
had
written
from
from
Part
1,
as
well
as
part
of
Part
2,
is
already
captured
in
a
and
kind
of
an
umbrella
issue
on
github
I
think
that
one
of
the
things
that
we
end
up
not
doing
is
coming
back
to
the
retrospective
action
items
until
close
to
the
time
of
the
next
next
retrospective.
So
having
this
in
having
this
in,
the
active
project
board
is
I
think
would
be
useful.
E
B
F
B
Let's,
let's
so
that
should
be
so
between
the
release
team,
lead
and,
and
the
sig
on
the
CI
signal
lead
for
the
cycle
should
be
handling
scheduling
that
meeting
the
CI
signal
lead
can
probably
take
it.
That
meeting
should
include
scalability
chairs,
release,
chairs,
release
team,
leads,
lead
and
lead
shadows
and
say
the
CI
signal
team,
and
we
should
set
that
meeting
for
once.
The
shadows
are
set
right.
E
Know
we
problems.
I
also
know
that
we're
trying
to
address
it
I'm,
not
sure
that
having
a
meeting
is
the
correct
I
mean,
is
necessary,
I'm,
not
sure
what
what
what?
What
a
meeting
has
that,
having
a
regular
person
to
either
attend
a
release,
team
meeting
upon
invite
or
to
discuss
with
via
slack,
wouldn't
be
able
to
do
because
we've
not
had
that
either.
That's.
B
E
A
A
A
H
There
was
already
several
issues
open
on
this:
there's
both
been
working
on
the
informing
blocking
criteria
and
then
the
second
problem
is
that
when
we
branched
off
the
1/16
test
jobs,
we
discovered
that
the
code
that
creates
the
perversion
jobs
had
a
different
list
of
jobs
than
what
we
had
in
master,
and
so
that
caused
some
confusion
and
then
on
top
of
which
we're
looking
at
taking
more
things
out
of
blocking,
because
they
were
flaky
during
the
1:16
cycle
and
as
flaky
jobs.
They
shouldn't
be
in
blocking.
H
B
A
H
B
H
But
I
haven't
assigned
it
to
the
different
groups,
so
that'll
be
something
probably
looking
to
do
in
117
I'll
leave
that
up
Claire,
so
I've
finally
gotten
merged
in
a
bunch
of
general
documentation
about
what
shadowing
it
is
and
why
we
do
it
and
that
sort
of
thing,
and
so
from
here.
What
we
need
in
each
of
the
handbooks
is
a
section
that
says
what
new
shadows
we'll
be
doing
as
part
of
that
handbook
or
make
some
comments
in
that
regard.
H
The
eye
a
couple
of
hand,
books
already
kind
of
have
this,
and
we
just
want
to
get
it
for
the
rest,
so
I'll
act.
So
that
follow-up
is
on
me
because
it's
my
issue
I
need
to
go
through
and
do
the
usual
tracking
issue
thing
and
say:
okay,
here's
the
handbooks
that
have
this,
here's
ones
that
don't
the
same
as
we
did
for
time
and
qualifications
expectations.
C
A
E
A
Okay,
so
if
you're
gonna
open
an
issue
and
then
also
track
it
and
I
think
we're
good
any
other
items
that
are
not
on
the
list
going
once
twice.
Alright,
let's
call
that
a
closed
I
think
the
last
action
item
is
Stephen.
Nude
captured
action
items
into
that
tracking
issue.
Are
you
gonna
take
the
action
to
add
the
additional
ones
or
is
that
something
you
want
me
to
take?
I
I.
B
E
Just
like
you,
people
are
awesome
and
we
sort
of
and
I
know
the
really
the
retrospective
as
always
dislike
long.
You
know
drawn-out
thing
but
like
I
feel
like
we
should
all
give
us
those
big
Pat's
on
the
back,
because
we
did
a
cool
retro,
we
managed
to
stay,
we
managed
to
stay
positive
and
forward-looking
and
solution
oriented
and
all
overall,
it's
a
really
really
positive
experience
to
be
collaborating
with
everyone.
B
You
okay,
so
next
week
we
will
be
having
the
the
Wow
okay
brain
brain
fart.
The
release
engineering
meeting
in
the
same
time
thought
we
will
start
to
talk
about
some
of
the
plans
for
117
once
I
start
writing
some
of
them
down
and
I
will.
I
will
hope
that
the
release
manager
associates
the
branch
management
Pat,
release
team.
Anyone
who
is
interested
in
release
management
in
general
joins
that
call,
because
we
have
a
lot
of
work
to
do
for
117.
B
If
you
are
generally
interested
in
helping
out
on
that
stuff,
you
can
find
us
on
the
cig
release
channel
in
slack
the
release
management
channel
in
slack
as
well.
If
you
want
to
chat
about
how
you
can
contribute
and
want
to
do
that
privately
I'm,
just
a
guest,
this
on
slack
Tim,
is
here
too,
and
that's
tee
pepper
once
like
what
else?
What
else
is
there?
So
in
two
minutes
we
will
be
starting.
B
The
117
release
call
release
team
meeting
the
first
official
one,
primarily
that
is
leads
only,
but
anyone
who
is
interested
in
hanging
out
for
that
we
will
be
on
the
same
zoom
call.
So
don't
go
anywhere
or
her
or
stop
and
get
a
quick
break
and
then
then
come
back.
But
thank
you
again.
Everyone
I
seriously
like
the
the
work
that
you
all
do,
just
echoing
some
of
the
stuff
that
Gwen
was
saying.