►
From YouTube: Weekly Kubernetes SIG Release for 2/24/2020
Description
Weekly Kubernetes SIG Release for 2/24/2020
A
Welcome
everybody:
this
is
the
sig
release
meeting
for
February
24th
2020.
This
is
a
recorded,
kubernetes
community
meeting.
We
ask
that
everybody
adhere
to
the
kubernetes
code
of
conduct,
the
meetings
being
recorded
and
it
will
be
uploaded
to
YouTube.
After
the
fact,
we
have
a
Google
Doc
running
with
agenda
items
and
we'll
be
taking
meeting
minutes.
Also
it
just
got
pasted
by
multiple
of
us
into
the
zoom
chat.
If
you
don't
have
it,
it's
also
accessible
from
the
the
master
cyclists
in
kubernetes
community
repo.
A
If
you
could,
please
throw
your
name
into
the
list
of
attendees.
That
would
be
awesome
and
we
could
use
oh
I
take
the
back.
As
you
can
say,
we
use
a
note-taker,
but
Bob
Gillan
has
just
volunteered
in
the
Google
lock
all
right,
so
we
have
a
set
of
recurring
topics
where
we
get
some
updates
from
our
various
sub
projects
and
then
a
little
bit
of
review
of
where
we
are
on
our
core
things
that
were
working
on
plus
some
open
discussion.
A
B
C
D
A
A
B
Nothing
right
now,
I'm
thinking
that
we
should
I,
don't
know
what
to
do
with
this
yet.
But
we
should
talk
about
I.
Think
I,
think
that
not
many
of
the
sub-project
owners
for
licensing
has
been
active.
So
there
there
are
a
few
open
things
that
potentially
can
be
shorted
out
so
a
few
contributors,
but
give
me
a
chance
to
look
through
the
open
issues
and
see
what
we
can
do
there.
A
Yeah
that'll
be
awesome,
it's
been
an
area
where
at
various
q
cons
is
we've
talked
about
it,
it's
something
where
various
people
here
and
there,
especially
maybe
a
nos
PO
groups
that
companies
things
like
that
or
depending
on
individuals.
Past
experiences.
There's
people
out
there
who
have
expertise
in
this.
So
if
we
have
things
we
can
write
down
and
chart
out,
that's
a
good
thing:
release
engineering
there's
definitely
stuff
going
on
in
that
space.
What
should
we
share
with
folks.
B
Today
sure
so,
I
think
the
first
one
I
think
probably
the
most
impactful
one
is
that
we've
been
moving
on
a
lot
of
the
Krell
work,
so
hat
tip
to
have
to
Daniel
and
Sascha
and
Carlos
and
honest
and
everyone
who's
been
diving
in
there
to
work
on
crow.
As
of
this
release
cycle,
we
started
using
crevel
fast
forward,
as
opposed
to
branch
fast
forward.
I
see
there
was
an
open
PR
to
actually
remove
branch
passwords,
so
a
steps
in
the
right
direction.
B
F
So
I
guess
one
of
the
big
things
is
when
we're
like
translating
stuff
deciding,
whether
to
kind
of
like
keep
it
in
bash
fashion,
where
we're
calling
calling
like
command
line
you
Dalls
and
that
sort
of
thing
and
for
most
of
the
changes.
If
the
initial
step
we've
been
kind
of
like
going
with
that
same
pattern,
so
that
the
setup
and
usage
is
similar
to
using
the
existing
bash
implementations
and
then
over
time,
we're
trying
to
move
like
more
towards
actually
calling
universe
decays
and
that
sort
of
thing.
F
So
a
good
example
is
any
of
like
anything's
using
google
cloud.
You
know
we
have
a
lot
of
like
comic
gsutil
or
something
like
that.
I'm
so
you'll
still
see
those
sprinkled
in
with
some
of
the
Krell
tools,
but
we're
kind
of
incremental
II,
removing
some
of
that
as
well.
So,
if
you're
familiar
with
that,
that
definitely
be
a
good
area
to
jump
in,
because
it
is
sort
of
like
a
a
one-to-one
translation
where
you
can
see
the
functionality
and
just
kind
of
like
that's
using
something.
That's
a
little
more
testable.
A
Got
a
high-level
question
on
the
GCB
manager
work
from
the
last
week
like
to
me.
It
feels
like
sort
of
a
wrapper,
often
or
primarily
in
front
of
an
ago.
Krell
is
also
sort
of
a
rapper
and
I'm
used
to
tools
where
you
sort
of
have
to
name
followed
by
verb
and
I'm.
Imagining
verbs
here
being
things
like
mock,
staged,
mock
release,
official
stage,
official
release,
release
note,
notify
test,
release,
notify
official
things
like
that.
The
GCB
manager
move.
That's
a
weird.
B
So
I'll
speak
since
I
worked
on
the
jeans
to
be
manager,
one
that
is
kind
of
I,
think
I,
think
for
the
bigger
scarier
ones,
I'm
more
focused
on
replicating
functionality
and
teasing
out
the
right
things
that
we
need
to
do
so
like
I
started
on
the
nagas
one
as
well
and
I
started.
That's
a
very
that's,
very
generous
statement.
It's
essentially
skeleton
right
now,
but
really
I
I
think
it's
I
think
it's
naming
is
hard
figuring
out.
What
to
call
the
thing.
B
Gcb
manager
does
a
few
things
right
now
that
I'm
not
sure
that
we
all
take
advantage
of
the
primary
one
is
job
submission
right,
so
I
think
it's
naming
is
hard.
What
we
call
job
submission,
is
it
just
crawl
submit
or
something
right
to
GCB
I
felt
that
using
GCV
manager
would
be
very
clear
about
what
it's
doing
it's
doing
the
same
functionality
as
GCP
manager.
If
we
decide
to
call
that
something
different
in
the
in
the
future,
I
think
it's
fairly
easy
to
to
rename
that
stuff.
A
Of
my
second
question
that
I
secured
well,
we've
talked
about
the
ability
to
do
local
dev
test
again.
Gcb
manager,
sort
of
feels
like
an
in-between.
If
conceptually
I
think
we
build
stuff
in
containers,
happens
being
cloud,
I
have
a
way
to
run
containers
locally
like
could
there
be
a
fast
iterative,
local
dev
test
for
especially
for
unskilled
UNAM
privileged,
though.
A
A
B
So
this
is
this
is
something
that
I
was
thinking
about,
while
playing
around
with
the
GC
builder
or
the
image
builder
or
whatever.
We
call
it
in
test
and
for
us,
so
we
kind
of
did
we
kind
of
did
a
bit
of
a
fork
of
that,
so
that
we
can
take
that
functionality
strip
it
into
a
library
and
then
build
the
new
GTV
manager
around
that
so
there's
also
a
function
of
GC
b
manager
are
not
used
to
be
manager,
but
the
GC
b
build
submit
where
you
can
do
like
a
local
build
submit.
B
So
you
can
validate
the
options
of
of
the
the
template
that
you're
going
to
submit
as
well
as
do
a
local
run
of
it
right
and
I'm
thinking
that
that
would
probably
be
later
functionality
that
we
could
roll
in.
The
reason
that
came
up
was
the
essentially.
What
we're
doing
in
prowl
is:
if
you
look
at
the
prototype,
build
jobs,
we're
essentially
using
a
TCP
template
to
submit
a
TCP
template
to
like
to
run
it
in
a
different
in
a
different
GCP
account,
so
I'm
thinking,
though
the
local
cloud
build.
B
Let
me
see
if
I
can
find
that
piece.
I
Bart
I
know
that
you
had
you're
planning
a
work
on
something
and
and
I
kind
of
asked
that
you
would
come
to
sig
release
and
talk
about
what
you
were
thinking
of,
because
it
was
kind
of
unclear
from
from
what
you'd
put
up
initially
so
I
want
to
see
if
we
can
maybe
meet
in
the
middle.
If
there's
already
stuff,
you've
been
working
on.
G
B
B
G
You
know
just
moving
writing
another
abstraction
layer
over
some
proper
over
some
already
existing
book
and
moving
the
one
technical
depth
to
the
another
technical
depth
without
any
architecture
or
design
or
thinking
before,
which
is
I,
think
that
which
will
move
and
we
create
another
problems,
not
solve
the
problems.
What
will
what
is
the
what
the
benefits
of
the
tooling
right
now,
which
were
rewriting
differently?
What
are
the
benefits
of
completely
rewriting
one
tool
from
one
language
to
another
language,
so.
B
I
think,
with
the
benefit
that
we're
getting
right
now,
is
more
hands
involved
in
actually
understanding
what
the
tool
does.
The
reason
why
we're
trying
to
not
reaaargh
attacked
them
massively
is
because
not
everyone
understands
what
they
do,
what
they
do
right
so
having
a
one-to-one
mapping
of
how
these
tools
work
is
one
of
the
first
steps
I
think
it's
pretty
easy
to
refactor
once
we're
in
a
language
that
is
highly
flexible.
G
Because
when
you
know,
when
you
just
switch
a
language
without
kind
of
conceptual
feeling,
before
so
doing,
even
flow
charts
or
even
I,
don't
know
kind
of
document
where
you
before
writing
any
code,
you
know
what
you
want
to
do.
It
is
just
shifting,
like
you
know,
just
digging
the
hole
another
place.
Yeah.
B
G
G
That's
the
case:
there
is
multiple
different
pieces
together,
no
one
place
with
the
proper
documentation
where
we
can.
You
know
we
have
one
single
source
of
truth
about
that,
and
then
we
are
just
watching.
You
know
moving
shifting
things
from
one
place
to
another
and
generating
another
technical
depth,
and
this
is
not
how
the
things
should
work
and
I.
I
was
working
for
a
lot
of
projects
where,
like
there
was
never
any
project
or
never
any
kind
of
product
which
that
kind
of
approach
worked.
D
G
Wrong,
maybe
there
are
kind
of
people
who
saw
and
experienced
different
thing,
but
I
feel
like
what
we
are
doing
right
now
is
just
shifting
technical
depth
from
one
place
to
another
place
with
one
language
from
our
language
to
another
language.
So
my
approach
and
my
thinking
that
this
is
the
thing
how
this
is
the,
how
the
pin
should
P
is
to
first
know
how
to
solve
the
problem
then
solve
the
problem
we've
caught.
That's
it
that's
kind
of
so.
B
G
A
So
I
see
a
couple
of
problems
that
were
for
maybe
walking
around.
We
definitely
have
a
problem
in
the
actual
implementation
of
the
Bosch.
The
style
of
the
Bosch
is
complicated
in
a
way
that
is
not
accessible
or
approachable
so
changing
that
is
a
benefit,
but
we
also
have
some
pretty
big
picture
concerns
I
think
around
how
we
release
today.
It's
it's.
A
It's
not
very
it.
It
doesn't
follow
best
practices.
Put
it
that
way
of
how
industry
deliver
software.
We
have
a
set
of
automation,
run
by
one
team
that
delivers
things
into
tests,
a
different
set
of
automation
that
delivers
things
and
the
sort
of
production
path,
a
nursing
release
for
distinct
from
what
the
test
and
for
our
folks
do.
So
that
itself
is
means
that
we're
not
testing
what
we
eventually
release
or
releasing
what
we
tested
from
artifacts
perspective
from
a
code
perspective.
A
These
things
get
built
mostly
from
the
right
the
same
places,
although
the
the
way
we
do
fast-forwarding
and
patching
slightly
differently
on
different
branches
means
that
there's
variation
there.
So
we've
had
architectural
discussions
over
the
last
year
around
shifting
towards
a
different
flow
of
release.
I
think
it's
reasonable
to,
especially
as
we
have
new
people
getting
involved
and
and
changing
code
and
implementing
new
things
to
have
them.
A
Thinking
about
that
big
picture
and
making
small
changes
towards
that
as
it
makes
sense,
as
opposed
to
just
doing
things
is
a
simple
transliteration
and
I
do
see
some
signs
of
that,
but
the
at
times
I
agree
that
I'm
not
quite
sure.
What's
going
on
and
the
specifics
of
the
implementation
so
the
it
we
got
to
keep
the
forest
in
mind
and
not
just
be
focusing
on
the
trees,
but
we
need
more
discussion
of
what
is
the
desired
force.
B
So
I'm
linking
something
in
the
chat
that
is
a
brainstorm,
I,
think
I.
Think
of
all
of
the
things
that
we
said,
the
biggest
thing
to
worry
about
the
biggest
thing
I
get
concerned
with
is
the
fact
that
we
don't
have
enough
people
available
to
work
on
the
tools,
because
there
is
a
lack
of
understanding
that
that's
the
primary
focus
for
for
the
transliteration
of
these
tools.
A
In
addition
to
a
PR
to
remove
branch
ffs,
one
might
even
imagine
a
PR
event
remove
Crowell
FF,
because
there
isn't
a
strong
reason
for
having
this
fast
forward.
So
we
have
a
lot
of
things
that
we're
doing
for
historical
reasons
that
don't
make
the
most
of
sense
and
as
we
re
implement
them,
it
can
send
the
wrong
message.
I
think
at
times
around
what
our
intent
is.
We
can
brainstorm
things,
but
we
also
need
to
sort
of
decide
out
of
the
possibilities
of
brainstorms.
What
is
what
is
a
sound
engineering
forward
path.
H
So,
from
my
perspective,
if
we
go
iterative
he
to
solve
this
problem,
then
first
of
all,
we
have
to
understand
how
it
works
and,
for
example,
so
fast
forward
is
a
pretty
good
example,
because
for
me
it
was
the
only
way
to
actually
understand
how
it
works
and
then
use
our
libraries
like
ticket
library
and
repository
abstraction
above
we
implemented
to
implement
that
same
fast
forward.
Behavior
I
mean
they
are
just
100
200
lines
of
code.
H
B
A
We
had
like,
if
we
had
in
some
durable
way,
aside
from
the
code
implementation
some
sense
of
what
the
original
authors
of
that
tool
had
intended.
It
would
have
made
our
lives
a
lot
easier.
Most
of
what
we're
doing
looking
at
Otago
is
going.
Why
would
they
do
this
and
based
on
how
we
believe
release
happens?
We
look
at
the
code
in
ways
that
is
full
of
assumptions
and
generally
those
proved
to
be
wrong.
So
I
I'm
totally
for
incremental
improvement.
A
I
think
that's
the
the
main
way
that
we're
gonna
make
forward
progress,
but
I
think
to
do
incremental
improvement.
Well,
so
that
you
iteratively
end
up
not
going
off
the
screen
there,
but
it
really
end
up
this
direction.
We
as
a
group
have
to
have
conceptual
integrity.
We
have
to
understand
where
it
is.
We
intend
to
go
incremental
II,
because
at
any
moment
you
can
go
any
direction
or
you
could
just
be
spinning
in
circles
as
well.
So
I
think
it's
important
for
us
to
have
some
of
these
big
picture
discussions
more.
A
Do
we
need
to
be
having
more
of
them?
I
think
that
that's
the
main
thing
I
was
hearing
Bart
say
that
this
action,
all
we
should
be
talking
about
the
concept
in
point
Direction
a
little
bit
more
often,
while
recognizing
that
in
a
moment,
we're
probably
mostly
just
looking
at
point
things
but
knowing
the
end
goal,
while
you're
working
on
a
point
increment
is
actually
beneficial
to
ensuring
that
you
increment
in
the
most
useful
direction.
A
I
B
Well,
if
not
all
there,
the
I
think
the
gaps
that
we
currently
have
are
being
able
to
push
images
to
the
staging
cake.
Statues
GCR
that
IO
as
well
as
Kate
statue
stereo,
so
those
vanity
domains
that
are
fine,
Google
and
and
being
able
to
publish
Deb's
and
rpms
write
everything
in
front
of
that
process.
I'm
pretty
sure
we
haven't
at
this
point.
It's.
I
A
Maybe
you
heard
more
than
what
we
said:
that
is
those
remain
the
goal,
but
I
think
over
the
last
year
and
a
half
since
we
really
identified
those
as
the
goal
of
being
able
to
publish
images,
signing
and
building
of
our
pins
and
Deb's.
We
haven't
changed
anything
on
that.
We
are
starting
to
have
a
vision
for
where
that
will
go
and
I
think
that's
part
of
what
bumps
into
things
that
Bart's
working
on
in
terms
of
the
the
newer
Cates
infra,
but
those
aren't
things
that
we
have
actually
changed.
B
Yeah
I
think
for
thinking
about
signing
and
what
our
approach
is
going
to
be
there.
It's
gonna
be
one
of
the
next
things:
I've
been
working
on
Cuba
pkg,
which
is
the
Devon
rpm
builder
that
we
have
or
that
we
will
have
or
that
we
will
use
and
the
RPMs
and
Deb's
have
been
removed
from
from
kubernetes
kubernetes.
So
there
is
forward
progress
there.
Just
I
think
the
next
stage
is
figuring
out.
G
B
So
so
I
I
think
I
want
to
make
clear
that
there
is
architectural
thinking
going
on
all
we're
trying
to
solve
these
problems,
and
it's
not
a
one
one
to
one
mapping
we're
doing
in
rewrites
the
primary
thing
that
we're
trying
to
get
is
solved
with
that
is
maintainability
right.
So
the
people
who
are
the
people
who
are
patch
release
team
members
like
they
cannot.
They
cannot
necessarily
work
on
these
things
all
the
time.
B
A
That's
something
to
add
to
the
list
of
initial
goals
was
broadening
the
the
set
of
people
involved
and
and
they're.
The
thinking
has
definitely
been
that,
instead
of
monolithic
tools,
if
we
have
smaller
point
tools
that
can
be
run
locally
and
can
have
unit
tests
that
are
in
CI,
that
makes
it
a
whole
lot
more
approachable,
an
individual
can
say.
Oh
this,
this
seems
slightly
broken
or
there's
a
more
optimal
way
to
do.
This,
I
can
tweak
the
code
and
then
they
can
see
if
it
works.
A
I
I
We
are
not
you're,
not
questioning
the
architectural
decisions.
I
am
just
well.
We
are
just
trying
to
brainstorm
here,
trying
to
figure
out.
How
can
the
kate's
infra
help
you
achieve
those
other
goals
faster
right,
because
if
you're
talking
about
signing
and
being
able
to
test
pushing
two
repositories
nightly
builds
of
depth
and
rpms,
you
know
and
those
kinds
of
things
you
know
those
seems
to
have
like
maybe
put
on
the
backburner
as
compared
compared
to
here.
B
H
G
Also,
I
want
to
add
that
my
kind
of
talk
was
that
kind
of
research
which
I
was
doing
and
I'm
doing.
Right
now
was
exactly
for
that
purpose.
To
not
just
complain
about
some
architectural
design,
but
to
actually
try
to
understand
them,
and
so
far
it
is
so
for
me
at
least
it
is
so
messy
in
so
many
places.
It's
changing
so
often
that
I,
it's
really
really
hard
for
me,
not
a
little
bit
the
project
from
this
time.
So
I
don't
even
think
about
people
who
just
are
joining
so.
B
I
think
yeah,
so
I
think
it'd
be
super
useful
if
you
are
working
on
something
that
involves
our
our
stuff.
That
would
be
helpful
to
know
what
you're
working
on.
So
we
can
help
direct
you,
because,
yes,
things
are
changing
very
rapidly
right
now,
so
I
think
it's
helpful
to
have
this
to
continue
coming
to
the
cig,
release
meetings
and
continue
having
these
discussions,
so
we
can
help
steer
you
in
the
correct
direction.
Yeah.
I
Stephen,
the
problem
here
is
doing
something
in
kids.
In
fact,
it
takes
a
really
long
time
right,
so
we
have
to
not
only
think
about,
like
the
short-term
goes
as
well
as
the
longer-term,
like
example,
the
image
promoter
has
taken
so
long,
and
it's
not
still.
We
are
not
still
at
a
point
where
everything
is
ready
right,
so
we
we
have
to
be
I.
Don't
want
to
wait
for
the
short-term
benefits
of
the
maintainability
Eclipse.
What
the
long-term
stuff
that
we
need
to
do
and
get
there.
D
I
B
Yeah
so
again,
I
think
it's
better
understanding
like
I,
don't
I
like
today,
I,
don't
understand
what
the
what
the
Katyn
for
roadmap
is
at
all.
I
know
that
image
promotion
is
high
up
there
but
like
if
there
are
places
that
we're
dovetailing.
This
is
kind
of
why
we
suggested
having
the
face-to-face
at
in
Amsterdam
to
actually
sit
down
and
talk
about
some
of
this
stuff.
That's.
I
I
We
want
to
kind
of
say
with
the
release
team
we
want
to
say
these
are
the
resources
that
are
needed
by
the
Misty,
and
this
is
the
priority
of
the
resources
that
are
needed
by
the
release
team.
So
if
we
have
that
common
understanding,
then
we
can
figure
out
how
to
slowly
get
there
without
questioning
okay.
What
is
the
overall
release
goals
of?
What
is
the
overall
goals
of
the
signal
ease
or
the
overall
goals
of
case
since
I?
Don't
want
to
get
into
that
argument
here?
I
I
I
I
B
B
F
G
B
B
A
A
Yeah,
it
seems
fairly
quiet,
as
my
read
of
things
so
far,
but
we're
just
getting
into
maybe
for
the
newer
folks
on
the
call.
The
the
release
is
cyclical.
It's
on
a
quarterly
basis
and
out
of
the
three
months
of
the
quarter,
the
last
month
or
plus
a
week
or
two
depending
on
what
fires
have
simmered
past
the
release
as
well.
That's
when
things
tend
to
get
a
little
more
exciting
right.
Now,
it's
kind
of
business
as
usual
things
merging
into
the
KK.
A
All
right,
then,
we
have
a
number
of
things
that
I
think
are
listed
in
open
discussion,
which
deserves
some
time
so
I
kind
of
want
to
leave
off
the
project
board
review.
Just
for
the
moment.
Also,
that's
semi-regularly
covered
in
the
release
team
meeting.
Also,
there's
overlap
across
those,
so
I
feel
like
it's
not
completely
on
triaged.
So
the
open
discussion,
jeremy
record
had
put
a
few
topics
around
keps,
but
I
don't
actually
see
them
on
the
attendees
right
now,
I,
don't.
B
C
The
issues
per
stage
I
think
that
was
the
whole
kept
for
alpha-beta,
like
people
doing
caps
for
specific
phases
that
is
currently
being
addressed
in
the
cap
of
caps.
The
the
meta
kept
changes
by
pushing
for
just
one
one
kept
for
the
entire
feature
enhancement.
It
covers
all
the
stages:
alpha-beta
stable,
yeah.
B
D
B
C
B
B
D
B
A
If
there
are
questions
about
what's
going
on
on
any
of
these,
so
the
the
two
in
particular
that
I
had
in
mind
are
well
actually.
Why
don't
we
go
time
order?
The
oldest
of
the
four
is
around
adding
conformance
documentation
as
a
part
of
the
release
documentation.
This
has
been
around
for
a
year
and
I
wondered
since
we
have
dims
on
the
line.
Also,
oh,
not
in
the
original
discussion,
so
I
guess,
Stephen
you
and
Erin
we're
the
main
people
talking
about
this.
Maybe
initially
is.
B
B
B
A
A
A
B
So
yeah
we
don't
talk
about
conformance
much
in
in
this
proposal,
but
basically
there
was
a
chat
on
the
on
the
state
architecture,
mailing
list
about
some
potential
improvements
to
caps
and
it
kind
of
overlaps
heavily
with
some
of
the
stuff
that's
already
written
in
cap
1a,
which
is
now
being
converted.
So
you
kept
617
based
on
the
new
structure
where
we'll
be
referring
to
caps
by
the
issue.
Number.
That's
that's
currently
open.
So
there
are
a
few
things
going
on
there.
Moving
the
caps
to
directory
structure.
B
C
C
B
B
I
D
A
Okay,
all
right:
well,
we
can
I
guess
we
can
leave
that
one
where
it
is,
then,
for
the
time
the
next
newer
one
is
luminaires
proposal
about
moving
Cuba
diem
out
of
kaykai.
This
is
a
pretty
major.
Change
is
the
first
thing
that
is
a
release
team
released
artifact,
that's
moved
out
of
kaykai
to
my
knowledge
anyway,
and
that
drives
interlocked
with
what
we're
doing
in
terms
of
our
release
process.
A
This
one
was
a
little
bit
of
a
surprise
like
we
knew
this
was
coming,
but
then,
when
it
showed
up
in
January,
with
the
hope
of
going
into
this
current
quarters
release
relative
to
all
the
other
things
that
we're
doing
refactoring
existing
code.
This
is
definitely
an
area
where
we
need
to
re-architect
flows,
so
it
conflicts
with
the
current
short-term
implementation
swizzles.
A
The
last
time,
I
was
really
seeing
the
conversation
active.
This
was
having
discussion
around
okay.
Let
that
we'll
defer
it
to
the
next
release
or
a
better
time,
maybe
in
abstract,
like
we're
relatively
agile,
like
we
want
things
in
this
release
and
if
not
well,
it'll
be
the
future
when
the
future
works.
It's
currently
labeled
as
119,
but
is
there
been?
Has
anybody
seen
any
additional
discussion
or
changes
on
this.
A
B
D
D
President
KK
place
it
in
a
folder
that
is
comfortable
for
a
logo
and
Hanako
can
just
release
the
artifact
without
having
to
build
it
and
also
I'm
going
to
have
to
overhaul
the
whole
the
whole
idea
around
branch
and
tack
synchronization,
because
I
was
experimenting
with
some
tools
or
how
to
do
this,
so
the
cap
is
out
of
date.
At
this
point,
okay,.
B
I
No
bummer
I,
are
you
just
trying?
Is
this
new
thinking
just
to
makes
it
make
it
easier
for
the
release
team,
or
is
it
actually
the
thing
that
we
would
like
to
do
for
all
the
other
things
that
needs
to
come
out
of
KK?
Also
right,
I
would
rather
spend
the
time
thinking
and
making
changes
that
will
support
extracting
of
other
things
other
than
cube
ADM
in
the
and
not
just
short-term
things
just
for
cube
idea.
Do
you
see
what.
I
B
So
this
is
one
of
our
initial
criticisms
of
the
cap
right.
There
was
discussion
around
whether
okay.
Well,
maybe
it
will
just
do
it
ourselves
right,
but
like
QC
TL
was
probably
going
to
be
one
of
the
next
ones
to
push
out
of
of
KK
and
like
it's
a
process
that
we're
going
to
have
to
repeat
for
different
tools
right
so
it'd
be
nice
to
understand
exactly
how
to
do
it
right.
B
So
the
the
creating
a
folder
and
pushing
artifacts
somewhere
and
having
them
be
available
doesn't
really
solve
the
problem
for
us
because
and
I'll
go
make
some
assumptions
about.
What's
going
to
be
in
the
prepared
tree
right,
it
looks
to
see
if
there
are
artifacts
of
the
prepared
tree
right.
There
are
certain
like
we
would
so
that's
like
for
that.
We
would
have
to
add
functionality
to
an
go
to
go.
B
Look
at
this
extra
place
right
and
and
like
it
more
makes
the
its
you
know
and
more
makes
the
case
for
like
this
thing
needs
to
go.
It's
not
flexible
right,
the
the
sidestepping
and
go
and
expecting
things
to
be
in
a
certain
location
like
that.
Doesn't
work
today
like
we
would
have
to
write
that
right?
So
it's
those.
D
A
Certainly
possible,
depending
on
what
you
figure
out
with
near
experimentation
around
branching
and
tagging,
that
you've
done
an
equivalent
thing,
but
then
we
did
would
at
least
need
to
make
sure
that
we
have
a
clean
way
of
not
doing
those
things
for
things
that
have
taken
care
of
it
themselves
is
make
release
is
easy,
but
this
was
sort
of
one
of
my
questions
in
the
Catholic
from
what
are
you
building?
We
we
have.
That
part
needs
to
be
reproducible.
A
Can
set
up
your
git
repo
locally
and
you're,
like
you
just
got
a
directory
of
sources
like
anybody
can
set
this
up.
Any
automation
can
set
this
up,
and
at
that
point
you
can
run
make
release.
Write
like
make
release
is
easy
at
that
point,
if
all
of
its
assumptions
are
satisfied,
but
there's
other
side
effects
that
happen
is
a
part
of
the
build
process
around
the
branching
attacking.
Can.
A
Basic
thing,
though,
is
to
say
like
for
for
the
inputs
of
make
release
to
make
sure
that
those
are
durable.
If,
if
whatever
your
scheme
is
that
gets
the
code
into
the
subdirectory,
where
it's
make
release
a
bull,
is
something
for
a
script
that
does
it
get
check
out
of
a
tag?
It's
probably
gonna,
be
something
relatively
straightforward.
There's
a
number
of
things
in
today's
antigo.
I
A
A
Lining
up
if,
if
Crowell
has
replaced
an
ax
go
over,
this
I
mean
at
this
point
over
the
coming
five
weeks.
I
think
that's
speculative
speculating
I
would
say
that's
aggressive
and
verging
on
unlikely,
but
if
we
hit
a
if
we
presume
we
have
accomplished
that
there
should
be
individual
point
tools
that
would
not
need
to
be
called
when
making
cube
ATM
and
that
could
make
it
much
easier
to
split
out
alternative
workflows.
A
B
All
right,
but
the
Thames,
this
came
up
as
a
result
of
us
reviewing
caps,
not
and
we're
bringing
it
up.
So
that's
why
I'm
saying
like
if
there
are
alternative
approaches-
and
it
is
and
I'm
pretty
sure
something
like
that-
it's
listed
in
the
cap-
I'm
just
saying
bring
it
here,
so
we
can
discuss
it.
It's.
A
A
It
would
be
great
if
each
team
that
did
that
didn't
have
to
reinvent
all
their
tools
and
understand
the
infrastructure
and
all
of
these
different
things
that
there
is
a
an
easy
button
for
them
to
get
their
thing
built
on
whatever
it
is,
their
cadence
is,
but
in
the
short
term,
I
think
just
saying
we'll
build
it.
Ourselves
means
there's
a
lot
of
reinvention
reimplementation
parallelization
of
things
and
in
RISC
the
things
that
are
intended
to
be
kept
in
sync
aren't
in
sync,
because
it's
it
becomes
implicit
there's,
not
a
lockstep
coordination
point
there
there's.
A
Think
we
need
to
make
sure
that
we
coordinate
the
things
that
we
intend,
if,
if
everything
must
be
tagged,
v1
not
18.0.
At
the
same
time,
people
who
are
doing
that
should
be
talking
to
each
other
instead
of,
if
I
view
it
as
a
failing
of
us
collectively,
all
of
us
on
a
call
if
we
end
up
in
a
place
where
we're
not
talking
to
each
other
in
coordinating
that
stuff.
So.
D
I
just
want
to
say
that
they
already
have
a
tool
that
is
doing
exactly
that.
It's
using
github
actions.
It
is
currently
synchronizing
at
this
repository
the
other
day
it
created
the
release
branch
automatically
after
Carlos
pushed
the
release
branch.
It
picked
that
up
pushed
new
tags.
So
it's
the
synchronization
process
that
the
main
the
main
issue
here
is
releasing
cube
ATM
as
part
of
the
terminals.
A
All
right
we're
over
time.
Thank
you
all
for
joining,
really
good
conversation
today,
actually
as
much
as
it
may
have
felt,
contentious
like
we
have
to
have
these
conversations.
This
is
how
we
establish
that
conceptual
integrity
being
aware
of
what
we're
doing
and
and
not
end
up
again
where
we
have
something
like
a
Naga
with
all
sorts
of
hidden
assumptions
that,
where
we're
trying
to
be
in
sync
we're
explicitly
and
sync
and
documenting
that
all
so.
Thank
you
all.
Thanks.