►
From YouTube: Implementation Sync: 2021-07-07
Description
Meeting notes: https://bit.ly/38pal2Z
A
It
you
anthony
there,
you
go
okay,
so
I
guess
let's
do
status
updates.
I
can
kick
it
off.
I
don't
have
much
to
report,
I
mean
you
know.
Everybody
else
has
been
doing
the
coding.
Oh
I
did.
I
did
put
up
a
pr
to
run
the
pac
acceptance
tests
in
our
github
actions,
which,
for
anyone
who
ever
had
to
scramble
to
find
a
windows
environment
so
that
you
could
run
pack
acceptance.
A
B
B
These
platforms,
0
7
pr
first
that
was
merged,
and
then
I
was
you
know
changing
whatever
part
was
affected,
and
then
there
is
this.
Another
conversation
opened
that
can
affect
the
way
I'm
doing
the
validation.
So
I
was
checking
that
to
see
you
know
what
what's
going
on
there,
but
I
think
I
will
keep
this
vr
there
just
waiting
for
some
other
clarifications
and
some
other
parts
right
before
merging
something
that
you
know
we
will
be
rolling
back
and
you
know
I
think
so,
it's
better
just
for
me
to
keep
an
eye
on.
B
B
I
so
I'm
working
on
I'm
working
on
an
issue
to
make
the
cmv
assets
environment
variable
show
up
conditionally
right
if
asset
packages
are
supported
both
in
the
build
pack
and
the
platform
turned
out
to
be
a
little
bit
more
acrobatics
than
you
know,
first
thought,
but
it's
all
right,
I
I
think
I
put
the
bulk
of
it
up
still
in
draft
mode.
I
just
wanted
to
go
back
on
to
make
sure
I
got
all
the
tests
right.
All
the
all
the
test
coverage.
B
Good
luck
again,
jesse
hi
emily,
so
I
was,
I
think,
mostly
out
since
the
last
time
we
talked
we
met,
I'm
sorry
and
since
I'm
I
was
back,
I
mostly
reviewed
some
prs
and
rfcs,
so
I
didn't
have
a
lot
to
share.
I
started
looking
at
one
of
the
life
cycle
bags
this
morning,
so
I
don't
have.
I
still
don't
have
updates
on
this.
A
D
Opening
up
that
conversation
feels
a
little
bit
bad,
so
we've
just
done
this
with
stack
packs,
but
I
do
think
we
probably
should
have
that
conversation,
maybe
tomorrow
at
working
group
before
we
ship
the
life
cycle
and
maybe
a
little
bit
here,
I'm
just
curious
to
get
this
smaller
group's.
Take
on
that.
B
Absolutely
I
think
the
concepts
are
just
at
least
to
me
they're
very
similar
and
the
use
cases.
You
know
it's
very.
It's
very
blurry,
I
think
it'd
be
nice
to
just
from
a
design
perspective,
to
understand
like
holistically
what
the
different
use
cases
like
tailored
to
best
and
like
at
least
so.
The
documentation
at
least
will
like
be
clear.
D
D
But
they
do
have
a
solution
for
that
that
works
for
them
most
of
the
time
in
a
way,
that's
transparent
to
end
users,
just
like
a
little
bit
ugly
it'd
be
nice
to
have
a
standard
in
the
project
right,
but
it's
not
practically
a
burning
issue
nothing's
on
fire
when
we
don't
have
it.
Unlike
some
other
problems
which
are
more
actively
bothering
our
end
users.
A
A
A
Milestone
so
there
are
four
issues
this
one
at
the
top
is
the
chore
that
I
mentioned
in
my
status
update.
This
should
be
I
mean
pending,
I
can
assign
myself,
but
this
should
be
pending
pr
review.
Hopefully
we
can
get
that
merged
in
and
this
one
from
one,
I
think,
maybe
deserves
a
bit
of
discussion
because
as
one
as
you
mentioned
in
your
update,
there
is
an
open
question
on
the
spec
about
what
should
the
platform
api
really
look
like?
A
C
A
Okay,
all
right,
let
me
know
if
I
can
get
some
more,
but
I
guess
the
question
is
you
know
we
backed
out
the
changes
to
analyze
tamil.
There
was
a
bunch
of
schema
changes
that
were
no
longer
necessary
if
we're
not
validating
mixins.
But
I
guess
the
question
is
now
that
we're
validating
read
access
to
the
run
image.
Does
it
make
sense
to
pass
that
along
to
the
exporter
so
that
we
ensure
the
exact
same
run?
Image
is
used
during
export
and
then
there's
been
a
little
bit
of
conversation
about
that.
A
I
don't
know
if
anyone
wants
to
speak
to
either
of
these
options.
I
I
sort
of
put
forward
a
third
option
of
just.
Can
we
just
proceed?
What's
so
bad
about?
You
know
we're
just
providing
a
convenience
to
the
user
and
failing
fast
if
they
can't
actually
read
the
run
image,
but
I
don't
know:
are
there
any
strong
opinions.
D
D
So,
if
you're,
like
really
looking
at
the
tag
or
using
a
different
input,
sort
of
what's
the
run
image
in
one
phase
might
not
actually
be
the
run
image
in
a
later
phase.
Just
for
checking
read
access.
It
really
doesn't
matter
that
much.
You
know
you're
trying
to
help
people
out,
but
but
it
won't
matter
so
much
if
you
fail
later
it's
like.
Well,
that's
a
weird
thing
you
did.
D
I
do
have
a
tiny
worry
that
if
we
don't
lock
it
down,
it
is
an
opportunity
for
bugs
to
come
in
later
based
on
race
conditions.
It's
like
if
we
in
the
future,
without
thinking
better
like
oh
we're,
just
assuming
that
run
image
is
correct,
but
really
we're
resolving
it
twice
and
it
could
have
changed
or
be
set
with
a
different
input.
That
seems
like
an
opportunity
in
the
architecture
for
us
to
introduce
issues
eventually.
C
I
don't
have
a
strong
opinion
either.
I
do
like
the
idea
of
fetching
the
digest
early
so
that
we
are
talking
about
the
same
image
throughout
the
process.
I
think
it
could
simplify
some
of
the
some
of
the
code
that
has
to
go
out
and
check.
Some
of
these
things
later
on,
like
we
should
be
able
to,
you,
know,
make
sure
that
we're
not
as
an
image.
E
E
C
E
Before
the
build
kicks
off
and
resolve
a
digest
to
something,
then
it's
like
you
know,
I
think
it
makes
sense
to
pass
the
information
forward
because
we've
said
this
is
the
one:
that's
not
just
accessible,
but
it's
also,
you
know
we.
We
failed
fast
because
we
checked
the
metadata
on
this
particular
revision
of
it
and
that
that
feels
like
a
stronger
argument
for
passing
a
digest
forward,
then
not
doing
that.
But
if
it's
really
just
read
access
like,
I
don't
even
know,
if
I
guess
it's
like
kind
of
convenient
to
fail
fast.
C
E
If
it's
just
validating
that
you
can
access
it,
though,
maybe
that's
something
we
should
push
into
the
platform,
because
I
could
see
a
platform
like
you
know,
kpac
that
validation
may
be
extraneous
because
they
pre-validate
their
images
in
a
different
controller,
or
you
know
like
it
feels
like
it's
having
the
life
cycle.
Take
a
strong
opinion
about,
maybe
something
that's
a
little
bit
outside
of
its
domain.
But
I
would
disagree.
D
Because
the
life
cycle
has
to
eventually
read
this
image,
to
succeed
so
being
able
to
read
it
isn't
really
outside
of
its
domain,
and
there
could
be
some
nuances
in
the
way
credentials
are
passed
from
the
platform
to
the
life
cycle
or
the
way
we're
consuming
the
credentials
that
still
cause
it
to
break.
Even
if
the
platform
gives
it
the
thumbs
up,
there's
a
bunch
of
like
weird
edge
cases
with
like.
Is
there
a
trailing
slash
on
your
registry
and
your
docker
files?
Stuff,
like
that?
D
E
E
In
the
future,
we
probably
want
to
do
them
early
anyways.
So,
for
the
same
reason
like
you,
don't
want
to
pick
a
bad
run
image,
you
don't
want
it
to
fail
during
export,
and
so
I
think
that
that
works
well
with
blocking
down
the
digest
future.
Looking,
maybe
other
validations
could
happen
there,
and
so
it
works
out
architecturally
towards
the
same
thing.
D
B
A
So
that's
why
it's
kind
of
pushing
for
keeping
things
as
they
are,
but
at
the
same
time
I
don't
think
like
all
worshipping
right
with
this
life
cycle
at
the
end
of
the
day,
is
this
reversal
of
the
phase
ordering
plus
baby
asset
packages?
You
know
it's
like
a
very
small
feature
set,
and
so,
if
we
are
comfortable
delaying
that
to
make
it
more,
I
guess
complete
or
what
we
want
it
to
be.
Then
you
know
that
seems
worthy
to
me.
D
D
I
feel
like
even
in
a
world
where
there
are
multiple
candidate
run
images,
we
might
want
to
check
that
they're
readable
during
analyzer,
anyways
right
and
then
eventually
lock
down
their
metadata
once
at
the
beginning,
and
we
can
trust
it
all
on
and
if
platforms
have
to
do
a
lot
of
work
to
accommodate
this
new
api
changing
the
phases.
I
incline
slightly
towards.
D
A
I
think
so
I
mean
it's
like,
on
the
one
hand,
I'm
like
cringing
inside,
because
because
we
haven't
shipped
the
life
cycle
for
a
while
and-
and
I
know
that
it
sounds
simple
to
change
that
schema,
but
I
have
that
draft
pr
that,
like
does
approximately
that-
and
it
was
a
big
change
but
personally
yeah.
I
think
if
we,
this
seems
like
the
right
way
to
do
it.
If
we're
going
to
invest
the
effort.
D
B
A
A
A
A
D
Oh,
should
we
label
those
with
the
implementation?
I
think
they
got
labeled
with
core
stephen,
which
is
something
we
usually
do
for
like
governance
stuff,
even
though
most
big
spec
changes,
you
know
they
touch
implementation
and
core.
I
might
relabel
them
because
I
think
it'd
be
easier
to
see
them
in
this.
E
A
Me
I
do
have
one,
I
guess
just
sort
of
meta
comment
about
some
of
these
rc's
like
maybe
this
is
just
you
know
me,
but
it
kind
of
feels
like
there's
so
many
sort
of
larger
changes
being
proposed
right
now
and
they're
all
kind
of
moving
at
their
own
pace.
But
it's
not
clear
to
me.
You
know
how
to
bring
them.
A
E
I
think
for
the
ones
I've
opened,
I'm
planning
to
respond
to
all
the
feedbacks.
There's
like
charles
from
red
hat,
just
asked
for
some
more
examples.
There's
just
a
bunch
of
comments
out
there
that
are
like
hey.
Can
you
clarify
this
part?
So
my
plan
is
to
respond
all
the
feedback
and
then
keep
answering
questions
until
nobody
says
anything
for
a
week
and
all
the
feedback's
been
responded
to
and
then
I'll
I'll
request
to
be
moved
to
fcp
to
get
approved.
D
I
do
wonder
this
even
given
that
we're
both
the
cycle
times
for
both
of
us
iterating
on
some
of
these
things
can
be
long
like
if,
if
someone
here
wanted
to
take
one
of
steven's
three
rfcs
and
be
responsible
for
making
some
changes
to
it,
you
know
with
us
syncing
up.
I
don't
want
to
speak
for
uc,
even
but
I
imagine
you
might
appreciate
that.
E
Yeah,
if,
if
anybody
feels
like
any
of
the
ones,
I'm
working
on
with
faster,
please
feel
free
to
make
suggestions
to
them.
Take
the
pr
over
completely
push
commits
to
the
branch
I
put
the
branch
on
the
project,
so
you
can
push
to
it
directly
if
you
have
access
to
life
cycle,
if
you
want
to
that's,
you
know,
any
of
those
things
is
fine.
I
have
no
no
attachment
to
them.
I
just
want
to
push
things
forward
and
a
bandwidth
limited
assume
emily.
You
feel
something.
A
E
E
E
A
B
A
D
D
D
D
D
Yeah,
I
think
pre-release
apis
was
supposed
to
be
around
like
we
think
we've
implemented
api
06,
try
it
out
and
or
like
maybe
we
haven't
implemented
it
all
the
way.
This
is
like
a
version
of
this
that
is
incomplete
or
unvalidated
feel
free
to
try
it,
but
we
don't
guarantee
it
support
with
the
same
level.
D
B
All
right,
I
definitely
like
to
talk
to
a
maintainer
about
this,
but
from
the
platform
perspective
from
my
perspective,
I
kind
of
I
kind
of
don't
want
this
in.
To
be
honest,
like
you
know,
it's
a
non-trivial
amount
of
code
to
maintain
right
and
again,
I
just
I
haven't
heard
like
a
lot
at
stake
here.
If
you
know,
I
think
it's
going
to
cause
more
harm
than
good
to
just
plop
it
in.
D
That's
my
fear
as
well,
given
the
moving
parts
around.
Actually,
the
asset
package
images
themselves
if
it
was
if
it
was
a
simpler
feature
like
there's
just
extra
layers
in
a
build
pack
or
a
builder,
rather
than
this
whole
new
artifact
concept,
I
would
feel
a
little
bit
better
about
it
in
terms
of
the
complexity
we'd
be
pulling
in
for
an
experimental
feature.
D
A
D
Be
some
sort
of
entered
assets
eventually
right,
there's
a
good
chance
that
we
end
up
flipping
that
back
on,
even
if
we've
changed
stuff
about
the
packaging
interface
or
exactly
when
they're
there
a
lot
of
that.
A
lot
of
the
things
that
are
contentious
about
that
rfc,
don't
actually
touch
the
life
cycle,
part
which
is
just
telling
build
packs
where
the
assets.
A
B
D
If
you
need
help
there,
one
of
us
can
help
you.
I
think
this
is
also
100
the
conversation
we
need
to
have
again
with
the
broader
working
group,
because
this
has
already
gone
through
the
rfc
process
and
I'm
sorry
to
make
you
all
do
it
twice?
I
just
sort
of
wanted
to
do
it
first
in
this
smaller
group.
A
A
D
I
feel
bad.
The
sub
team's
had
to
deal
with
a
lot
of
churn
due
to
waffling
in
the
decision
making,
but
I
think
it's
going
to
be
worth
it
in
the
end,
because
our
choices,
I
think,
are
deal
with
the
churn
now
or
deal
with
another
large
set
of
braking
changes,
potentially,
which
is
annoying
for
the
life
cycle
in
its
own
way.
Because
you
have
to
maintain
all
the
permutations
of
the
api.
A
A
A
A
A
Anyway,
I'm
sorry,
I
should
have
prefaced
this
whole
thing.
I
think
we
talked
about
in
the
fact
in
the
past
that
you
know
the
core
team
is
very
busy,
and
so
we
should
try
to
as
we
can
contribute
to
the
spec
the
changes
that
we
want
to
see
reflected.
So
that
was
my
purpose
in
going
through
these.
I
don't
know
if
that's.
D
B
D
A
I
I
think
I
remember
actually
dan
included
in
his
original
pr.
It
was
a
pr
to
both
the
platform
and
the
bill
pack
files
and
then
we
said
we'll
never
change
both
files
in
a
single
pr
and
and
remember
that
the
change
the
platform
221
for
platform
changes
which
has
already
been
merged.
So
there
we
go
remember
these
changes
were
not
strictly
required.
They
were
just
kind
of
clarifying
that
prefix
list
mix-ins
affect
both
images.
This
is
even
just
like
a
nice
to
have.
A
D
D
A
A
Actually,
this
is
these:
there
are
61
open
issues
on
the
life
cycle
and,
like
a
fair
amount
of
them,
relate
to
snack
packs.
So
I've
omitted
those,
but
also
a
fair
amount
of
them
are
chores
which
actually
might
be
valuable
to
look
at
as
well,
but
I
don't
I
mean
I
don't
know
if,
like
just
going
through,
all
the
issues
is
going
to
be
helpful
here.
A
So
I
guess
you
know
kind
of
my
question
at
least
is:
does
anyone
have
a
sense
of
what
we
should
focus
on
once
we
get
through
this
period
of
reversing
the
phases,
and
you
know
fast,
validation
of
registry
access.
All
that
stuff
like
there
are
a
number
of
different
directions.
We
could
take
this,
so
one
of
the
things
we
talked
about
is
like
all.
That's
why
I
have
all
the
chores
here,
like
the
various
improvements
that
we
want
to
make
to
the
code,
to
make
it
easier
to
change
in
the
future.
C
C
Ask
a
question,
but
what
I'm
wondering
if
we
should
start
cutting
releases
and
leaving
them
like,
like?
I
don't
know
whether
a
life
cycle
should
support
like
all
versions
forever
like
it
feels
like.
We
should
maybe
try
to
restrict
that
down
to
you
know.
The
latest
version
supports
the
latest
life
cycle
and
if
and
we
can
go
back
and
patch
for
security
vulnerabilities
of
the
older
ones,
like
I'm
just
wondering
if
it's
just
getting
so
complicated
because
we
have
so
many
different
spec
versions
and
build
pack
versions
that
collide
all
the
time
like.
D
C
Yeah,
I
think,
that's
that's
kind
of
what
I
had
in
mind.
It's
like
one
per
platform
and
like
maybe
the
platform,
each
platform
only
supports
the
you
know
a
a
minimum
bill
pack
version
as
well
just
to
kind
of
move
things
along,
but
if
it
made
it
easier
to
support
all
build
packs
across
all
platforms
that,
I
think
I'm
fine
with
that
too,
but
just
reducing
another
matrix
the
platform
and
build
right.