►
From YouTube: Implementation Sync: 2021-01-14
Description
Meeting notes: https://bit.ly/38pal2Z
B
I'll
kick
us
off.
It's
fine!
Let's
see
record
meeting
status
updates.
I
don't
really
have
much
other
than
I'm
going
to
be
getting
into
the
first
kind
of
piece
of
stack
packs,
which
I
put
on
the
agenda
to
talk
briefly
about
kind
of
our
opinions
on
which
direction
to
go
for
the
first
set
here,
yeah.
Anyone.
A
I
just
picked
up
a
a
chore
to
pull
build
pack
related
code
into
its
own
package.
I
think
that's
something
that
will
potentially
help
us
with
stack
packs,
some
of
the
complexity
there.
My
brain
hurts
now
because
it's
a
lot
of
logic
and
you
know,
detect
and
build
to
kind
of
sift
through,
but
hopefully
making
progress
on
that.
C
I
put
a
few
pr's
a
few
days
ago
that
relates
to
adding
the
manifest
size
to
report
tamil.
It's
an
image
you
tell
in
life
cycle,
which
is
depends
on
image
retail
and
in
spec.
A
B
Cool
yeah,
you
want
to
link
your
your
bug
or
pr
as
well
and
maybe
add
to
the
agenda.
You
can
discuss
a
little
bit
if
you
want.
B
The
next
item
is
release
planning.
Someone
who
actually
does
releases
probably
should
speak
to
this.
B
B
B
D
Yeah,
I
think
we
are
implementing
the
next
spec
as
the
issues
come
through.
There
was
one
thing
that
came
up,
which
was
matt
moore,
had
added
support
for
east
dogs.
D
I
don't
know
how
to
pronounce
it
e
star
g
to
ggcr
and
he
wanted
to
try
out
it's
like.
Basically
what
it
does
allow
you
to
lazy
pull
images,
so
it
doesn't
pull
layers
until
they're
used
at
runtime,
and
there
are
some
things
you
can
do
to
make
images
that
work
efficiently
for
that.
But
the
basic
workflow
wouldn't
need
us
to
do
anything
in
order
for
him
to
try
out
taking
advantage
of
lazy,
pulling
images
and
since
it's
in
ggcr,
if
we
updated
ggcr,
which
we
already
have,
I
think,
since
the
release.
D
B
What,
with
the
would
our
users
be
able
to
tell
if
this
was
implemented?
I
guess
like.
I
understand
the
idea
of
lazy
pulling
but
like
what
like,
since
we're
building
images
and
like
concatenating
layers
like
which
what
wouldn't
have
to
be
pulled
in
like
a
normal,
typical
pack,
user
kit
or
lifecycle
use
case.
D
It's
an
interesting
question
because
I
feel
like
most
things
that
end
up
in
a
cmb
built
image
should
kind
of
need
to
even
start.
So,
from
my
perspective,
I
don't
see
like
a
lot
of
winds
from
lazy
pulling
in
a
life
cycle
created
image
where
I
do
see
really
big
winds
would
be
lazy
pulling
in
a
builder
yeah,
but
up
shipping.
A
life
cycle
wouldn't
help
with
that
at
all.
D
You
know
flag
it
on
with
an
environment
variable
that
ggcr
understands
and
play
with
it
on
their
own.
I
don't
necessarily
want
to
block
people
from
doing
this,
even
though
I
am
somewhat
skeptical
that
it
would
bring
large
benefits
yeah,
but
it
feels
a
little
weird
to
ship
in
a
patch
and
I'm
not
sure
whether,
like
waiting
for
the
next
big
life
cycle,
release
feels
like
it
might
be
a
long
time.
B
Yeah,
I
don't
know
I
I'd
kind
of
have
to
see
I'd
kind
of
like
to
understand
what
the
perceived
benefit
would
be,
because
I'm
afraid,
like
it
being
in
its
own
release,
might
even
give
it
sort
of
a
seeing
release.
Notes
of
some
experimental
cool
feature
that
talks
about
lazy
pulling
and
then
like
turns
out
it.
You
know
it
doesn't
really.
B
D
Rather,
being
really
specific
about
it,
but
that
feels
kind
of
sneaky
right,
I'm
not
quite
sure
what
the
right
answer
is
here.
So
if
anyone
has
a
better
idea-
or
you
know,
we
can
tell
matt
and
the
folks
who
are
interested
in
this
just
I'll
wait
a
couple
months,
but
I
like
to
help
people
out
when
they're
excited
about
something
and
it's
easy
for
us.
It's
not
hard
for
us.
It's
just.
D
D
Next,
we
don't
need
to
do
anything.
We
just
ship
with
the
updated
gdcr.
D
B
A
D
Yeah,
which
means
you
know,
like
probably,
couldn't
even
use
it
through
pack
right
now,
so
in
a
lot
of
ways,
it's
not
a
feature,
we
would
truly
be
exposing
to
people,
but
anyone
who's
running
it
in
an
environment
where
they
can
change
the
environment
variables
would
then
be
able
to
use
it.
B
Awesome
anything
else
on
release
planning.
B
B
That's
a
good
point
yeah
to
do
that.
B
All
right
so
yeah,
the
next
question
that
I
think
yell
brought
over
from
last
time.
Let's
see,
okay,
let
me
figure
out
how
to
share
this
screen.
I
guess.
B
B
And
there
are
some
things
listed
here-
that
I
will
open
up
as
well.
That
are
like
questionable.
I
think.
B
A
What
I
was
thinking
of
there
was
someone
I
believe
I
believe
she's
at
ibm
had
raised
a
it's
like
the
one
bug
that
we
have
or
the
second
bug
that
we
have
now
you
just
click
on
type
bug.
It
should
pull
them
up.
It's
like
so
many
tags,
okay,
and
it's
this
retry
of
fetching
images.
I
think
we
had
said
you
know
we
will
look
at
it.
C
B
What
was
the
it's.
C
A
Oh,
I
had
a
meta.
I
had
like
a
meta
point.
I
don't
know
feel
free
to
this
could
be
totally
off
topic,
but
on
adding
stuff
to
the
milestones.
I
know
on
the
pack
side
like
they're
kind
of
just
encouraging
and
correct
me
if
I'm
wrong,
but
like
just
encouraging
like
just
if
you
think
something
could
go
in
the
milestone
edit
and
then,
if
we
need
to
push
it
off
to
the
next
milestone
like
we
can.
B
C
D
C
I
agree
the
only
thing
that
can
happen
with
this,
like
idea,
is
that
we'll
work
on
some
stuff
that
can
we
that
we
can
push
to
the
next
release?
While
there
are
some
other
stuff
that
we
would
like
to
add
to
that
current
release
and
then
like
we
can
get
to
a
point
where
we
would
like
to
release
and
we're
like.
We
still
have
some
bunch
of
things
to
do,
but
I'm
not
I
mean
if
we
could
have
priority
inside
their
lives
inside
the
release
could
solve
this
problem,
but
I'm
not
sure.
What's
the
right.
A
A
B
D
B
D
Throw
it
in
there
what
I
worry
about
this
particular
one
is
that,
like
I,
this
is
a
bug
that
I
don't
actually
know
what
it
required
like
investigation
to
figure
out
what
exactly
is
going
wrong
here.
So
I
don't.
If
there's
a
quick
one,
I'd
be
like
yeah,
let's
throw
it
in,
but
I
don't
know
whether
it's
a
lot
of
work
or
not
a
lot
of
work.
D
Yeah-
let's
throw
it
in
for
now,
and
then
we
can
boot
it
if
we
need
to.
I
threw
another
one
in
there
in
the
spirit
of
our
new
resolution,
which
was
support,
node
identity
based
authentication.
Just
because
I
think
it's
probably
pretty
easy
and
it's
definitely
something.
B
D
B
D
D
B
All
right
well,
I'd,
say:
if
there's
anything
in
here
that
looks
out
of
place,
bring
a
call
either
now
or
later
take
a
look
at
it.
A
The
only
other
question
I
had
around
this
was
the
pre-release
and
experimental
stuff
like
I
thought
we
were
gonna
need
that
for
stack
packs,
but
but
since
they
will
be
fully
specced
in
the
07
api
like
is
it
still
as
important.
A
C
Yeah
I
edit
this-
I
just
as
part
of
the
issue
of
adding
the
manifest
size
to
record
autumnal.
I
had
to
introduce
the
new
api
and
I
suddenly
need
to
edit
like
in
two
files,
which
is
not
that
bad,
but
I
always
prefer
to
not
have
duplicate
things
in
our
code,
so
I
was
wondering
whether
we
can
put
it
in
like
in
one
file
and
then
generate
the
other
file
like
take
the
value
from
the
other
file,
and
I
want
to
hear
your
thoughts.
I
I
couldn't
find
a
reason
not
to
do
so,
but.
D
Sort
of
the
descriptor
file
filled
out
at
the
root
of
the
repo.
This
is
definitely
something
we've
run
into
with
builders
and
build
packs
in
the
past,
where
the
descriptors
were
templates
and
for
folks
browsing
with
the
template
is
not
as
informative
as
a
file.
You
could
just
open
and
see
exactly
what
the
values
are
going
to
be.
C
A
C
D
A
D
B
A
I
think
we
decided
that
we
had
to
do
that,
because,
when
you
merge
release
branches
back
into
main,
it
would
like
clobber
the
version,
and
that
would
be
a
pain
to
always
keep
it.
I
don't
know
if
that's
true
that
could
potentially
still
be
true
for
the
supported
apis
right
unless
we,
we
were
also
talking
about
having
some
sort
of
like
automation,
around
merging
our
release,
branches
back
as
well,
which
could
prevent
clobbering
supported
api
versions.
You
know
from
an
old
branch,
but
I
don't
know.
C
C
B
All
right
there's
only
five
minutes
left,
but
the
next
one
is
analyze
versus
prepare.
I
know
emily.
We
talked
about
this
briefly
yesterday
in
the
slack
chat.
I
know,
there's
like
a
lot
of
competing
rfcs
and
specs
and
stuff
going
on
with
like
exactly
how
we're
going
to
do
this
first
step.
That's
needed
to
kind
of
kick
kick
off
stack
packs,
and
so
I
wanted
to
kind
of
get
the
group
consensus
on
whether
we
would
like
to
introduce
a
new
phase
of
prepare
that
would
currently
do
sort
of
what
analyze
does.
B
It
looks
at
the
you
know
previous
image,
and
I
guess
it
would
emit
an
analyzed
tunnel
as
well
as
that
would
include
the
mix
ends.
I
guess
somewhere,
so
that
the
next
phase
detect
can
do
validation
against
those
right
image
mix-ins
or
if
we
want
to
move
analyze
before
detect
and
and
do
the
bits
that
are
dependent
on
the
build
packs
in
restore
or
similar
after
detect
has
occurred
so
that
we
can.
D
D
B
D
Yeah,
I
don't
have
a
strong
opinion.
I
will
say
I
find
the
fact
that
we're
working
on
the
implementation,
the
spec
in
the
rfc,
all
in
parallel,
it's
actually
kind
of
like
hurting
my
brain.
B
Yeah,
I
actually
sort
of
checked
out.
I
was
a
little
distracted
yesterday
being
on
call
during
the
meeting,
but,
like
I
came
back
and
was
very
confused
on
all
the
like
different
rfcs
coming
around
and
also
you
know
the
push
to
actually
get
this
work
done
as
well.
It's
it
is
not
making
the
image
clear
on
what
I'm
supposed
to
be
doing.
When
I
sit
down
to
code
something
so
I
don't
know
what
we
can
do
to
smooth
that.
D
B
D
D
That
working
on
it
in
parallel
sort
of
part
of
trying
to
make
it
go
faster,
so
this
doesn't
end
up
like
stack
packs,
but
I
do
wonder
you
know.
I
think
this
change
is
simpler
than
stack
packs.
I
feel
like
when
we
have
the
three
streams
like
we're,
making
different
decisions
in
different
places,
and
it's
not
clear
that.
D
Like
we
can
make
a
decision
about
the
life
cycle
now
right,
but
if
steven
doesn't
approve
it
into
the
rfc,
they
have
to
go
back
and
do
it
all
again
and
because
the
conversations
are
having
in
three
different
places,
I
feel
like
I'm
losing
context,
I'm
having
trouble
thinking
about
what
it
is.
We're
trying
to
do.
B
C
D
Yeah,
like
I'd,
be
okay,
just
saying
like
yeah,
we're
gonna
do
it,
but
I
know
we
actually
need
all
the
votes
before
we
can
really
ship
it.
So
I'm
worried
about
sort
of
going
in
circles
and
having
the
conversation
in
a
bunch
of
different
places,
but
I
know
joe
really
wants
to
proceed
with
it
in
parallel.
D
B
Yeah
there's
there's
also
in
my
head
there
I'm
wondering
like
pack,
which
already
does
its
own
validation
of
mix-ins.
Obviously,
pax
gonna
have
to
swap
the
order
of
these
things
once
it
starts
to
use
that
platform
api,
and
that
also
means
they
could
get
rid
of
their
mix
and
validation,
or
they
could
keep
it
depending
on.
B
A
D
B
I'll
put
it
on
the
agenda
today,
and
hopefully
we
can
at
least
come
to
a
consensus
on
the
what
steps
to
take
to
move
forward.