►
From YouTube: Platform Sync: 2021-03-24
Description
Meeting notes: https://bit.ly/38pal2Z
A
All
right
we
are
now
recording
we
could
go
with
status
updates.
I
can
go
first,
since
I'm
speaking
there
were
a
couple
minor
issues
that
came
about
the
pack
release
earlier
this
week.
A
The
one
that
I
was
looking
at
right
before
this
meeting
is
for
updating
the
docs.
When
we
create
a
release
for
pac,
we
ultimately
update
the
docs
on
our
website
for
all
the
commands
and
stuff
like
that,
so
sam
noticed
that
they
weren't
getting
updated.
So
I
looked
into
that,
I
did
find
what
the
issue
was
and
just
put
a
pr
up,
basically
because
we're
using
it
as
a
library
or
pack
as
a
library,
we
were
pinned
to
a
very
specific
version
which
was
like
o13o.
A
So
we
need
to
upgrade
that
every
time
that
we
generate
the
docs,
so
I
just
added
that
to
the
makefile
to
you
know,
and
it
should
work
right,
so
yeah,
that's
kind
of
where
we're
at
with
that
any
other
status
updates
for
the
oh.
Actually,
I
have
one
more
sorry
techton.
We
were
finally
able
to
get
the
techton
stuff,
the
two
tasks
upgraded
into
the
tekton
catalog.
A
We
are
still
waiting
on
the
pipeline.
There's
some
minor
tweaks
necessary
there,
but
hopefully
we'll
be
able
to
get
that
out
soon
as
well.
All
right
now,
I'm
officially
done
anybody
else.
Have
any
status
updates.
B
I
suppose
I,
I
guess
I've
kind
of
been
trying
to
push
this
acid
cache
thing
along,
inevitably
get
it
to
the
end
of
the
road.
So
it's
functional
and
you
have
something
minimal
and
usable
yeah,
and
I
guess
other
than
that,
just
the
pack
release
and
trying
to
hack
around
some
of
the
issues
with
how
ubuntu
builds
packages,
which
is
like
really
a
nightmare.
B
A
A
A
Cool
we
can
move
on
to
the
next
item
I
put
on
here
cash
flags,
since
this
is
top
of
mind
right
now,
and
I
wanted
to
see
whether
or
not
we
wanted
to
kind
of
think
this
through
a
little
bit
as
part
of
this
meeting.
I
know
dan,
you
were
kind
of
you
know,
spearheading
this
for
a
bit
and
I
think
I
just
came
across
another
use
case
for
it
in
talking
with
somebody
about
how
to
use
pack
within
a
bit
bucket
the
bit
bucket
pipelines.
A
I
believe
this
is
the
correct
term
there.
So
for
some
context
here
I
have
the
screenshot.
There
might
be
a
little
tiny,
but
so
big
bucket
pipelines
have
this
kind
of
requirement
or
yeah.
I
guess
a
limitation
in
which
they
don't
support
named
volumes
at
all.
Right,
like
that
is
like
one
of
the
big
limitations,
then
the
secondary
one
is
that
the
bind
mounts.
A
The
only
volumes
that
you're
allowed
to
use
are
bind
amounts
and
they
have
to
be
to
the
path
of
the
what's
called
the
bucket
clone
directory
right.
So,
basically,
where
you
threw
all
your
your
source
into
it-
and
you
know
it's
it's
a
pretty
harsh
limitation,
but
to
some
extent
it
makes
sense.
A
I
wish
they
did
support
named
volumes,
because
then
we
wouldn't
have
this
issue,
but
nonetheless,
I
think
it
does
bring
up
the
kind
of
question
around
whether
or
not
we
want
to
enable
support
for
bind
mounts
for
caching
right.
So,
if
you
think
about
it,
the
lifecycle
essentially
provides
this
limit
or
provides
us
functionality
right.
A
So
if
you
think
about
it
right,
there's
nothing
stopping
packed
from
actually
providing
a
bind
mount
to
the
lifecycle
as
a
directory
and
so
essentially
saying
on
the
host.
This
is
the
directory,
where
I
want
to
like
cache
my
stuff
right
and
we're
talking
about
build
cache
in
this
case
so
yeah.
So
I
think
I
put
on
here
one
of
the
kind
of
like
you
know.
A
A
The
complexity
then
comes
with
like
how
do
we
determine
whether
we're
talking
about
a
named
volume
or
a
directory
right,
a
local
directory?
And
I
think
that's
where
dan
your
proposal
comes
to
mind,
because
it
allows
us
to
expand
on
these.
Like
you
know,
I
don't
want
to
say
infinite,
but
almost
infinite
options
right
that
we
could
provide.
A
The
other
thing
is,
I
believe
this
is
the
first,
and
only
time
that
we'll
be
kind
of
expanding
from
this
terminology
of
cash,
and
I
guess
externalizing
the
idea
of
a
launch
cache
right
and
the
launch
cache
is
only
used
with
the
dr
daemon
use
case.
It's
not
used
on
the
publish,
because
in
that
case
we
use
the
image
from
the
registry,
so
I
guess
any
questions
on
that.
I
know
I've
talked
a
little
bit
on
that.
B
Yeah,
so
I
guess
it's
like
if
I
have
a
question,
because
I
think
this
all
makes
sense,
but
it's
like
kind
of
the
philosophy
around
like
what
we're
doing
here,
where
it's
we
are
adding
features
like
one
by
one
by
one
and
now
we
are
hitting
this
point
where
it's
like.
B
B
Maybe
we
don't
have
all
the
functionality
right
out
of
the
gate
like
but
yeah,
I
guess
yeah,
which
is
kind
of
like
where
I
think
this
like
got
stopped
last
time
right,
which
is
like
because
our
like,
if
I
provide
a
cli
interface
that
implies
you
can
do
something.
Do
I
also?
Oh?
Am
I
required
to
also
provide
all
the
implementation
of
that
right,
so
yeah.
A
I
think
where
I'm
at
right
now
personally
is
again:
I
I
definitely
feel
the
pressure
of
the
reoccurring
theme
right,
especially
when
you
know
the
simple
ask
was
like
hey.
I
just
want
to
be
able
to
name
this
volume.
However,
I
want
so.
A
I
could
then
look
it
up
right
or
reuse
it
for
whatever
purposes-
and
you
know
again,
there
were
some
opinions
early
on
whether
or
not
that
was
the
appropriate
thing
to
do,
but
given
the
fact
that
we
now
support
cache
image
like
it
makes
no
sense
to
not
provide
that
functionality
and
now
to
further
expand
it
to
this
right,
like
again,
bitbucket
is
just
one
use
case
right
but
like
if
I
wanted
to
literally
just
provide
a
directory
locally
to
you
know
my
workspace.
A
I
want
to
be
able
to
do
that
as
well.
Right
like
there's,
nothing,
stopping
us
or
nothing
should
be
stopping
us
there.
So
let
me
see
sorry
going
back
to
this.
The
proposal
that
you
have
right.
I
think
we
talked
about
the
complexity.
A
Oh,
this
is
the
proposal
all
right,
so
it
talks
about
cash.
Then
it
has
a
couple
of
like
options.
I
think
the
the
one
thing
that
I'm
still
worried
about
is
the
relocation
functionality
right
like
being
able
to
take
from
some
place
and
then
put
it
in
another
place
in
one
parameter.
I
think
that's
a
little
bit,
maybe
too
complex,
and
I
don't
think
we've
seen
yet
a
use
case
for
that
to
come
up.
A
B
I
mean,
I
guess,
like
my
my
question-
is
kind
of
like
we're
now
at
a
point
like
we've
had
some
asks
in
this
for
this.
These,
like
particular
sets
of
features
we're
at
a
point
now,
where
we're
gonna
like
come
up
with
a
new
way
that
people
can
figure
out
what
volumes
they're
using
where
they
come
from,
etc.
B
Do
how
general
do
we
want
to
make
it?
Do
you
want
to
make
it
just
big
enough
to
encapsulate
all
the
asks
that
people
have
made
right
now
or
like
do
we
want
to
make
this
a
little
bit
larger
so
that
upon
a
sub
like
if,
in
the
future,
someone
asked
for
this?
Oh,
I
want
to
do
this
new
thing
with
volumes
that
we
just
it
doesn't
fit
into
our
like
ui
very
well,
and
we
have
to
do
this
again,
where
we
re-define
exactly
how
the
flags
work.
B
A
I
definitely
think
we
want
to
strike
a
balance
right.
A
I
I
don't
think
we
could
really
say
that
we
can
go
one
way
or
the
other,
because
one
way
hypothetically
would
be
providing
a
flag
for
each
type
right,
similar
to
what
I
kind
of
you
know
grossly
just
throughout
here
right
like
build
cash,
launch
cash
and
then
like
you,
would
specify
like
if
we
really
wanted
to
expand
it,
it's
like
build
named
volume,
cache
or
something
right
and
the
other
one
would
be
a
directory
so
like
we
could
tell
the
difference
right
so
like
that
in
itself
seems
like
it's
already
breaking
down
right.
A
Then,
if
we
look
at
this
options
for
like
similar
to
the
docker
mount
stuff,
I
don't
think
it's
too
bad
right
like
I.
I
do
think
that
it's
reasonable,
especially
if
you're
thinking
about
like
just
how.
A
I
think
it's
like
a
linux
thing
right,
like
mounting
disk
options,
essentially
right
and
being
able
to
provide
like
this,
is
the
general
type
right
like,
let's
say
again
volume.
So
I
I
have
three
in
mind
right.
It's
like
directory
or
bind
mount
right
like,
however,
you
wanna
spell
it
out,
then
there's
a
volume
which
will
associate
with
a
named
volume
and
then
there's
an
image
right.
So
those
are
the
three
types
of
caches
that
could
be
or
mechanisms
again
loose
on
the
terminology.
A
A
I
believe
we
use
the
same
thing
for
both
right,
build
and
launch
caches
for
the
other
two
we'd
have
to
like
be
able
to
separate
both
of
them,
so
that
gets
a
little
bit
complicated
and
then,
lastly,
would
be
additional
options
per
the
types
right
so
for
like
an
image
type,
you'd
have
to
give
it
a
url
for
the
named
volume
you
just
have
to
specify
a
name
for
the
directory
or
bind
mount
you'd
have
to
specify
a
local
path
right.
So
again,
I
think
those
options
right
there.
A
B
A
So
the
action
item
from
here
would
be.
I
guess
I
could
write
down
like
what
I
just
mentioned,
but
I
think
dan,
I
don't
know
if
you
want
to
like
drive
this
all
the
way
to
the
rfc.
A
B
A
All
right,
moving
on
to
the
next
topic
pack,
refactor
rfc
question
mark.
B
B
B
So
I'm
I'm
not
going
gonna
go
all
the
way
through
this
again.
I
think
joe
just
left
me
a
little
bit
of
feedback.
Okay,
but
I
guess
the
the
big
thing
that
I'm
looking
for
is
like
some
maintainer
consensus
around
this
chain.
These
changes
before
like
moving
on,
because
I
feel
like
that's
the
first
level
of
concern
right
like.
A
Cool,
could
you
maybe
I
guess
the
questions
I
have
is
were
any
of
joe's
comments,
things
that
require
a
little
bit
deeper
thought,
or
were
they
just
very
like
high
level.
A
A
That
makes
sense,
and
then
alternatives?
That's
probably
something
worth
thinking
about.
I
don't
know
that
they're,
like
the
alternatives
that
I
always
like
to
put,
is
like.
Do
nothing
and
just
live
with
pain
forever,
so
I
don't
know
if
you
want
to
throw
that
on
there,
but
you
could
also,
I'm
sure,
come
up
with
something
slightly
different
cool
I'll.
Definitely
take
a
look
at
it.
Have
there
been
any
major
changes
since
the
last
time
I
looked
nope
nope,
okay,
oh
yeah,.
B
A
Yeah,
I
think
it
was
after
we
broke
it
up
into
like
almost
like
phases,
right.
A
All
right,
yeah
again,
this
is
probably
one
of
the
first
rfcs
for
the
platform
specific.
Only
so
we'll
iron
out
some
wrinkles
there,
hopefully
it'll,
be
smoother.
B
Yeah,
I
guess
the
next
question
on
this
is
just
like.
I
could
present
this
in
the
rfc
group
today,
but
then
it
immediately
goes
out
of
right.
It's
just
like
immediately
jumps
that,
like
point
where
the
maintainers
have
like
control
or
say
over
what's
happening
exclusively,
which
seems
like
it's
kind
of
what
we
want
to
do,
and
so
it
feels
a
little
awkward
being
like
okay,
well,
whatever
I'll,
just
like
slam
this
through
and
not
use
the
new
process
that
we
want
at
all.
A
If
you
may,
could
you
ping
david?
I
don't
think
I
saw
his
review
on
there,
but
just
ping
him
to
kind
of
get
get
a
review,
because
I
think
if
we
get
myself
and
and
david
that
should
be
sufficient
to
then
go
to
the
working
group
and
say
like
this
was
looked
at
by
the
platform
maintainers.
You
guys
should
just
take
it
right,
or
at
least
a
little
bit
more
on
that
side.
B
Yeah,
okay,
yeah
we'll
do
I've
added
him
in
the
ish
in
the
rc,
but
I'll
like
slack
him,
yeah.
A
Awesome
thanks
cool
anything
else.