►
From YouTube: Kubernetes Release Engineering 20200915
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,
hello.
Everyone
today
is
september
15th.
This
is
the
bi-weekly
release
engineering
subproject
meeting
for
sig
release.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people.
A
So
we've
got
a
few
agenda
items
some
some
that
have
fallen
out
of
the
119
retro,
but
I
want
to
start
off
with
some
gra
congratulations
and
some
welcoming
of
new
team
members.
A
So,
as
of
yesterday,
we've
promoted
marco
to
a
full-time
full,
fully
fledged
all
the
power
release
manager,
so
congrats,
marco,
thank
you
for
all
the
work
that
you've
been
doing.
It's
been
pretty
awesome
to
see
your
your.
You
know
the
the
the
increased
responsibility
that
you've
taken
on
over
the
past
few
cycles.
So
thank
you.
B
C
A
Awesome
so,
second
up,
we
have
added
some
new
release
manager
associates.
These
were
some
people
who
were
interested
in
the
release,
manager
associate
role
last
cycle
and,
and
they
were,
they
also
happened
to
be
leading
their
respective
roles
in
on
the
really
on
the
119
release
team.
So
without
further
ado,
welcome
adolfo
and
john
luca
to
the
team.
D
A
So
we
have
done
I've
done
some
of
the
initial
onboarding
for
you
all.
As
of
yesterday,
you
should
have
access
to
the
release
managers
at
kubernetes.io
group,
as
well
as
the
kate's
infra
release
viewers
group,
which
will
allow
you
to
view
logs
for
the
various
various
build
runs
that
we
do
for
kubernetes.
The
staging
and
release
runs
for
marco.
You
have
been
added
to
those
groups
in
addition
to
the
release.
A
Manager's
private
group
you've
been
given
release
manager,
access
on
github
teams,
which
means
you
have
right
access
over
kubernetes,
kubernetes,
now
so
great
power,
great
responsibility,
all
that
good
stuff,
your
you
should
also
be
added
to
the
private
slack
groups,
so
I'll
be
wrapping
up
the
onboarding
stuff
throughout
the
week,
they're
just
a
few
more
pieces,
but
I
wanted
to
make
sure
that
y'all
at
least
have
the
communication
groups
set
up
so
more
to
come.
A
If
you
have
questions,
please
ask
we
are:
we
are
open
books,
we
try
to
be
as
transparent
as
as
possible.
So
any
questions
as
you're
getting
ready
to
onboard,
especially
marco,
will
talk
more
about
the
role
definition
later
in
the
meeting,
so
stay
tuned.
For
that.
A
A
Awesome
awesome:
okay.
Next
up
now
that
we
have
new
personnel,
we
need
to
talk
about
personnel
for
the
upcoming
releases,
so
I
believe
tim.
You
started
the
chat
in
the
private
group
the
so
I
want
to
confirm
who
will
be
doing
the
patch
releases
for
tomorrow.
First
off.
F
A
Okay,
so
carlos
I'll
leave
it
to
you
to
coordinate
with
marco
and
sasha
and
any
of
the
release
manager
associates
that
want
to
look
over
your
shoulder
while
you're
doing
those.
A
All
right
now,
the
next
one
up
is
120
alpha
1.,
so
120,
alpha
1
is
kind
of
the
release
that
we
cut
right
before
the
release
cycle
has
officially
started,
which
the
release
cycle
has
officially
started.
So
we
should
cut
that
soon.
Is
there
anyone
interested
in
taking
that
one.
C
I
have
a
question:
should
we
maybe
leave
that
to
associates,
because
we
had
some
history
of
doing
that
before
and
that
might
be
a
good
opportunity
if
someone
wants
to
pair
and
see
if
it
can
come
up
with
something.
A
So
this
one
I'd
prefer
to
be
done
by
a
manager
and
the
ones
throughout
the
cycle
we
can.
We
can
delegate
to
associates.
A
Yes,
so
this
one
is
the
is
essentially
the
wrap
up
from
the
previous
cycle.
If
you're
familiar
with
the
kind
of
the
way
we
dance
with
the
multiple
releases
throughout
the
cycle,
depending
on
which
release
it
is,
there
may
be
multiple,
there
may
be
multiple
releases
cut
depending
on
what
type
of
release
it
is.
There
may
be
multiple
releases
cut
right
so
for
an
alpha.
There's
only
one
release
cut
and
that's
that
alpha
for
betas.
A
A
Rcs
even
are
are
single
releases
as
of
the
branch
cut
and
finally,
the
official
releases
are
both
official
as
well
as
rc's
right,
so
we'll
cut
the
so
if
you're
cutting
you
know,
120.0
120.0
will
be
the
first
release
to
cut
and
the
second
one
will
be
the
120
120.1
dash
rc
0
right,
so
it
basically
stages
the
next
one.
A
In
line
the
reason
this
one
is
a
little
special
and
for
the
alpha
one
at
least,
is
that
it's
kind
of
the
wrap
up
from
the
previous
cycle.
So
all
of
the
when
we
cut
the
120
alpha
0
for
the
120
alpha
0
essentially
happens
when
we
do
the
rc
cut
or
the
branch
creation
for
the
previous
cycle.
A
So
that
means
that
the
last
time
we've
cut
a
release
on
the
primary
branch
was
the
time
that
we
cut
the
rc
for
119.
So
there
there
are
some
catch-up
commits.
There
may
be
weird
things
I
doubt
they're
going
to
be
weird
things,
but
I
also
prefer
for
that
wrap
up
to
be
handled
by
by
a
more
experienced
release.
A
Manager,
carlos
did
you
have
something.
A
A
Now
we
had
discussed
initially
in
the
channel
that
so
carlos
was
kind
of
the
liaison
for
119,
essentially
the
requirement
being
that
you
attend
the
attend
the
release
meetings,
you
provide
status
to
the
release
team
regarding
branch
management
issues
or
duties,
and
so
we
were
going
to
have
carlos
continue
for
120,
but
now
that
we
have
marco
stepping
into
the
release
manager,
role,
I'd
like
marco
to
also
be
the
liaison
for
120.,
and
I
think
that'll
give
an
opportunity
for
kind
of
lots
of
lots
of
active
releases
under
your
belt
as
you
go
through
the
cycle
as
well
as
lots
of
opportunities
for
for
mentorship
from
the
the
senior
release
managers.
A
All
right,
so
next
up
on
the
list
is
adolfo.
I
wanted
to
talk
about
the
major
themes
in
comms
embargo.
Was
this
meant
to
be
maybe
a
sig
release,
meeting
discussion.
B
A
Okay,
do
you
want
to
do
you
want
to
pull
that
off
and
pop
that
on
to
the
other
agenda,.
B
Yeah,
this
is
regarding
a
pr
sent
on
saturday.
I
think
regarding
the
promotion
of
images.
I
don't
know,
if
that's
this
is
the
right
time
to
ask
about
that.
A
Yeah
sure
do
you
want
to.
I
was
talking
with
sasha,
I
think
a
little
bit
about
this.
Do
you
want
to
maybe
share
your
screen
and
walk
us
through
it.
B
Yeah
sure
I
wasn't
ready
for
that.
Of
course,.
B
B
Okay,
can
you
see
the
looks
like
I
got
a
lot
of
browser
windows
open?
This?
Is
the
promotion
command
pull
request
yeah,
so
basically,
what
this
does
is
that
it
takes
a
tag.
It
that's
a
new
subcommand
to
krell,
which
adds
a
tag
to
it,
and
it
takes
a
tag,
a
release
tag.
B
Then
it
takes
your
github
fork
and
it
it
will
run
in
the
background,
this
c
c
m.
B
I
don't
know
how
this,
how
to
pronounce
the
cmm
tool
to
analyze
all
the
images
in
the
repo,
and
it
will
push
a
pull
request
to
to
promote
those
images,
and
I
think
I
don't
I
may
have
a
well.
Let
me
show
you
a
little
bit
of
the
code.
What
this
does
is
it
take,
I'm
using
all
of
the
all
of
the
libraries
that
we
built
to
to
to
create
pull,
requests
and
and
push
things
back
to
github
for
the
release
notes
and
it
will.
B
B
These
these
are
promoted
to
kate's
right
now.
I
I
don't
think
I
have
an
example
of
the
output.
There
was
a
an
issue
where
that
I
saw
that
carlos
had
when,
whenever
he
was
promoting
images,
where
the
the
image
manifest
included,
the
mock
images-
and
I
got
stuck
in
that-
and
I
wanted
to
ask
about
those-
since
there
are
images
that
are
attacked
with
the
from
the
mob
run
and
the
in
the
in
the
registry-
those
are
included
as
well.
B
So
I
I
was
wondering
what
to
do
with
those
or
do
you
want
me
to
to
actually
run
the
command,
because
I
don't
have
it
yeah
go
for
it,
because
I
I
don't
have
it
in
this
computer.
A
A
All
right,
so
let
me
know
if
you
can't
see
my
screen
and
I'll
make
the
font
bigger
in
a
little
bit.
A
From
from
the
kates.io
repo
that
stores
a
bunch
of
the
kates
in
for
tools
and
I'll
just
try
to
give
you
an
example
of
what
this
looks
like
without
the
new
tool.
So
that's
that
all
right,
so
this
one
that
I'm
going
to
is
the.
A
The
container
image
promoter
repo
container
image
promoter
is
the
tool
that
we
use
across
the
across
the
across
the
community
to
do
image
promotions
from
the
kate's
community
staging
repos
into
into
the
production
area.
So
there's
a
tool
within
the
repo
called
cipm
and
eventually
release
managers,
release
engineering
subproject.
I
would
like
us
to
clean
up
some
of
the
things
in
the
sharipo.
Maybe
make
that
tool
a
little
clearer
about
what
it
does.
Cip
mm
stands
for.
A
A
I
wanted
it
to
be
kind
of
really
simple
for
a
release
manager
that
was
handling
or
really
anyone
who
is
handling
the
manifests
that
are
within
the
kate's
dot,
io
repo.
So
just
to
give
you
an
example
of
what
that
looks
like
we
have
images.yaml
right.
A
So
this
manifest
contains
a
set
of
container
image.
Digests
right
mapped
to
a
tag
right,
so
the
the
image
promoter
is
going
to
read
through
this.
This
digest
the
set
of
digests,
as
well
as
the
image
names
and
determine
what
those
images
should
be
tagged
as
when
they
get
promoted
into
production
right,
and
there
are
a
bunch
of
validation
things
that
happen
in
the
background
that
I
I
am
not
all
familiar
with,
but
this
is
an
example
of
the
build
image
set,
so
debian
base
images.
A
You
can
see
the
debian
hypercube
base
images
as
well
as
ip
tables,
go
runner
and
and
cubecross
right.
So
those
are
primarily
the
base
images
that
we
use
right,
so
it'd
be
cool.
If
we
could
take
you
know
normally,
if
I
was
to
think
of
an
image
that
I
wanted
to
to
get
some
information
on
that
was
in
a
staging
repo.
A
I
might
do
something
like
this
right,
so
gcr
g0.io,
let's
say
it's
our
we're
looking
for
build
images,
build
image,
and
I
wanted
to
get
info
on
like
debian
base
right
and,
let's
say,
buster
dash
v,
one
one,
two:
zero,
all
right:
let's
try
that.
A
Okay
right,
so
it's
gonna
spit
out
a
digest
for
me
right,
which
is
the
this
is
going
to
be
the
manifest
list
for
the
image
which
is
going
to
contain
a
set
of
manifests
for
the
individual
or
the
individual
image.
Architectures
right.
It
also
spits
out
the
repo
tags
right.
So
I
know
all
of
the
all
of
the
tags
that
are
attached
to
images
with
this
name
right
and
then,
if
I
was
to
do
a.
A
Scopio,
it's
going
to
give
me
the
the
image
manifest
list
right.
So,
if
you're
promoting
multiple,
if
you're,
promoting
a
multi-arch
image,
you're
going
to
need
information
on
one,
the
manifest
list
digest
right.
So
you
can
see
the
manifest
list
digest
for
this
tag
is
here
right:
ea
6!
A
And
then
you'll
also
see
the
we'll
have
to
put
entries
in
for
each
of
the
digests
for
the
individual,
the
individual,
architectures
right,
so
amd,
64
arm
arm,
64,
ppc,
64
le
and
then
s390x
right.
A
This
is
error
prone.
I
can
say
that
as
someone
who
has
made
errors
with
this
before
so
the
cip,
cip,
mm
tool
is
meant
to
take
a
tag
that
you
might
be
thinking
about
and
and
look
it
up.
Look
it
up
either
by
the
image
name
or
the
tags
that
you
specify
and
then
take
those
manifest,
take
those
digests
and
add
them
to
an
existing,
an
existing
manifest
for
the
the
image
promoter
right.
So
this
kind
of
simplifies
the
process
right.
A
If
I
was
to
run
this
in,
oh,
I
don't
have
the
command
at
the
ready.
Unfortunately,
but
if
I
was
to
so
I
wrote
a
janky
bash
script,
which
does
that
essentially
and
that's
promote,
base
images
right
so
cipm
based
directory
right,
specifying
where
that's
going
to
be
the
staging
repo,
the
filter
image,
so
the
image
to
filter
on
and
and
then
the
filter
tag
right.
A
So
if
I
was
to
run
this
script
from
this
directory,
I'd
get
say,
I
wanted
debian
base
and
I
didn't
want
to
give
it
so
if
I
said
debian
base
and
then
buster
v120
anything
else,
no,
okay
right.
So
this
is
kind
of
what
the
the
run
looks
like
of
cipm
right.
A
It's
it's
scrolling
through
a
set
of
a
set
of
parameters
right
the
image
names
as
well
as
the
the
tags
and
it's
looking
through
these
various
manifests
and
eventually
it
will
spit
out
something
in
this
case
it's
not
going
to
or
it
does.
Okay,
that's
interesting.
A
A
Okay,
these
are
because
so
our
in
our
staging
repo,
we
essentially
push
whenever
we
merge
changes
into
a
certain
repo.
We
push
a
tag
so
you're
also
supposed
to
bump
the
tag
if
you're
making
any
reasonable
or
any
meaningful
changes.
So
this
is
some
probably
out
of
band
change
that
doesn't
affect
the
image
that
has
changed
the
digests
right
so
but
being
that
we
haven't,
we
don't
have
anything
to
promote.
A
These
manifests
are
irrelevant,
but
this
is
just
kind
of
an
example
of
what
it
would
look
like
right.
So
normally
you
have
to
do
this
by
hand.
A
Cip
mm
takes
the
manual
miss
some
of
the
manualness
out
of
the
process
and
then
krell
promote
kind
of
extends
this
further.
So
if
we
look
at
adelpho's
pr.
A
Here
the
idea
is
that
cipm
should
be
able
to
run
within
the
context
of
our
release
process
using
krell,
which
is
going
to
further
prevent
the
manualness
of
of
it
all.
If
I
understand
correctly,
it
will
do
the
cipm
shenanigans
and
then
also
produce
a
pr
at
the
end
of
it.
Did
I
get
that
right?
A
Okay,
okay,
so
I
think
there
are
a
few.
A
few
fixes
and
sasha's
already
done
some
initial
review
here.
One
thing
I
wanted
to
discuss
before
we
move
forward
with
this.
One
is
understanding
context
right,
so
the
context
of
the
change
we
have
to
consider.
A
I
think
that
there
are
lots
of
different
things
that
the
krell
toolbox
does
or
so
for
people
who
are
not
familiar.
Krell
stands
for
kubernetes
release
toolbox
right,
so
there
are
lots
of
things
that
the
the
release
toolbox
does
at
this
point.
You
know
it
handles
and
handles
some
of
the
changelog
stuff
it
does
the
you
know,
gcp
manager,
stuff,
it's
starting
to
do
more
and
more.
A
I
think
that
it's
very
important
that
we
make
sure
that
the
the
names
for
the
commands
that
we
choose
are
properly
scoped
as
well
as
if
they
need
to
be
sub
sub
commands.
That's
something
to
consider
as
well
so
for
krell
promote.
I
don't
know
what
it's
promoting,
so
I
would
say
it's
you
know
it's
doing,
release
image,
promote
or
something
right,
so
just
just
just
to
provide
context,
because
the
you
know
eventually
we're
going
to
be
looking
at
doing.
A
Gcs
promotion
right,
artifact,
artifact
promotion
that
are
within
the
various
gcs
buckets
right.
So
we
have
to
talk
about
how
to
do
that,
but
we
also
will
need
a
promotion
command
for
that
right.
So
I
want
to
make
sure
that
the
we
don't
collide
in
that
namespace
before
certain
commands
exist.
So
I
think
that's
my
primary
review
point
for
this
pr,
but
I
think
it
looks
awesome.
B
So
maybe
promote
images
or
something
like
that:
yeah
yeah
and
well
the
other
half
about
it-
is
that
I,
when
I,
when
I
first
did
the
first
trial
runs
of
it.
I
saw
those
smoke
images
being
included
in
the
manifest
right,
so
I
wanted
to
know
where,
should
we
focus
our
efforts
to
fix
that?
B
So
I
was
thinking
in
maybe
three
places
I
could
add
some
logic
to
to
to
crail
to
skip
those
which
doesn't
seem
the
best
of
things
I
actually
maybe
had
batched
the
cipm
tool
or
maybe
deeper
in
the
release
process.
I.
A
Don't
know
so
yeah,
so
some
context
on
the
mock
images.
Essentially,
what
we're
trying
to
do
is
make
sure
that
it's
it's
hacky,
I'm
gonna
be
honest.
It's
it's
a
little
hacky.
I
I
tossed
that
in
so
that
we
could
still
do
some
validation,
so
you've
you've
worked
on
the
image
kind
of
validation
scopio
bit
as
well.
A
A
We
want
to
make
sure
that
the,
when
we're
doing
official
stages,
we're
promoting
to
the
official
place
that
they
need
to
live
right
or
we're
we're
landing.
Those
images
in
the
staging
repository
right,
which
then
needs
to
be
promoted
into
real,
prod
right,
but
we
need
kind
of
an
analog
on
the
mock
side
right,
so
the
analog
is
having
them
in
that
slash
mock
directory.
A
A
B
A
A
B
A
G
After
we
before
we
transition
to
the
next
thing,
I
have
a
quick
question:
that's
unrelated
stephen
yeah,
cool
okay.
So
in
the
chat
we're
talking
here
about
the
alpha
release-
and
I
was
wondering
are-
are
we
doing
one
tomorrow
right
now?
Well,
we
were
talking
about
a
number
of
things
number
one.
G
Should
we
do
one
tomorrow
and
then
number
two,
the
cadence
for
the
alpha
releases
on
the
schedule:
they're
not
like
in
a
uniform
cadence,
as
in
like
there's
different
durations
between
each
alpha
release,
and
we
were
just
wondering
about
the
protocol
for
for
establishing
those
on
the
release.
Calendar.
I
I
just
dropped
a
thread
just
to
discuss
that
in
the
sig
release
channel,
but
those
dates
came
from
the
original
like
they
were
based
on
what
was
in
the
119
schedule
originally,
and
I
asked
in
the
pr
if
those
dates
were
fine
and
didn't
get
any
feedback,
so
we
can
tweak
them
now.
I
think
let's
just
come
up
with
what
they
should
be,
so
we
can
update
the
doc
correctly.
G
J
A
Cool
yeah,
so
the
I'm
not
sure
that
the
I'm
not
sure
if
the
dot
one
is
is
in
the
schedule.
If
that's
what
you
just
said,
I'm
sorry
I'm
like
going
through
the
chat
as
well.
G
Yeah,
it's
not,
I
think
it
hasn't
been
for
the
past
releases
either
yeah.
A
So
yeah,
so
the
dot
one
is
intended
to
be
kind
of
like
a
post
release
act,
it's
listed
as
a
post
release
activity
for
for
the
previous
release.
So
it's
an
intended
that
it's
usually
happening
before
the
schedule
is
even
generated
for
the
next
release.
A
G
A
We
do
it
tomorrow,
yeah,
we
can
do
it
whenever
we
can
do
it,
whatever
the
so
I
had
hoped
to
get
a
few
more
things
in
to
for
that
dot.
One,
including
the
go
one.
Fifteen
two
update
that
stalled
out
on
some
basil,
things,
which
I
think
right
you're
almost
at
the
end
of,
but
I
would
say
I
would
say,
go
for
it.
G
Yeah,
the
the
the
reason
for
doing
it
tomorrow
would
be
that
alpha
2
is
scheduled
for
next
week.
So
you
know
if
we,
if
we
want
any
diff
there,
we
could
also,
you
know
just
bump
them
all
later.
G
I
leave
it
to
you
all
that
sounds
fine
to
me.
I
mean
I
don't
think
we're
like
you
know.
If
you
have
a
few
things
that
you
would
like
to
get
in
and
that
sort
of
thing
I
think
we
could
just
bump
them
all
one
one
if
people
are
cool
with
that.
A
Yeah,
so
that
sounds
like
a
task
for
release
managers
as
well.
If
you
want
to
take
a
look
at
where
we
currently
have
the
the
various
releases
in
the
schedule
and
see
if
the
cadence
makes
sense.
A
We're
at
inago
sasha:
do
you
want
to
talk
about
inaugural
a
little
bit.
D
Yeah,
so
we
have
two
main
topics
about
anago
and
the
first
one
is
the
migration
from
anna
go
to
krell
and
we
drafted
a
little
road
map
which
is
linked
there
for
transparency
reasons,
and
we
don't
have
a
decision
on
that
roadmap
yet.
But
I
created
a
bunch
of
issues
how
to
move
forward
on
the
current
recreation
and
which
parts
of
energo
can
be
converted
into
galling,
based
sub
commands
of
something
like
rel
energo
and
then
like.
We
do
it
with
the
set
release
version
which
is
currently
in
place.
D
D
Oh
yeah
and
let
me
share
my
screen
so
like
this,
so
what
I
basically
did
is.
I
just
went
to
anago
and
looked
at
the
huge
amount
of
bash
we
still
have
left
in
and
then
I
carved
out
some
pieces
of
bash
and
put
them
into
some
logical
conjunction.
For
example,
if
we
look
at
the
retrieving
the
build
candidate
there's
a
fair
amount
of
bash
code.
D
So
and
then
I
go
it's
right
right
around
this
one
and
also
some
other
functions
like
this
fast
forward
check
and
the
main
idea
is
now
to
build
a
krell
sub
command
as
part
of
corelgo,
which
actually
does
exactly
the
same
logic
and,
for
example,
for
that
build
version.
I
did
it
like
this
that
we
can
go
to
the
sub
command.
D
And
it
looks
it's
a
release
version.
Actually
I
mix
them
up
every
time
and
yeah
that
we
use
the
same
inputs.
So
we
have,
we
need
a
build
version,
we
need
a
branch,
we
need
a
parent
branch
and
and
then
we
generate
a
little
piece,
just
a
little
piece
of
patch,
which
will
be
then
just
sourced
by
energo
and
that's
it
and
the
only
thing
we
actually
do
here
is:
we
call
out
to
set
release
version
up
there
and
later
on.
D
If
we
have
cradle
stage,
for
example,
and
krell
release-
and
it's
just
create
a
stage-
I
think
so-
then
we
can
remove
this
whole
sub
command
and
only
use
those
lines
for
setting
the
release
version.
D
Yeah,
we
don't
do
refactoring
and
converting
from
bash
to
go
in
one
step,
so
this
is
a
two-step
approach
to
in
the
first
place,
implement
something
in
batch
in
in
golang,
which
replaces
which
should
replace
some
piece
of
bash
and
later
on,
we
refactor
on
top
of
that.
So
we
already
have
tests
in
place
then,
and
then
we
can
safely
switch
over
to
something
new
and
that's
the
whole
strategy,
and
the
same
applies
to
the
other
issues.
For
example,
we
have
the
same
for
updating
the
github
release,
which
is
currently
not.
D
I
mean
we
have
some
github
api,
but
this
api
has
to
be
extended
to
actually
update
the
github
release
for
the
kubernetes
release,
and
then
we
have
credit
push
which,
which
is
not
in
production,
used
right
now,
but
we
have
a
fair
amount
of
code
which
lays
around
in
k
release,
and
the
idea
is
to
finish
that
up.
I
assigned
myself
that
task,
but
there
are
still
some.
There
are
still
some
open,
open
pieces
left
and
then
we
have
the
same,
for
example,
for
pushing
to
get
objects.
D
I'm
not
sure
if
every
issue
is
already
a
sign.
Let
me
just
double
check
so
this
one,
for
example,
for
pushing
the
git
objects
is
not
assigned
yet
and
the
one
for
updating
the
github
release
is
assigned
to
marco,
and
this
one
is
for
the
build
candidate.
I
mean
this
is
a
little
bit
more
complex
to
be
honest,
and
it's
not
trivial
also
during
review
on
those
tasks.
D
D
So,
as
tim
on
the
call,
let
me
just
stop
sharing
I'm
here
yeah,
so
tim
had
a
proposal
that
we
move
on
over
from
order
to
create
something
like
a
feature
branch
and
currently
start
with
some
yeah
with
crest
stage
and
crail
release
right
now.
We
can
do
that
in
parallel.
D
If
we
keep
in
mind
that
we
still
have
some
open
conversions
left,
but
I'm
not
sure
how
long
it
will
take
until
we
get
something
actually
working,
because
testing
would
be
mainly
running
running
it
in
gcp
and
trying
to
build
a
release
right.
A
A
The
suggestion
around
having
the
inago
sub
commands
was
so
that
we
could
essentially
wash
our
hands
of
them
when
we're
done
right
so
similar
to
like
a
cube,
adm
alpha
phase
situation
right
where,
if
the
new
flow
is
kind
of
ensconced
in
these,
these
alpha
commands-
or
these
inaugural
commands,
that
we
can
do
a
krell
inaugural
stage
or
something
like
that
right.
A
H
H
A
Worked
as
long
as
it's
not
going
to
production,
I
think
it's
fine,
so
the
first
part
of
the
flow,
the
first
part
of
the
flow
we
can
absolutely
test
the.
I
think
you
know
it
gets
harder
when
we
flip
on
the
the
official
flag
right
or
the
no
mock
flag,
because
the
there
are
restrictions
about
where
we
can
place
artifacts.
A
So
the
kubernetes
release
test
the
gcp
project
has
access
to
right
into
the
kubernetes
release
buckets.
However,
the
gcp
project
that
we
should
be
using
the
kubernetes
staging
kubernetes
project
does
not
have
access
to
right
into
either
of
those
buckets,
and
the
reason
for
that
is
that
those
are
google
owned
projects
right.
The
the
old
buckets
are
google
owned
projects,
so
you
know
as
a
wider
effort
we
need
to.
A
I
think
this
cycle
is
a
good
time
to
start
talking
about
what
the
gcs
promotion
situation
looks
like,
because
we've
we've
essentially
it's
essentially
been
solved
for
container
images,
but
not
for
gcs
artifacts.
H
We
could
do
a
fair
amount
of
testing
over
the
coming
months
in
the
mock
path
and
then,
if
we're
ready
in
january-ish,
we
could
try
doing
some
actual
alpha
releases
from
it.
We'd
have
the
two
of
them.
We
could
make
a
alpha
one
with
the
one
tool
alpha
two
with
the
other
tool,
do
a
little
bit
of
back
and
forth
a
b
testing
at
the
alpha
point.
If
we're
not
ready
we'd,
depending
on
the
cadence
three
to
five
months
later,
we'd
have
the
the
next
opportunity
to
to
do
some
alpha
builds.
H
A
Yeah
sounds
reasonable,
so
so
sasha,
a
few
things
on,
do
you
mind
popping
up
your
sheet
one
more
time.
A
So
a
few
things
I
wanted
to
mention
here,
I
think,
there's
a
pr
open
for
the
retrieving
build
candidate.
I
think
there
was
a
name
change
to
one
of
the
functions
or
the
sub
command
name
that
actually
made
it
more
confusing.
For
me,
the
I
think
it's
the
set
release
version,
one.
D
Oh
yeah,
I
set
release.
A
A
So
that's
one
note
there
and
then
for
the
push
commands.
I
know
that
I
know
that
you're
staring
at
it.
I
know
that
I
know
that
dan
was
staring
at
the
push
commands
in
the
past.
We
need
to
be
very,
very
careful
with
krell
push,
because
krell
push
is
responsible
for
pushing
all
builds.
Not
just
you
know,
so
the
ci
builds
as
well.
So
if
we
write
a
tool,
the
tool
needs
to
be
usable
in
ci.
So
you
have
to
consider
all
the
paths
that
it
might
take.
A
D
Yeah,
okay,
all
right
so
do
we
want
to
add
something
to
this
whole
plan
that
we
want
to,
for
example,
my
proposal
would
be
now
we
start
in
parallel
with
something
like
krell
stage
and
test
it
directly
in
gcp
and
yeah.
In
any
case,
we
would
need
those
functionalities
down
here
like
something
like
updating.
The
github
release
would
be
needed
in
any
case,
so.
A
Right,
whatever
we
name
it,
let's
make
it
very
clear
that
it's,
let's
make
it
hard
to
do
wrong.
So
let's
make
it
very
clear
that
this
is
a
pre-release
command
or
an
alpha-ish
command.
So
if
we
need
to
name
it
krel
anago,
alpha
or
krell,
alpha
anago,
something
yadda
yadda,
make
it
hard
to
get
to
and
make
it
hard
to
be
used
a
little
harder
to
be
used
in
the
official
flow.
For
now.
A
Yeah
yeah
I
mean
we
can
do
that.
I
think
I
think
everything
I
think
if
we
were
to
ensconce
everything
in
a
sub
command
that
would
do
it,
but
but
yeah
we
could
look
at
doing
enable
you
know
enable
features,
or
you
know
some
feature
flag
name.
A
A
That,
okay,
all
right,
so,
let's
jump
to
marco,
tell
us
a
little
bit
about
the
role
definition
work
that
you've
been
doing.
C
Yeah
so,
as
announced
or
our
last
recent
generation
meeting
two
weeks
ago,
I
have
started
looking
into
some
role.
Definition
work
around
the
list,
manager
associate
and
trying
to
get
a
more
detailed
definition
and
some
set
of
documented
responsibilities
of
associates,
and
so
far
I
can
say
that
we
have.
We
probably
don't,
have
a
lot
of
habits
and
progress
so
far,
but
I
had
been
in
contact
with
laurie
and
the
team.
I
have
collected
some
feedback.
C
One
of
the
first
thing
is
that
by
the
end
of
the
next
week,
or
in
two
weeks
we
are
going
to
have
a
meeting
I
am
going
to
send
out
doodle
today,
then
dan
is
going
to
hold
the
meeting
that
he
is
going
to
do.
Some
release
manager,
release
manager,
associate
intro
and
we
are
going
to
have
a
time
for
some
q
a
sessions.
So
you
as
an
associate
can
come
and
you
should
probably
come
if
you
are
able,
we
are
planning
to
record
the
session
but
anyways.
C
It
is
probably
a
great
time
that
you
ask
any
questions
that
you
have
and
we
will
try
to
come
up
with
answers
and,
as
I
said,
I'm
going
to
said
that
after
the
meeting
and
besides
that,
I
am
looking
to
try
to
come
up
with
some
document
to
try
to
collect
some
of
the
tasks
that
we
have
been
doing
recently
and
collect
some
relevant
prs
descriptions.
Is
there
any
documentation?
C
K
Oh
sure,
so
I
just
put
the
link
in
the
agenda
and
also
shared
everything
on
the
channel
yeah.
I
did
this
morning.
Sorry
there's
a
lot
going
on,
but
basically,
how
do
we?
How
do
we
get
team
spirit
in
this
group
like
how
do
we
have
a
teami
feeling
where
we
know
that
we
all
are
driving
the
agenda
together
as
a
group?
So
to
do
this
requires
all
of
us
to
kind
of
just
be
mindful
of
how
these
meetings
are
run.
K
So
this
might
mean
you
know
if
we
have
an
issue
or
a
question
or
a
need,
we
bring
that
to
the
meeting
and
we're,
if
we're
concerned
about
how
to
do
that,
then
we
reach
out
for
guidance
to
structure
the
question
or
the
need
or
the
proposal
and
then
when
we're
trying
to
communicate
with
each
other.
Like
do
we
use
dms?
K
So
the
idea
here
is
to
see
if
we
can
just
draft
a
very,
very
lightweight
ways
of
working
agreement
that
spells
all
of
this
out,
so
that
it's
creating
a
kind
of
a
uniform
culture
for
this
group
and
how
we
like
to
communicate
how
we
like
to
structure
the
meetings,
how
we
like
to
make
sure
that
the
meetings
cover
the
right
topics
from
everyone.
So
those
things-
and
we
can
do
this
asynchronously
it
might
be
easier
to
do
in
person.
K
K
Does
anybody
think
this
is
a
stupid
idea,
like
I
always
work
with
what
is
bad
or
wrong
and
then
knock
out?
What
would
what
would
block
us
from
doing
something
so.
K
J
Stupid
either,
and
actually
I
think
it's
really
good,
because
I
think
I
can
tell
you
about
my
experience
and
we
talked
a
little
bit
and
I'm
actually
super
thrilled
that
now
I
have
like
friends
with
me
and
release
associates,
because
it
was
very
hard
for
me,
like
for
personal
reasons,
but
also
like
in
general
to
to
know
what
to
do.
J
You
know
because
and
not
not
even
technically
speaking
and
like
just
what
to
grab
and
like
what
was
I
able
to
grab
on
or
you
know
there
were
so
many
things
happening
at
the
same
time
and
like
on
my
side,
I
was
super
busy
with
other
things
that
it
was
super
hard
for
me
to
to
just
come
and
and
adopt
an
issue.
J
I
I
usually
have
a
lot
of
time
spare
time
but
like
in
that
spray
time,
just
just
work
on
it
and
instead
of
that,
it
usually
required
a
lot
of
triaging
and
all
that
which
I
am
not
saying
that
it
should
be
like
black
or
white
or
very
binary.
Of
course
you
have
to
talk
to
people
and
stuff
like
that,
but
I
think
that
that
was
the
main
issue
that
we
talked
about
in
other
meetings
so
and
yeah.
J
At
some
point
I
was
officially
like
the
the
only
kid
I
made
with
marco,
but
he
did
an
amazing
job
but
yeah
we,
we
didn't
have
like
a
structured
program
before.
K
K
J
So
I
think
that
with
the
number
of
people
it
might,
this
is
just
my
guess
that
it
might
be
hard
to
coordinate
all
the
schedules
every
single
time,
so
maybe
like
obviously
strive
for
that,
but
not
making
it
the
main
priority.
So
maybe
having
in
mind
keeping
in
mind
that
some
someone
at
least
wants
will
be
async
so
like
having
that,
like
that's
a
priority
that
this.
This
is
my
point
of
view.
Of
course,
I'm
open
to
others.
K
K
So
if
you
really
want
to
get
involved
in
defining
how
this
group
works,
go
to
go
and
put
a
note
in
the
slack
channel,
that
would
be
my
suggestion
and
then
you
will
be
called
upon
to
not
necessarily
do
more
work,
but
you
know
to
invest
in
the
outcome,
making
sure
there's
an
outcome
right
and
participating,
which
is
basically.
K
H
I
think
that's
one
of
the
key
notions
to
splitting
things
out
and
in
general,
just
having
effective
meetings,
the
more
you
can
do,
asynchronous
the
less
you
have
that
has
to
be
in
the
synchronous
meeting,
but
understanding
that
it's
almost
sort
of
a
hierarchy.
There's
there's
things
where
you
once
you've
established
something
within
a
set
of
people
you,
if
that
was
in
a
slack
dm.
You
bubble
it
out
into
the
slack
channel
and
say
hey.
H
We
just
have
this
idea,
what
do
others
think
or
you
bubble
it
out
into
github
and
and
maybe
they're
the
the
goal
at
github
isn't
to
get
the
pr
merged
is
to
get
a
discussion
started.
So
there
can
be
a
trade-off
in
velocity,
or
maybe
you
slow
down
a
little
bit,
but
that
brings
in
more
people's
voices
and
more
people
come
to
have
some
understanding
of
it.
H
It
may
mean
pausing
on
something
for
a
day
or
two
just
to
get
a
couple
to
proactively
pull
a
couple
of
other
people's
review
or
opinion
or
thoughts
and
and
build
out
the
team,
so
things
might
at
times
feel
slightly
slower,
but
then,
if,
if
a
few
people
are
like
well,
maybe
this
is
confusing.
Let's
get
some
more
people,
let's
bring
it
to
to
take
five
or
ten
minutes
on
the
agenda.