►
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
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
C
A
A
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
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
C
A
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.
B
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.