►
From YouTube: Platform Sync: 2020-10-07
Description
* Status Updates
* Release Planning
* pack 0.14.1
* pack subcommands
B
B
I'll
kick
us
off
here
a
little
bit.
We
did
release
what
is
it
pack
o
fourteen
one,
so
we
did
have
to
do
a
patch
release
and
that
had
to
do
with
a
what
is
it
the
log
output
of
the
lifecycle
phases?
Essentially,
they
were
not
coming
out
the
way
that
we
would
expect
them
to.
Since
we
changed
the
way
that
we
were
interfacing
with
the
containers
via
the
docker
api.
B
We
did
get
that
resolved
fairly
quickly.
I
think
it
took
us
about
two
days
to
get
it
fully
out
there,
but
it
didn't
seem
to
have
much
of
an
impact.
At
least
not
a
lot
of
users
complained.
So
that
was
a
good
thing.
Let's
see,
that's
pretty
much
it!
I
could
talk
a
little
bit
more
about
some
of
the
other
things
that
we're
currently
working
on.
B
I
did
make
an
update
to
the
docs
just
recently
created
a
pr
for
the
install
instructions
for
a
pack.
I
went
ahead
and
compacted
them
into
like
tabs
and
stuff
to
make
it
easier
to
navigate
and
find
the
os
and
the
method
of
what
you
wanted
to
install
pack
so
that
pr
is
open.
B
Which
yeah
the
docker
delivery
pipeline,
which
was
ultimately
just
not
having
the?
What
is
it
some
of
the
dependencies
inside
of
the
action
any
longer,
based
on
the
way
that
it
functions
that
got
resolved
internally?
And
I
think
I
put
an
issue
out
there
for
david,
since
it's
david's
github
action
that
is
currently
being
used
to
be
able
to
resolve
that
long
term
and
just
internalize
the
action
for
us
to
solve
it
in
the
short
term.
B
The
other
delivery
pipeline
that
was
broken
with
is
arch,
where
it
was
looking
at
picking
up
the
checksum
files
instead
of
the
actual
binaries
the
executables.
So
that
was
relatively
easy
to
do
and
that's
been
resolved
yeah.
I
think
that's
pretty
much
it
for
me.
Anybody
else
have
any
status
updates.
C
I'm
not
sure
if
this
falls
under
platformer
implementation.
So
correct
me.
If
I'm
off
track
here,
but
for
the
windows
build
packages
we
decided
to
because
nano
server
is
going
out
of
support.
We
decided
to
have
the
base
image
be
kind
of
a
minimal
window
scratch
image
that
we're
making
micah's
making
currently
ourselves
so
that'll,
be
the
base
for
windows,
build
packages
and
kind
of
related
to
that.
C
I
think
andrew
had
put
in
a
pr
to
clarify
the
distribution.
Spec,
I
think,
is
what
he
sent
me.
So
we're
still
waiting
on
that,
but
no
other
updates.
Besides
that.
B
A
question
on
the
base
image,
so
when
we
say
scratch,
I
have
maybe
two
thoughts
on
the
implementation.
Is
it
that
pack
itself
is
going
to
create
an
ephemeral
scratch
image
at
some
point,
or
is
this
going
to
be
like
a
quote-unquote
scratch
image
that
lives
somewhere
and
if
so,
where.
C
I'm
inclined
to
say
the
first
one,
but
I
will
double
check.
I
think
the
idea
is
that
it
would
be
procedurally
created,
but
I
haven't
been
working
on
that
track,
so
I
will
ask
mike
and
get
back
to
you.
A
My
machine
is
responding
glacially
today,
I
think
I
think
I
might
have
to
do
it
old
school
turn
it
off,
but
turn
it
on
again
yeah.
So
just
a
little
update
to
the
the
output
format
for
inspect
builder,
I
have
put
up
a
draft
pr.
It's
failing
at
the
moment
because
go
mark
is
making
mocks,
which
disagree
with
our
metal
inter
or
which
is
an
interesting
one,
but
it's
it
should
be
an
end-to-end
experience
for
just
the
existing
human,
readable
format
and
the
json
format.
A
The
yaml
and
tommel
options
still
to
to
be
implemented,
but
it's
it
also
represents
a
change
to
the
the
library
interface
for
inspect
builder.
The
order
type
has
changed
in
that,
but
it's
pre-existing
calls
to.
It
should
work,
because
the
the
the
depth
field
is
by
a
very
addict
option,
but
it
also
represents
a
sort
of
refactor
to
how
the
command
is
put
together
and
tested.
A
I
sort
of
appreciate
some
feedback.
It's
it
looks
quite
big,
but
a
lot
of
it
is
not
sort
of
fundamental.
It's
just
supporting
stuff.
B
B
I
did
put
something
into
the
agenda,
which
is
the
sub
commands
and
kind
of
discussing
what
our
strategy
for
implementing
such
a
large
change
should
be.
We
could
basically
jump
into
that,
since
I
don't
have
anything
else
for
the
release
planning
all
right.
So
if
I'm
going
to
share
my
screen
real
quick.
B
So
if
any
of
you
are
aware
there
is
this
idea
of
changing
the
pac
cli
to,
instead
of
having
these
very
long
single
top
level
commands
more
or
less
break
it
down
into
individual
sub
commands
or
resource
based
sub
commands.
B
B
All
right
yeah,
so
this
goes
into
a
little
bit
more
detail
about
how
everything
would
work.
We
are
going
to
keep
some
top
level
sub
commands
yeah,
that's
a
weird
way
of
saying
it,
but
yeah
some
top
level
sub
commands
that
more
or
less
now
will
work
with
multiple
images,
for
instance,
inspect.
B
Instead
of
there
being
a
inspect
builder,
inspect
build
pack
and
so
on.
We
are
going
to
be
looking
at
some
of
the
met
some
of
the
labels,
sorry
on
the
oci
image
and
based
on
that
be
able
to
infer
what
type
it
is.
B
B
We
now
have
a
pretty
good
strategy
and
once
we
implement
it
for
one
type
of
config
resource
such
as
like
lists,
we
should
be
able
to
apply
that
same
logic
to
other
list
type
resource,
config
elements
right
things
that
you
know
we're
kind
of
talking
about
here
are
trusted
builders
versus
registries,
which
is
something
that
I
believe
travis
is
actively
working
on.
B
So
I
don't
know
I
just
kind
of
want
to
open
the
floor
and
and
talk
about
how
we
could
implement
this
in
a
reasonable
manner,
given
that
we
have
do
have
a
lot
of
concurrent
work
that
could
be
impacting
here
and
we
ultimately
most
likely
are
not
going
to
want
to
break.
You
know
users
of
pack
at
this
moment
right,
so
we
have
to
provide
backwards.
Compatibility
for
at
least
one
minor
version.
A
The
the
list
on
that
rfc
seems
to
be
a
little
different
to
the
list,
as
it
currently
appears
in
the
issue
in
a
good
way.
I
prefer
what's
in
the
rfc,
so
is
that?
Will
we
update
the
issue
to
to
reflect
the
content
of
the
rfc.
B
I
could
definitely
do
that.
I
guess
that
the
the
way
I
was
thinking
about
it's
like
historical
presence
right
and
the
rfc
taking
precedence
over
what
was
in
the
original
comment,
but
if
it
helps
clarity,
I
could
definitely
update
it.
A
I
yeah
so
I
think
maybe
we
could
keep
the
historical
reference
in
a
comment
or
something,
but
I
would
be
concerned
that
someone
could
begin
work
on
this
issue
and
and
not
think
to
reference
the
rfc.
I
think
I
would
make
the
assumption
that
an
issue
that
came
out
of
rfc
would
would
have
the
desired
end.
State.
B
Yeah,
I
wonder
if
maybe
the
alternative
right
could
be
to
close
this
issue
and
label
it
as
something
like
rfc.
You
know
required
and
create
a
new
issue
which
is
more
or
less
an
epic,
very
similar
to
blueprints
registry
and
then
just
kind
of
list
out
all
the
broken
down
individual
issues
where
we.
A
Yeah
I
do
I
like
what
the
rfc
came
up
with
when
the
the
issue
kind
of
hid
build
behind
an
an
image
parent
command
and
I
was
sort
of
like.
Oh
I'm
not
sure
we
want
to
not
have
pac
build.
That
feels
like
dropping
heroku
push
or
cf
push
or
whatever.
B
Yep
yeah,
that
was
all
you
know
at
length
discussed
and
there
were
going
to
be
aliases
and
stuff
like
that,
and
we
might
do
that
in
the
future.
Once
we
have
more
like,
I
think
the
biggest
point
of
contention
wasn't
so
much
that
we
didn't
want
to
hide
it
under
like
an
image
thing.
It's
that
we
didn't
know
what
to
name
image
like
we
wanted
to
stay
away
from
app
right
as
well.
B
B
Cool
all
right,
so
does
that
sound
like
a
good
strategy?
I
know
travis.
I
know
you're
online.
I
don't
know
if
you're
busy,
but
I'm
concerned
about
the
conflict
with
some
of
the
stuff
that
you're
currently
working
on
in
this
release.
C
B
Cool
then
yeah,
I
could
definitely
take
the
action
item,
as
we
mentioned
to
just
kind
of
break
it
out
into
individual
issues
and
maybe
circle
back
next
week
or
actually
I'll
be
out
next
week.
There's
my
announcement
so
also
go
back
whenever
we
get
back
together,
again
and
kind
of
show
off
what
we're
gonna
be
work
tackling
in
regards
to
this
particular
issue
or
epic.