►
From YouTube: Implementation Sync: 2021-01-07
Description
Meeting notes: https://bit.ly/38pal2Z
A
All
right
looks
like
the
agenda.
Do
we
have
anything?
I
thought
we
had
some
standing
items.
I
guess
not
really
all
right,
yeah
the
first
thing
on
the
agenda
someone
put
on
here:
what
type
of
validation
should
we
do
prior
to
releasing
a
lifecycle?
And
what
can
we
automate?
Someone
wants
to
kick
us
off.
B
D
A
I
don't
think
we
have
a
date.
I
know
emily
mentioned
it
and
released
yesterday
during
the
the
working
group
meeting
that
we
haven't
really
sussed
out
what
exactly
is
going
to
be
in
this
next
release.
So
I
think
it's
going
to
be
some
time
before
the
next
release
before
the
next
major
release,
at
least
I'm
sure
minor
releases
can
go
out
with
you
know
any
bugs
that
we
find
that
are
worthy
of
creating
one.
A
C
C
C
As
a
sanity
check
for
because
the
apis
aren't
finalized,
yet
as
a
sending
check
for
how
much
stuff
we
want
to
try
to
cram
into
these
apis
or
whether
we
want
to
do
both
platform
and
build
pack,
which
we
have
historically
been
doing
them
both
at
the
same
time.
But
if
we
thought
that
it
would
take
too
long
to
do
both
o6
apis
and
we
were
getting
near
the
point
where
we'd
been
uncomfortable,
because
we
were
waiting
too
long
for
a
release,
then
we
could
decide
to
do
just
platform
or
just
buildpack.
C
D
D
A
Out
how
to
test
like
some
of
the
stuff
that
natalie's
talking
about
now,
like
kind
of
working
backward
into
figuring
out
what
we
can
accomplish
and
how
to
beef
up
our
testing
and
automation
and
giving
that
time
to
run
through
towards
the
end
and
like
have
a
goal
in
sight.
You
know
I
don't
know
so
you
said
roughly
two
months
earlier
emily.
What
does
everyone
feel
about
like
march
1st?
Is
that,
like
I
don't
know,
I
guess
I
should
make
sure
that's
like
an
actual
date?
That's
not
a
weekend
or
something
first.
A
B
A
A
It
would
make
sense
for
those
to
be
like
features
and
bugs
for
life
cycle
itself,
not
the
automation
around
it,
because
I
think
there's
still
plenty
of
room
for
us
to
like
in
that
last
week,
to
like
sure
up,
you
need,
like
you
know,
as
we
test
those
things
that
have
been
submitted
and
they
fail
or
something
we
have
plenty
of
time
to
like,
and
we
don't
have
to
bump
the
release
for
for
that
sort
of
work.
Maybe,
but.
D
A
D
B
We
have
pack
acceptance
test
which
exercise
basic
life
cycle
functionality
and
then
as
a
one-off,
but
maybe
it's
something
we
could
continue
for
the
last
release.
We
had
our
techton
tasks
that
again
were
doing
very
basic
basic
builds,
but
you
know
kind
of
toggled
to
fit
our
needs
for
the
particular
feature
that
we
were
testing.
D
I
felt
that
while
I'd
be
creating
new
features,
where
like
it
was
a
problem
that
we
were
not
able
to
run
some
tests
and
see
that
we
didn't
break
anything,
so
I
think
we
should
prioritize
at
least
not.
We
talked
about
it
yesterday,
maybe
at
least
one
like
phase
per
release,
so
maybe
start
with
the
creator
or
like
something
else
that
you
think
is
more
important,
but.
C
I'm
inclined
to
do
sort
of
like
breadth
rather
than
depth
depth
first
for
these,
like
if
we
could
just
even
get
one
test
for
every
phase,
one
happy
path
test,
then
we'd
at
least
have
a
structure
where,
if
we're
adding
new
features
and
stuff,
we
can
it'd
be
easier
to
insert
there.
I
feel
like
that,
would
help
a
lot.
A
You
know
because
there's
plenty
of
pack
acceptance
tests
before
we
ship,
generally
speaking
at
least
like
some
of
it
at
least
the
normal
cases.
I
kind
of
feel
like.
I
wonder
if
it
makes
sense
to
have
some
sort
of
you
know.
Kubernetes
like
yaml,
like
you
know,
acceptance
tests
where
it
doesn't
have
to
be
technon,
but
it
needs
to
be
like
a
pod
that,
like
runs
these
in
different
containers,
potentially
as
different
users.
A
Maybe
even
using
the
lifecycle
created
scratch
images
or
maybe
not
you
know,
just
you
know
trying
to
figure
out
like
because
I
think
that's
sort
of
where
the
edges
are
weird.
It's
like
what
user
it
runs
as
and
like
some
that's
very
kubernetes
specific,
but
that's
really
our
target
platform
for
lifecycle.
I
would.
C
C
I
think
these
tests
sort
of
test
would
be
good
for
not
introducing
regressions,
they're,
probably
not
a
great
way
to
test
the
features
of
new
apis,
because
then,
all
of
a
sudden,
we
basically
be
upgrading
every
platform
for
the
new
apis
and
we
already
have
too
much
work
to
do.
But
I
wonder
if
like
when
we
cut
a
release
branch.
Maybe
we
want
some
automated
that's
when
we
can
start
doing
some
of
these
automated
tests
to
ensure
we
don't
have
any
regressions
against
pac
or
tecton.
C
E
C
E
Kubernetes
has
been
nice
to
suss
out
some
windows
requirements
around
file
permissions
that
weren't
exposed
by
docker
docker
does
some
magic
to
fix
file
permissions
that
that
kubernetes
doesn't
but
yeah.
I
think
I
don't
know.
I
could
definitely
look
in
to
see
what
yeah
what
the
techton
story
is
with
windows,
if
that
would
be
useful
and
if
it
just
if
we
just
know
for
sure
that
it
doesn't
work
and
it's
not
going
to
work,
that's
fine
too.
A
Techdown
regressions
seem
like
a
a
decent
target,
but
I
think
yeah,
the
just
using
kubernetes
instead
of
docker,
I
think,
is
my
main
like
concern
there.
Just
because,
like
I
said,
the
magic
that
docker
does
for,
you
is
just
doesn't
exist
in
kubernetes,
and
you
have
to
think
about
things
like
security
context
and
how
you
run
them
and
what
happens
if
you
don't
run
them
and,
like
you
know,
building
up
some
of
those
acceptance
test
at
some
point
would
be
beneficial
to
this
project.
A
A
C
D
D
A
A
A
C
Yeah,
I
think,
there's
two
big
parts
to
this.
One
is
just
like
building
and
publishing
lifecycle
binaries
that
can
run
on
on
arm,
but
the
other
one
is
making
sure
we're
doing
a
scene
build
so
that
you
know
we're
not
running,
build
packs
in
arm
and
exporting
on
amd
run
image
stuff
like
that.
That
would
just
create
broken
images.
C
A
Yeah,
I
guess
the
first
part
is
fairly
easy
to
tackle,
I
think,
but
if
it's,
but
if
it
ends
up
producing
unreadable
images,
then
that's
not
good,
but
I
think
if
we
assume
builders
are
running
x86
now,
then
that
would
be
a
good
first
step
right.
So
is
that
something
we
want
to
put
as
a
milestone
to
like
compile
these
for
arm
like
do
we
even
have
the
capability
to
test
these
on
arm
right
now?
I
guess.
A
C
E
E
So
I
think
all
this
like
being
super
explicit
about
is
a
good
idea,
but
to
the
ci
question
it
would.
It
would
be
kind
of
cool
if
the
runners
already
could
do
that
arm,
translation
and
then
we
wouldn't
have
to
get
into
a
whole
big
mess
of
well,
especially
if
we
start
to
go
into
kubernetes
based
integration
tests,
it
kind
of
explodes
our
matrix
of
runners.
A
C
So
definitely
I
wouldn't
stick
it
in
front
of
other
things
that
we've
been
saying
for
a
long
time
our
high
priorities,
but
I
think
the
sooner
we
could
do
it,
the
the
better,
but
that's
more
from
like
a
proactively
generating
excitement
perspective.
I
think
it's
something
that
would
get
users
excited,
but
I
don't
think
it's
more
important
than
solving
existing
big
problems
like
installing
os
packages.
A
Yeah
that
jives
with
what
I
think
as
well
yeah,
because
we're
already
seeing
support
internally
for
the
idea
of
stack
packs
people
are
starting
to
build
stuff
that
doesn't
have
the
os
packages.
They
need
we're
starting
to
see
some
more
interest
in
being
able
to
extend
that
way.
So
I
do
think
that
that
arm
is
behind
that
for
sure,
for
us.
E
E
A
A
D
D
C
B
Cool
I'll
just
say
in
the
in
the
one
minute
we
have
left,
I
don't
want
to
prolong
it
unnecessarily,
but
I
I
put
that
action
item
on
basically
what's
in
the
milestone.
Right
now
is
everything
that,
like,
I
think,
would
be
necessary
to
cover
the
06
apis,
but,
like
one
chore
that
we
said
was
important
but,
like
you
know,
we
can
throw
in
other
issues,
and
so
I'm
just
sort
of
inviting
that
conversation
which
we
can
have
whenever
like
please
come
forward
with
your.
You
know
like
the
issues
that
should
be
tagged
as
well.
A
C
A
C
C
I
also
think
the
sort
of
pre-work
that
joe's
been
doing
that
I
need
to
like
read
through
that
sort
of
just
provides
the
mix-ins
at
the
right
phase,
which
is
a
requirement
that
stipex
are
going
to
need,
but
it
could
be
done
totally
separately
and,
in
fact,
would
allow
us
to
validate
mixins
and
sensible
ways
that
we
don't
right.
Now.