►
From YouTube: Implementations Sync: 2020-09-03
Description
* Windows - Make changes to spec requiring PATH
* Stack buildpacks PoC and Kaniko for Windows
A
Alrighty
so
yeah
make
sure
that
you
sign
in
to
the
doc
attached
to
this
meeting.
If
you
need
a
link,
please
let
me
know,
I
know
of
a
few
people
that
are
out
today
and
spring.
One
is
also
happening,
so
I'm
not
entirely
sure
if
we'll
get
too
much
conversation
in
here,
but
glad
whoever's
here
can
still
be
here,
and
we
could
maybe
talk
about
something
if
we
need.
A
A
Okay,
I
could
get
us
started.
Yeah,
let's
go
through
the
agenda
items
again
feel
free
to
add
anything
to
the
agenda
that
you
think
we
should
be
discussing
today.
A
As
far
as
status
updates,
I
can
relay
some
information
prior
to
some
individuals
being
out,
which
is
there's
a
new
rfc
that
was
discussed
yesterday
in
the
working
group
meetings
in
regards
to
process
types
and
essentially
changing
it,
so
that
build
packs
themselves
define
what
the
default
process
type
should
be.
It
seems
like
there's
going
to
be
a
pretty
good
amount
of
discussion
necessary
there.
So
not
a
lot
of
you
know
tangibles
just
yet
yeah
anybody
else
have
any
other
status
updates
in
regards
to
the
implementation
side
of
things.
B
Not
much,
I
think,
I'm
gonna
try
to
spend
some
time
on
stack,
packs,
joe's
pr
and
kind
of
get
familiar
with
that
and
kind
of
help.
Push
that
proof
of
concept.
I
guess
to
a
state
in
which
we
can
discuss
and
push
further
to
finalize
the
rfcs
that
are
in
flight.
For
that.
C
I
guess
I
can
chair
rfc
related.
We
have
a
rfc
and
a
potential
spec
change
related
to
windows,
all
around
requiring
the
image
configs
to
require
a
path
environment,
variable
that's
in
the
works
and
we'll
probably
be
opening
up
the
rfc
early
next
week.
At
this
point,.
A
Okay,
any
other
status
updates
all
right.
Let's
see,
release
planning
from
what
I
hear
there
is
something
in
the
works
that
is
being
you
know
I
guess
going
to
be
released
soon.
That
was
that
that
was
one
of
the
things
that
they
were
working
on
prior
to
you
know
being
on
vacation
in
spring
one.
A
A
Cool
all
right,
we're
in
the
dark
over
here,
okay,
so
yeah
I
mean
I
am
curious,
just
because
I
guess
maybe
some
more
insight
to
the
platform
side
of
things,
or
at
least
at
minimum.
The
learning
side
of
things
in
regards
to
the
spec
changes
that
you're
referring
to
micah.
A
How
does
that
impact?
The
end
user,
typically
like
a
lot
of
our
tutorials,
have
very
basic
setup,
and
are
we
saying
that
you
know?
Essentially,
this
is
necessary,
just
in
general,
to
be
added
to
every
base
image
and
we're
saying
that
the
default
base
images
don't
come
with
this
information,
so
it's
kind
of
like
a
mandatory
thing
that
we
have
to
add
on
top
of
the
maybe
microsoft
provided
images.
C
C
The
hope
was
that,
since
stack
authors
are
fewer
in
number
than
buildback
authors,
they're,
you
know
would
be
a
little
bit
less
of
a
impact
to
them,
but
yeah,
it's
still
as
far
as
the
user's
concerned.
It
would
still
be
a
manual
step.
They'd
have
to
do.
C
Cool
and
especially
in
a
case
where
they
would
want
more
than
just
the
path
more
than
just
the
shell
part
of
the
path
in
there
too,
there
might
be
some
tooling
or
some
other
things
that
the
spec
would
force
the
spec
wouldn't
mandate
it,
but
an
implementer
would
probably
want
to
make
that
experience
better
for
a
user
just
reminding
them
say
when
they
run
pac,
create
builder
or
any
life
cycle.
That's
going
to
export
an
image
or
deal
maybe
come
into
contact
with
validating
all
the
current
image
metadata
or
image
config
metadata.
C
They
might
want
to
give
an
error
message
that
would
say:
hey
here's,
how
you
do
it
or
here's
a
value
that
would
be
sufficient,
but
sadly
we
can't
just
due
to
various
constraints
of
the
situation.
You
can't
really
read
the
value
that
the
exact
value
that
they
should
use
and
it's
not
very
easy
to
for
the
same
reason:
it's
not
very
easy
to
just
solve
it
for
them
by
copying
it
over
those
registry
windows
registry
hives
is
where
the
actual
data
is.
C
I'm
definitely
interested
in
getting
that
kind
of
feedback
on
the
spec
when
it
comes
up
to
an
rfc
I'll.
Try
to
repeat
the
what
I
said,
but
you
know
happy
to
happy
to
discuss
it
and
pros
and
cons
and
whatnot.
C
A
A
All
right
anything
else
that
we
should
be
discussing
today.
A
Yeah,
we're
gonna
try
to
keep
a
very
strict
separation
of
concerns
here,
yeah.
That
means,
but
it's
it's
slightly
life
cycle
related.
I
guess
that's
kind
of
where
my
question
is
gonna.
Be
is
whether
or
not
this
impacts,
multiple
platforms
right
from
a
life
cycle's
perspective,
and
I
don't
think
it
does
right.
I
think
it's
to
your
point
very
specific
to
maybe.
A
C
I
was
gonna,
throw
it
just
as
a
question
for
for
jesse
the
I
look
briefly
at
the
sorry
they're
not
called
stack
packs.
The
stack
build
packs
it
looks
like
kaneko
is
potentially
pretty
I
mean
it.
There
might
be
some
very
small
changes
needed
for
windows,
but
it
looks
like
it's
operating
on
a
level.
That's
not
going
to
be
too
os
specific.
C
That
was,
I
guess.
If.
B
Yeah,
I
don't
know
if
kaneko
works
on
windows
at
all,
but
but
the
but
yeah
the
implementation.
He
did
try
to
put
some
effort
into
making
sure
that
at
least
sort
of
had
a
hook.
C
C
C
It
probably
doesn't
right
out
of
the
box.
I
looked
at
the
source
for
it
and
everything
that
it's
doing
in
terms
of
unpacking
the
tars
and
inspecting
through
the
apis
and
stuff.
All
pretty
straightforward
I'd
be
interested
when
you
feel,
if
is,
that
kind
of
in
a
in
a
stable
place
as
far
as
the
pr
goes,
as
far
as
how
it's
going
to
change
like
is
now
a
good
time
to
try
it
out
on
windows,
specifically
stack
buildback
stuff.
I.
B
Don't
I
doubt
it
I,
I
doubt
it's
quite
there,
yet
I
don't
think
it's
actually.
I
don't
think
the
exporter
work
has
been
done
at
this
point,
so
I
think
it's
running
the
build
packs,
but
I
don't
think
we're
actually
like
re,
taking
this
snapshot
of
tars
and
putting
them
in
the
actual
export
part
and
unless
joe
finished,
that
up,
while
I
wasn't
looking,
which
is
you
know
possible
as
well,
but
I
think
exporter
that
stuff
is
not
done
yet.