►
From YouTube: Platform Sync: 2021-02-24
Description
Meeting notes: https://bit.ly/38pal2Z
A
A
All
right,
let's
get
started
so
the
first
thing
on
the
agenda
status
updates
since
I'm
already
talking
I'll
go.
First,
I
added
to
the
agenda
the
techton
build
packs
pipeline,
which
is
a
a
new
thing
that
we're
going
to
be
adding
to
the
tecton
catalog.
I
could
go
into
a
little
bit
more
detail
there,
as
maybe
a
notable
mention
myself
and
dan
are
setting
up
a
windows
work
station
on
equinix
metal.
A
I
think
that's
how
you
pronounce
it,
and
so
this
hopefully,
should
enable
a
lot
of
the
windows,
debugging
and
development
to
be
a
little
bit
more
accessible
to
those
that
either
might
not
have
a
vm
available
or
a
windows
machine.
You
know
physical
windows,
machine
available
and
so
we're
making
this
available
to
any
verified,
contributor
and
maintainer
of
the
project.
So
we'll
have,
I
think,
for
now
one,
but
maybe
two
machines
always
available
for
anybody
to
gain
access
to
a
little
bit
more
detail
coming
on
that.
A
Okay,
anything
else,
any
other
status
updates
by
anybody.
B
I
can
throw
mine
in.
I
was
working
on
the
cache
image
bug
for
windows,
cache
images,
most
of
the
works
in
life
cycle
and
image
util,
but
it
should
fix
the
upstream
pack
issue.
It's
gonna
require
a
couple
changes
and
I'll
keep
it
short,
but
it's
gonna
introduce
os
awareness
into
the
constructors
for
image
util,
so
be
able
to
pass
in
the
kind
of
image
that
you
want
to
make
from
the
start.
A
A
Okey
dokey
moving
on
to
release
planning,
I
think
we've
still
got
a
long
ways
to
go
with
pac
release
the
one
for
techton
is
coming
up.
I
believe.
Oh
I
forgot
february
is
a
short
week
or
sorry
short
month.
A
It
will
be
this
week.
It
looks
like
so.
This
is
the
first
time
that
we'll
be
kind
of
doing
a
cadence
for
the
tecton
integration
repo.
A
So
I'm
not
entirely
sure
exactly
what
that
looks
like
I'll
kind
of
be
working
ad
hoc,
but
so
far
we
do
have
updates
to
the
two
tasks
that
we
have
for
techton
and
the
new
pipeline,
which
I'll
again
discuss
as
part
of
the
agenda
items.
A
Okay,
anything
else,
release
planning.
A
Okay,
let's
see.
A
A
A
A
Rfcs
again,
I
I
believe
the
purpose
of
having
rfcs
here
is,
to
you
know
a
make
people
aware
of
any
new
upcoming
changes
to
platforms
and
be
to
see
if
we
want
to
dive
into
any
of
these
specific
changes.
If
anybody
has
questions
about
them,
so
the
first
one
we
have
is
adding
builder
key
and
project
descriptor
right.
I
think
this
is
from
the
title
pretty
self-explanatory.
A
We're
adding
just
a
builder
key,
I
believe,
here's
the
sample
yeah,
so
there's
a
builder
with
a
string.
This
would
be
the
same
thing
that
we
would
provide
via
pack,
but
now
it's
in
a
way
that
it's
specified
at
the
project
level
and
maintained
in
the
source
repository
so
that
it's
portable,
the
other
one
group
additions
to
the
build
order.
I
believe
that
the
description
of
the
title
isn't
all
too
clear,
but
I
believe
this
is
a
pre
and
post
build
packs
yeah.
A
Next,
one
stockify
repo,
I'm
not
entirely
sure
how
this
applies
to
platforms
specifically
other
than
I
know
that.
There's
some
intention
that
pac
will
provide
this
functionality.
A
I'm
not
sure
yeah
here
so
packs
that
create
you'd
be
able
to
kind
of
pass
in
the
image
that
you
want.
The
run
images
a
couple
of
flags
that
are
detailed
here
and
it
should
add,
metadata,
mix-ins
and
and
so
forth,
information
to
the
image
so
basically
taking
any
base
image
and
creating
a
stack
from
it.
A
A
Away
all
right
back
to
our
agenda
standardizing
cash
flags.
Anybody
want
to
take
that
on.
C
Yeah
sure
so
I
think
this
is
probably
something
that's
come
up.
A
couple
times
is
that
we
keep
getting
requests
for
different
options
for
people
to
manage
the
build
cache
when
they're
running
a
pack
build
whether
that's
making
a
remote
image
that
they
can
then
save
between,
runs
or
specifying,
where
the
cache
is
coming
specifically
and
the
image
that
it's
going
to
locally.
C
There
is
like
some
small
changes
that
will
be
made.
Did
tim,
I
think
let
the
creator
have
some
of
this
functionality,
specifically
when
you
have
differences
between
whether
you
want
to
import
a
image
like
a
cache
image
and
export
a
local
volume,
or
vice
versa,
but
that's
just
kind
of
like
something
that
would
be
possible
already
with
just
running
the
binaries
independently.
Just
don't
really
have
it
on
the
creator
yet.
A
Recording
the
issue
has
a
really
good
proposed
solution,
or
at
least
it
it
definitely
solidifies
it.
In
my
mind,.
A
A
So
I
guess
at
first
right,
like
I,
when
this
was
first
brought
up,
it
was
like
we
have
cash
image
and
cash
volume,
and
that
was
like
the
idea
that
this
is
where
your
stuff's
gonna
be
persisted,
and
it's
either
gonna
be
in
one
of
these
two
formats
right
and
reading
through
the
proposed
solution
as
well
as
I
think
some
of
the
comments
below
it
seems
like
we're
talking
about,
like
I
think,
migrating
caches
is
the
right
term
to
use
here
right.
A
C
Yeah
100,
and
I
think
that
the
like
the
fact
that
we
can't
do
that
is
just
a
constraint
kind
of
imposed
by
pack
and
not
really
imposed
by
the
underlying
life
cycle
binaries.
So
it
feels
like
something
that
shouldn't
be
too
difficult
to
do
right
and
if
it's
already
possible
with
the
underlying
lifecycle,
binaries
should
probably
do
it.
We'll
make
this
simpler.
A
A
It's
not
volumes
mounts
right
like
the
docker
mount
syntax
and
that's
like
pretty
complex,
so
so
yeah.
I
guess
basically,
I'm
kind
of
like
asking
is
the
demand
worth
the
added
complexity.
C
Good
question:
that's
like
super
hard
to
answer.
I
guess
right.
C
C
A
Yeah
so
so
they're
trying
to
store
the
cash
as
a
volume
right
or
sorry
they're
trying
to
be
able
to
name
the
the
cached
volumes
so
that
they
could
potentially
share
them
across
to
different
apps.
At
least
that's
one
of
the
use
cases
that
I've
definitely
heard
before
right.
A
C
B
A
Need
some
additional
buy-in
to
be
able
to
provide
the
same
functionality
to
the
creator,
yeah
it
would
yeah
and
given
that,
in
most
cases
at
least
you
know,
this
is
maybe
just
me
making
an
assumption,
but
most
people
would
use
the
suggested
builders
and
thereby
use
trusted
builders
which
thereby
would
use
the
creator
and
like
if
we
really
think
that
this
again
was
like
a
demand
or
there
was
a
demand
for
this.
A
Then
we'd
want
to
also
add
it
to
the
creator,
and
so
I'm
thinking
about,
like
the
domino
effect
right
of
all
the
effort
versus
the
demand
and,
like
I
said,
like
I
haven't,
heard
this,
I
don't
know
if
you
could
point
to
any
specific
request
to
have
a
migrating
cache
versus
just
is
it?
Is
that
really
the
reason
why
we're
doing
it
or
is
it
that
we're
just
trying
to
collapse
the
the
idea
of
having
you
know,
cache
image
versus
cache
volume,
flags.
C
Yeah,
I
think
that
the
start,
the
reason
why
I
wrote
this
was
definitely
simplify
the
user
experience
when
using
all
these
options
like
and
the
interactions
between
them
right,
like
you,
can't,
publish
and
specify
your
the
name
of
a
volume
that
you're
gonna
use
right
like
there's
just
like
a
lot.
There's
gonna
be
a
lot
of
interaction
between
these
things.
Right.
C
Yeah,
I
was
just
curious
what
so,
what's
the
the
migrating
use
case?
May
I
miss
that
part
of
the
discussion,
so
you
want
to
have
an
input
cache,
but
then
you
want
it
to.
You
want
to
write
to
a
different
cache
on
output,
yeah
and
so
it'd,
be
a
difference
in
type,
so
you'd
be
able
to
read
from
a
cache
image
and
write
to
a
cache
volume
or
switch
those
two.
That's
I
mean
that's
one
of
the
things
this
would
let
you
do.
A
Cash,
so,
ultimately,
like
hypothetically
right
like
if
we
wanted,
if
someone
was
really
saying
like
hey,
I
want
to
be
able
to
migrate
cash
right
like
would
we
instead
then
have
like
a
pack
cash
migrate
command
right?
That
then
takes
an
input
and
an
output
versus
having
to
do
the
build
process
for
it.
C
Is
it
a
migrate
or
a
copy
like
if
I
specify
this
source,
is
it
then
copied
to
this
destination,
and
then
the
bill
gets
run
on
top
of
it.
C
Sorry
so
was
that
a
proposal,
or
was
this
like
following
up
on
javier's
proposal
of
having
a
specific
command
to
do
this
or
when
you
run
pac?
This
would
be
the
behavior
sorry.
I
missed
that.
C
A
A
It's
interesting
so
again,
I
guess.
Maybe
I
want
to
determine
the
demand
for
for
the
migrating
use
case,
but
if
we
were
to
think
of
simplifying
the
fact
that
we
have
two
flags
and
potentially
making
them
one
flag,
I
think
that
sounds
more
reasonable
or
I
guess
maybe
more
actionable
right,
because
then
that
the
scope
is
a
lot
lower,
I
would
think
right
and
then
it
doesn't
require
for
us
to
hopefully
have
to
like
also
change
the
creator
right
or
maybe
the
change
there
would
be
also
minimal.
C
A
Yeah,
because
I
could
definitely
think
of
flags
that
we've
condensed
right,
like
I'm
thinking
of
pull
policy,
we
definitely
condensed
that
and
we
definitely
allowed
for
some
room
where
we
could
add
complex,
pulling
logic
which
we
haven't
implemented
again,
because
the
desire
hasn't
been
quite
there
yet
right,
but
I
feel
like.
Maybe
we
could
do
something
similar
here,
where
we
could
simplify
it
to
a
single
flag
right
and
then
determine
exactly
like
what
the
format
for
that
should
be
and
make
sure
that
it
doesn't
lock
us
in
into
anything.
A
A
A
All
right,
I
guess
I'll
present
the
other
one.
Well,
we
have
five
minutes.
Yeah
we're,
definitely
not
going
to
get
through.
All
of
these.
A
Yeah,
what
about
pack
package
refactoring.
C
It's
pretty
small,
I
think
just
take
a
look
at
it.
Don't
have
to.
A
Okay
over
right
now
sounds
good
I'll,
go
through
the
techdown
thing,
real,
quick,
and
if
we
have
maybe
a
few
minutes,
we
could
also
glance
at
that
one
all
right.
So
this
is
a
pull
request
on
the
tech
dyn
integration
repo.
So
I
realized
that
this
is
like
a
relatively
new
repo
as
far
as
being
worked
on.
A
The
purpose
of
this
repo
is
to
provide
a
lot
of
tooling
and
automation,
automation
and
testing
around
some
of
our
tasks,
and
one
of
the
things
that
kind
of
came
up
in
one
of
our
discussions
was
the
fact
that
we
have
two
tasks
and
it
it's
very
difficult
for
the
user
to
really
understand
which
task
they
should
be
using
right
like
they
want
to.
You
know,
do
they
use
this,
build
packs
task
and
we
kind
of
explain
what
it
really
is
here
right
to
some
extent
or
do
they
use
this
like?
A
Well,
I
guess
that
link
doesn't
work
or
do
they
use
the
build
pack
phases
right
and
again,
it
kind
of
tries
to
explain
a
little
bit
as
to
why
you
might
want
to
use
this,
but
in
general,
like
it's
still,
not
very
user
friendly
right,
at
least
compared
to
pac,
where
it's
an
underlying
implementation
detail,
whether
it
uses
individual
phases
or
if
it
uses
the
creator.
A
So
in
trying
to
replicate
that
one
of
the
limitations
with
tecton
right
now
is
that
in
these
tasks
there
are
steps,
but
these
steps
cannot
be
conditional
right.
So
like
there's
no
way
to
conditionally
execute
these
steps.
The
conditions
lie
at
a
higher
level,
which
is
what's
called
a
pipeline
right,
so
you
could
conditionally
execute
certain
tasks
within
this
pipeline.
A
It
determines
whether
one
of
two
tasks
will
run
or
set
up
tasks,
which
is
the
build
untrusted
right.
We
have
this
condition
here
or
the
build
trusted,
which
I
guess
I
skipped
over
here-
build
trusted
which
then
executes
the
build
packs
task
versus
the
build
pack
phases
right.
So
very
simple,
I
guess
indirection
for
this
pipeline,
but
other
things
that
I
think
this
pipeline
will
allow
us
to
do
is
add
more
functionality
that
has
been
requested
in
regards
to
like
environment
variables.
A
One
of
the
things
I
want
to
do
is
like
determine
the
user
id
and
group
id
by
inspecting
the
image,
as
opposed
to
requiring
the
user
to
be
able
to
set
this.
So
I
think,
long
term.
What
I
want
is
the
pipeline
to
be
like
the
simplest
use
case
and
then
the
tasks
to
be
kind
of
like
implementation,
details,
that's
more
or
less
the
strategy
or
goal
here.
A
Cool,
so
the
only
other
thing
I
I
will
ask
is:
if
anybody
has
some
free
time
to
review
this
pr
make
sure
I'm
not
missing
you
know
anything
big
or
or
whatnot,
but
otherwise
again
the
intent
is
to
release
it.
This
week.
A
Thank
you,
oh
and
we
ended
right
up
time,
so
we
have,
I
guess,
two
other
things
as
mentioned
pack
package
refactoring,
if
you
mind
looking
at
that
rfc,
I
think
that'd
be
nice,
but
other
than
that
we
could
review
it
at
more
depth
next
time
around
cool.
Thank
you
all
see
you
later.