►
From YouTube: Implementations Sync: 2021-02-25
Description
Meeting notes: https://bit.ly/38pal2Z
A
B
I'm
happy
to
facilitate
unless
someone
else
wants
to
all
right,
awesome
so
holding
this
up
status
updates.
I
can
quickly
share,
I
think.
In
the
past
week
it's
been
a
lot
of
looking
at
the
couple
prs,
so
the
pr
to
flip
analyze
and
detect.
I
put
that
on
the
agenda
today
cause
I
was
hoping
we
could
talk
about
the
different
ways
we
could
go
about
it.
I
also
just
put
up
a
pr
for
exactly
on
windows.
A
C
Yeah
I've
been
working
on
a
pr
to
flip
analyze
and
detect,
mostly
that
was
sort
of
that
to
I'm
really
after
getting
able
to
validate
stack
stack
for
the
build
packs-
that's
kind
of
my
goal,
but
since
we
have
to
flip
these
first
to
do
some
of
the
validation.
I
went
ahead
and
got
back
on
that.
So
I'm
just.
G
I've
been
working
on
the
cache
image
fix.
Oh
my
video
froze
again,
but
the
it's
driving
out
a
little
bit
of
the
constructor
change
for
image
util,
so
that
you
can
make
os
specific
images
just
from
the
new
image
call
it's
moving
along.
Okay,
it's
it's!
I
think
it's
all
working
now.
I
just
need
to
clean
up
some
of
the
commits
it
did
drive
out
some
of
the
with
platform
stuff.
G
So
we
do
technically
have
some
knobs
in
there
to
pick
the
right
images
or
to
deal
with
manifest
lists
now,
but
I'll
I'll
tidy
it
up
and
put
it
in
a
little
bit
more
presentable
format.
B
A
B
Okay,
so
here's
the
milestone-
and
I
think
everything
with
a
face
is
well
jesse's.
Current
work
is
in
support
of
this,
and
actually
I
don't
dan
correct
me
if
I'm
wrong,
but
I
don't
think
you
picked
this
up
yet
right.
The
retries.
B
Just
looking
at
this,
I
feel
like
the
ones
that
are
currently
being
worked
on
will
probably
jessie's
might
take
a
little
longer,
but
the
other
ones
are
kind
of
moving
a
pace.
B
So
do
we
want
to
make
any
guesses
as
to
when
we
might
be
able
to
ship
or
any
decisions
about
what
should
go
in
the
release?.
C
C
C
F
A
lot
of
features
that
we
sort
of
just
like
described
in
a
sentence
in
the
rfc
like
we're
gonna
check
the
right
access,
we're
gonna,
validate
the
run
image,
and
I
think
that
was
appropriate
for
the
rfc.
But
I'm
wondering
if
at
some
point
like
we
want
to
like,
do
we
want
to
break
that
up,
or
are
we
going
to
try
to
get
all
of
that
into
the
spec
06
and
the
next
life
cycle
release?
I
think
it's
a
question.
E
C
C
F
F
F
C
Yeah
I'll
I
just
kind
of
want
to
do
the
work,
whatever
we
think
makes
sense.
So
if
someone
has
an
opinion,
I
will
like
to
follow
whatever
that
is.
Oh
six
or
seven,
a
little
bit
of
both
doesn't
really
matter
to
me.
F
F
That's
a
good
question.
My
gut
feeling
is
like,
let's
just
cram
it
all
into
011,
although
it
will
slow
things
down,
because
we've
made
a
serious
commitment
to
do
all
of
stackpacks
and
07
the
api,
07
and
lifecycle
12
right.
I
think
getting
this
groundwork.
There
will
make
that
easier.
Otherwise,
12
is
going
to
be
a
bit
of
a
bear,
but
it's
just
like
a
light
opinion
like
I
could
be
tucked
out
of
it
at
the
end
of
the
day.
Don't
have
a
really
strong
preference
here
other
than
a
preference
for
organization.
B
I
will
add:
well
so
we
were,
I
think,
maybe
it's
already
been
moved,
but
we
were
kind
of
feeling
uncertain
that
the
windows
sid
stuff
would
make
this
release.
Maybe
that's
something
that
we
should
you
know
if
we're
going
to
do
this
phase
reversal
and
extend
the
you
know
ship
date
for
011.
Maybe
that
gives
us
more
room
to
also
do
the
windows
stuff.
B
B
I
think,
as
long
as
we're
not
you
know,
sitting
idle
right
like
waiting
for
the
phase
reversal
to
go
through
like
we,
I
mean
there's
plenty
of
stuff.
We
can
pick
up
in
the
meantime.
You
know
like
I
think.
Maybe
we
should
just
aim
for
that
and
then,
if
we
find
that
it's
taking
really
long
and
and
you
know,
we
want
to
unblock
ourselves
and
we
can
just
decide.
B
F
B
All
right,
I
guess
I
think,
we've
we've
covered
release
planning,
so
I
guess
next
on
is
needs
discussion
which
we
had
this
was
this
just
remaining
from
last
week.
This
thing
this
label.
I
think
I
forgot
to
take
it
off.
We
talked
about
it
last
week
and.
A
G
B
Interesting,
okay,
I
guess
let's,
let's:
let's
do
we
want
to
talk
about
that
now
or
it
should
be.
Did
you
add
this
like
that.
G
I
actually
didn't
add
it.
I
was
about
to
add
it,
and
I
saw
someone
had
something
that
looked
almost
identical
there,
but
very
cool.
B
Okay,
let's
I
guess,
let's
just
keep
going
with
our
our
list.
No,
I
did
this
already.
Where
is
it
rfcs?
I
think
we're
probably
no
rfc's,
so
we
can
go
to
our
first
agenda
item
setting
flags.
E
Yeah,
so
I
put
this
after
a
very
short
discussion
that
we
had,
I
mean
in
our
team,
the
stand-up
today,
so
it's
still
regarding
the
the
same
opt-in
layer,
caching
issue
according
to
the
rfc
for
buildback
api
lesson06,
we
would
like
to.
I
think
we
also
talked
about
it
here
like
two
weeks
ago.
Maybe
so
we
would
like
to
send
a
warning
to
the
buildback
author.
E
E
Now
my
question
was
whether
we
want
to
fail
or
warn
also
when
the
user
set
the
flag
to
false,
because
in
this
case
I
mean
it
kind
of
we
don't
care
right,
I
mean.
Usually
the
user
won't
set
it
to
false,
because
if
they
don't
set
it
at
all,
then
it's
considered
as
false,
but
if
they
do
set
it
as
false
in
the
wrong
place.
E
So
do
we
still
want
to
warn
and
to
fail,
or
do
we
just
want
to
ignore
it,
or
what
do
you
want
to
do
and
then,
when
I
brought
this
up
in
our
team,
then
I
mean
it's
it's
it's
possible
to
do
this.
E
It's
not
like
the
way
we're
doing
it
right
now
right,
because,
when
we're
like
decoding
tamil
file,
we'll
just
set
it
to
false,
if
we're
doing
it
in
like
the
simplest
way,
I'm
sure
there
is
a
way
to
to
like
check
whether
the
user
set
it
to
false
or
whether
it
was
just
it
was
not
in
the
file
and
then
automatically
it
was
set
at
fault.
E
A
F
E
So
for
build
like
api
lesson06
will
warn
if
it
set
it
inside
a
type
table
and
for
built
like
api,
zero.
Six
and
up
will
fail
if
it's
at
it
at
the
top
level,
but
yeah
from
one
hand
I
mean
it's
like
the
user,
didn't
intend
to
do
anything
so
when
it's
he
said
to
false,
so
that
that's
fine,
we
can
theoretically
just
ignore
it,
but
maybe
it's
just
like
not
that
clean
to
ignore
it.
I
don't
know
it
just.
C
Yeah,
it's
a
little
weird,
I
would
say,
but
I
think
I
think
I
agree
with
emily,
but
it
would
be
nice
like
if
the
parser
like
had
a
list
of
warnings
like
if
we
were
like
use,
pointers
there
to
figure
out
that
they,
the
intent
of
whether
they
actually
said
it
or
not,
and
then
being
able
to
like
have
a
collection
of
warnings
to
admit
or
something
based
on
the
version.
But
I
I
don't
think
it's
worth
it
right
now.
E
A
B
Next,
one
that
I
put
was
was
the
analyze
detect
pr.
B
B
F
C
Yeah,
it
took
some
steps
yesterday
with
creating
a
couple
classes
to
interfaces
to
sort
of
express
the
some
stuff
that's
shared
between.
You
know
like
the
metadata
parser
from
cash
and
like
the
layer.
C
Interfaces
instead
of
having
to
set
up
those
additional
structs,
and
so
that
helps
a
little
bit.
I
still
have
some
concern
about
like
we
probably
need
to
be
pushing
those
into
like
an
internal
package
or
something
because
I
don't
really
want
to
grow.
Our
surface
area
like
I
have
some
concerns
around
that,
but
it
would
be
nice
to
kind
of
know.
C
What
steps
to
take
to
kind
of
get
this
over
the
line?
So
we
have
the
minimum
sort
of
viable
architecture
that
we're
okay
with
pushing
through,
I
don't
mind,
doing
some
additional
work
here,
but
it's
kind
of
flying
blind.
It's
really
kind
of
the
first
big
pr
that
I've
done
in
this
project.
So
I
don't
really
want
to
like
rewrite.
D
F
F
I'm
wondering
if,
like
maybe
when
we
want,
is
really
explicit,
like
like
a
package
for
each
api
version,
and
then
they
can
share
a
lot
of
internal
stuff
and,
like
maybe
that
means
every
time
we
have
an
api
version,
we're
like
copy
pasting,
a
bunch
of
things
over,
but
I
don't
mind
as
long
as
we
can
call
into
a
shared
package
for
complicated
stuff.
I
don't
mind
that
kind
of
duplication
in
order
for
it
to
be
explicit
and
easy
to
track
changes
over
time.
C
You
had
similar
thoughts.
I
was
actually
just
asking
some
folks
internally
here
about
like
testing,
because
I
will
say
that's
the
biggest
annoyance
in
doing
this
right
now
is
that
our
testing
for
me
is
set
up.
It's
just
really
hard
to
write
tests,
especially
when
you've
got
you're
juggling
multiple
platform
versions,
because
we
have
a
lot
of
duplicated
tests
because
we
sometimes
like
to
make
tests
underneath
a
when
statement
for
a
particular
platform
api.
But
then
sometimes
we
don't
and
it's
because
setups
get
complicated
and
mocks
get
complicated.
C
Scripts
and
like
the
main,
go
project
that
sort
of
set
up
the
world
anyway,
it's
something
to
kind
of
explore
when
we
do
decide
to
take
on
some
testing
changes
that
would
allow
us
to
potentially
set
up
things
like
the
architecture,
as
well
as
the
platform
api
and
potentially
have
scripts,
that
sort
of
set
up
some
stuff
and
then
execute
the
test
so
that
we
can
have
a
single
copy
of
each
test
and
then
some
variables
that
come
from
the
outside
in
and
you
know,
for
things
like
platform
apis
that
don't
support
something
anymore.
D
C
F
Even
if
the
first
pass
at
breaking
this
up
looked
like
you
know
for
a
new
api,
we
copy
paste
the
entire
test
file
and
then
make
some
changes
like.
Maybe
we
don't
refactor
the
tests
to
use
shared
stuff
right
away,
but
given
that
we
shouldn't
be
modifying
older,
apis
it'll
create
a
lot
of
code
that
we
might
want
to
refactor
later.
But
I
don't
think
you'll
create
a
lot
of
problems
because
we
won't
be
going
and
changing
the
old
one.
C
E
C
01
to
light
03
because
maybe
didn't
do
anything
in
o2
but
it'll
be
copied
when
something
changes,
but
it.
H
D
C
I
still
think
there's
at
least
some
architecture
work
to
do
to
get
this
across
the
line
around
the
conditionals,
with
like
the
cash
being
nil,
especially
and
not
being
nailed
depending
on
the
caller,
like,
I
think,
creating
something
there.
I
don't
know
what
I
have
to
take
a
look
at
that
figure
out
what
it
looks
like
again,
but
I
think
we're
gonna
need
to
have
like
two.
A
B
A
C
F
I'm
happy
to
help
and
spike
out
some
of
this,
because
I'm
pretty
interested
in
this
problem,
but
I
won't
really
have
time
until
the
beginning
of
next
week
to
be
particularly
useful.
There
that's.
C
C
Kind
of
concerned
about
my
time,
commitment
like
on
this
like
next
week.
I've
got
I've
got
to
spike
out
some
stuff
internally
here,
and
so
I'm
not
sure
I'm
going
to
be
able
to
like
do
anything
past
tomorrow
for
a
life
cycle
like
all
of
next
week,
maybe
dead
time.
So
I'm
not
convinced
we're
going
to
be
able
to
get
this
across
the
line
next
week
anyway,.
B
A
B
C
I'll
continue
kind
of
playing
around
with
that
pr
and
at
least
kind
of
factor
out
some
of
the
the
bad
things
that
it
probably
does
now
and
then
and
then,
if
we
want
to
copy
paste
test
or
copy
paste
into
another
package,
we
can
kind
of
port
some
of
this
stuff
over.
It's
fine.
If
we
decide
that
that's
worth
it
before
we
shift
but
I'll
get
kind
of
ready
in
a
state
that
could.
F
D
Yeah
yeah,
so
natalie
brought
the
subway
stand
up
and
it
sounded
like
pretty
low
risk
place
to
do
some
like
spiking
and
releasing
stuff
that
has
this
behavior
in
it
and
so
yeah
like
I
know
you
have
a
mountain
of
stuff
on
your
plate.
No
I've
never
seen
it.
I
just
know.
G
That's
true
yeah,
so
just
to
understand
this,
this
is
you
would
like
to
have
an
image
on
a
registry
that
could
contain
assets
and
be
used
by
like
windows
or
linux.
Platforms
like
it
would
just
contain
like
build
pack
caches
or.
D
Yeah,
so
it
would
contain
assets,
and
it's
a
little
weird
since,
like
if
I'm
giving
you
a
go
binary,
you
probably
don't
want
the
same
thing
for
windows
and
linux,
but
and
I'll
probably
look
a
little
bit
different,
but
I
think
there
are
some
things
in
the
paquetto
ecosystem
right
now.
That
could
benefit
from
something
like
this.
D
G
Yeah,
you
I
mean
so
if
you
did
want
that
and
these
images
you
wanted
them
to
be
pullable,
docker
pullable,
and
you
wanted
to
combine
layers
that
way.
You
end
up
getting
stuck
with
a
kind
of
a
quirky
image,
layer,
type
or
image
layer
format.
You
can.
You
can
get
pretty
far
by
just
omitting
the
os
flag
on
the
image
config
entirely,
then
any
demon
that
pulls
it
down
just
makes
it
its
own
os.
G
So
if
you
just
had
a
image
that
had
almost
an
entirely
blank
config
for
the
os
architecture,
os
version
all
those
ones,
it
should
be
pullable,
but
you
could,
but
then,
as
far
as
the
layers
go,
you
need
layers
that
are
both
rooted
at
forward
slash
and
have
a
files
prefix.
G
I
have
a
prototype
that
does
pretty
much
all
this
same
stuff
and
then
there's
hard
links
between
the
two
which
may
be
sim
links
that
makes
it
work
with
both,
but
the
quirky
bit
is
that
it's
it's
a
it's
a
very
strange
image
to
inspect
it's.
For
the
most
part,
it
looks
like
a
linux
image,
but
if
you
don't
require
it
to
be
docker
pullable,
then
you
know
maybe
you're.
You
have
some
other
options.
G
Technically,
we
had
a
bug
already
with
pac
where
windows
builds
were
were
pulling
in,
linux,
cache
images
and
it
was
all
working
just
fine.
We
didn't
actually
realize
it
was
making
linux
images
all
along,
but
we're
technically
going
to
undo
that
feature,
but
yeah
there's
not
there's
not
a
lot
that
would
get
in
the
way
of
of
of
doing
what
you
described.
G
It
would
just
end
up
in
kind
of
a
weird
with
weird
image
formats
and
we
hadn't
played
around
with
them
too
much,
but
I
think
you
kind
of
hit
on
the
head
is
you'd
want
to
validate
that
that
a
shared
cache
actually
does
make
sense
like
one
a
windows
app
would
use
the
same
as
a
linux
and
that
the
benefits
would
outweigh
the
the
strangeness
of
it
all.
D
Okay,
all
right,
I'm
wondering
if
you
could
slack
me
or
shoot
me
wherever
this
prototype
lives
just
so
I
can
look
at
it
a
little
bit
yeah
for
sure,
but
okay,
all
right.
I.
H
Sorry,
I
can
ask
you
know
just
on
this
topic
for
historical
context.
For
me,
I
guess
I'm
wondering
why
we
chose
to
store
things
on
the
registry.
This
way,
I'm
you
know
I
I
believe
manifest
has
manifest
lists
right.
That
could
essentially
just
point
to
different
images
for
different
os
types
right
and
then
it
can
be
sort
of
him
be
handled
transparently
to
the
user
right.
So
I
guess
I'm
just
wondering
why
this
direction
was
chosen,
for
you
know
historic
for,
for
me,
who's
just
sort
of
joining.
G
H
You
know
just
not
even
cache
images,
just
multi
os
images
in
a
registry
period
right.
G
I'm
pretty
sure
this
is
this
is
a
oh
is
that
to
dan
we
don't
actually
use
them
internally,
anyways!
It's
just
my
idea.
H
In
my
bed
I
thought
we,
I
thought
we
were
already
storing
multi-os
images
in
registries
right
now.
I
that's
what
I
thought
was
happening,
but
I
guess
not
yet.
G
Not
in
any
production
implementation,
just
really
in
this
prototype
I
came
up
with,
was
able
to
make
a
a
build
package
that
has
no
os
set
on
it,
and
the
layers
are
technically
compatible
with
with
any
daemon.
Okay.
G
Sorry
there's
build
packages.
Their
os
specific
build
packages
are
stored
on
registries.
Those
you'd
make
like
a
pack
build
dash,
dash,
publish
yeah.
Oh
wait,
wait,
that's
not
right!
Pac
build
pack
package
dash,
just
publish,
I
think
folks
will
have
to
verify
that
I
might
be
making
that
up.
A
B
F
G
G
Yeah
I
mean
the
fun
part
is
that
you
can
create
these
artifacts
as
build
packages
and
then
they're,
not
really.
You
can
create
them
in
different
ways.
Besides
having
pack
or
life
cycle,
do
it
and
play
around
with
them
and
they
can
exist
just
fine,
but
I
feel
like
once
you
start
to
make
it
a
supported
thing
inside
any
of
them.
By
by
having
pac
or
lifecycle
generate
them,
then
it
you
take
on
a
new
burden
of
support
and
risk.
D
G
G
And
I'm
digging
up
that
prototype
as
well
too
I'll
send
that
over
as
soon
as
I
find
it.
G
Yeah,
it
was
a
perfect
segue
into.
It
was
literally
the
same
words
I
was
going
to
type,
although
for
a
definitely
different
thing.
Just
as
far
as
the
questions,
I
was
going
to
ask
about
folks
thoughts
on
how
to.
G
G
The
idea
is
that,
in
order
to
allow
to
make
it
easier
to
make
a
new
os
specific
image,
we
would
change
the
constructors
for
image
util,
which
are
remote.new
image
or
local.new
image.
To
now
take
a
new
option
called
local
remote
dot
with
platform
and
passing
a
platform
would
do
two
things
it
would
if
you
pass
it
along
with
a
from
base
image.
G
G
G
If
you
did
it
for
linux,
instead,
you
did
linux
arm
it'd,
give
you
back
an
empty
linux
image
with
no
layers
at
all
and
the
nice
bit
that
this
gives
you
is.
It
fits
a
lot
with
the
current
way
that
we're
calling
image
util
or
the
new
image
constructors
inside
of
lifecycle.
It
also
fits
nicely
with
the
way
that
pack
is
calling
image
until
since
it's
optional,
it's
a
little
bit
easier
to
have
a
migration
plan.
G
In
there
a
lot
of
places
are
making
a
new
empty
image
and
then
calling
set
os
on
it
afterward
or
set
architecture.
You
don't
necessarily
need
to.
You
can
keep
doing
that
if
you
want
to,
but
if
you
pass
it
with
platform
instead,
it
the
main
up
shot
for
the
driver,
for
this
is
that
it
adds
the
shim
based
layer
in
there
for
you
automatically,
so
you
can
actually
start
removing
those
pieces
out
of
your
code
base.
G
So
I
guess
what
I
was
going
to
ask
is:
technically
we
can
start
introducing
this
in
lifecycle
first
and
not
require
pac
to
use
it
until
it
tell
whenever
they
want
to
wonder
if
that
feels
all
right
or,
if
there's
any
sort
of,
if
we,
if
we
really
want
pac,
to
drive
out
how
this
implementation
works,
I
don't
know
how
y'all
feel
about
that
or
if
we
have
image
util
changes
in
the
past
that
had
to
go
lockstep
with
lifecycle
impact.
F
That
whole
plan
sounds
great
to
me.
I
feel
like
we
can
adopt
it
in
imagery
until
I
mean
in
lifecycle
before
pack,
especially
because
it's
a
like
we're,
not
making
a
breaking
change
right,
just
an
additional
option,
which
is
cool.
The
only
question
I
had
based
on
your
prescription
is
that
you
mentioned
local
and
remote
images
and.
A
F
G
Yeah,
as
I
was
doing,
the
test
that
definitely
became
true.
The
only
thing
it
was
useful
for
was
architecture
potentially
creating
an
arm
image
on
a
md64
daemon,
but
we
could
hold
off
on
that
or
we
could
just
make
it
so
that
it's
not
a
with
platform,
but
it's
a
with
architecture,
kind
of
option
or
something
I
don't
know
if
you
had
a
a
preference
there.
G
Technical
question
yeah:
that
is
what
it's
doing
right
now
I
just
I
I
I
feel
fast.
If
they're
trying
to
change
the
os
and
yeah
os
version
is
a
weird
one,
I
was
trying
to
find
like
a
realistic
case
where
you'd
want
to
pick
that
but
yeah,
I
guess
it's
it's
there.
It's
a
field
technically,
there's
also
variants
and
there's
like
two
other
fields.
On
a
on
a
platform
related
to
that,
too,
I
introduced
a
new
struct
into
image,
util
image
util.platform,
just
so
we're
not
copying
ggcrs.
G
G
One
other
thing
related
to
that
is
ggcr
in
its
comments
for
its
own
platform.
It
says
that
it
kind
of
preferred
to
use
the
spec
there's
a
spec
implementation.
It
has
like
wild
card
selectors
and
stuff.
Most
of
those
are
to
support
manifest
list
choosing
I
didn't.
I
didn't
really
think
that
would
be
possible
because
it's
we're
not
really
looking
for
like
query
selectors,
but
it
did
start
to
make
me
feel
like
maybe
we're
overloading
things
with
both
the
manifest
list:
preference
and
the
default
os
field.
F
I
got
like
85
of
the
way
through
a
major
image
utility
factor
that
I
promised
you
all
a
very
long
time
ago.
That
does
address
some
of
these
problems
and
then
my
life
imploded
with
a
bunch
of
other
things,
and
I
didn't
get
back
to
it
yet,
but
I
feel
like
what
you've
described
is
a
really
good,
incremental
change
that
we
can
merge
now,
even
if
we
want
to
think
about
ways
to
change
the
architecture
in
the
future.
I
think
this
solves
our
current
problem
and
it's
clean.
It
works
well
with
our
other
stuff.
G
Pac
needed
a
bunch
of
unit
test
changes,
but
those
are
all
fixed
up.
So
that's
ready
to
go
even
if
we
want
to
hold
off
on
it.