►
From YouTube: Platform Sync: 2021-03-10
Description
Meeting notes: https://bit.ly/38pal2Z
A
Great
okay,
so
moving
on
to
status
updates,
I
guess
I
can
share
something
that
I've
been
kind
of
looking
into
a
little
bit
recently,
which
is
in
regards
to
our
ci
pipeline
or
workers.
We
had
some
issues
that
kind
of
required
us
to
go
ahead
and
update
the
the
runners
themselves,
and
in
doing
so
we
got
the
latest
version
of
docker
desktop,
which
kind
of
brought
on
a
slew
of
issues
that
I've
posted
in
the
ci
slack
channel.
A
I've
since
then
just
pinned
to
an
older
version
of
docker
desktop,
and
I
haven't
gotten
the
time
to
go
back
and
really
dig
into
exactly
what
all
the
issues
are
and
how
to
like
really
remedy
them.
Since
it
seems
like
it's
going
to
impact
a
number
of
contributors,
at
least
since
our
tests
are
failing
due
to
some
changes
in,
I
believe
networking
for
the
most
part.
A
I
don't,
I
believe
dan
might
be
taking
on
some
of
that
to
look
into
but
I'll.
Let
him
speak
to
that
other
than
that
still
poking
at
tecton
catalog,
for
them
to
be
able
to
to
essentially
merge
in
our
our
tasks
and
pipeline.
A
I'm
not
entirely
sure,
what's
going
on
there,
so
I'll
continue
to
poke.
Alternatively,
I
did
discover
that
the
hub,
which
is
like
a
ui
similar
to
the
build
pack
registry,
what
they'll?
Let
you
search
for
stuff,
it's
going
to
allow
for
different
catalogs,
so
I
think
we
could
kind
of
branch
off
and
instead
of
using
and
relying
on
the
central
tecton
catalog,
we
could
kind
of
host
our
own
similar
to
how
we
do
for
homebrew,
and
hopefully
this
will
enable
us
to
do
releases
in
a
more
you
know,
timely
fashion.
A
I
still
eyeing
that
I
posted
the
proposal
as
an
issue
in
the
tecton
integration
repo,
but
I'll
probably
be
creating
an
rfc
once
that
really
becomes
something.
That's
a
capability
all
right,
sorry,
that
was
all
of
mine.
Anybody
else
want
to
give
a
status
update.
B
Slightly
related
I
was,
or
to
your
ci
adventures,
I
was
trying
to
reproduce
those
issues
on
various
different
versions
of
docker
desktop
for
windows.
Nothing
too
interesting,
yet
I'm
still
on
old
versions.
That
seem
to
be
passing
so
I'm
about
to
bump
it
up
to
the
newer
version.
So
I'll.
Let
you
know
what
I
find
and
also
separately
working
on
the
image.
B
Util
related
changes
to
fix
the
cache
image
bug
where
cache
images
are
created
for
linux,
when
you
want
them
to
be
windows,
and
it's
all
there's
various
pr's
out
that
are
getting
reviewed,
but
I
think
most
that
the
code
is
complete
there.
B
The
only
relevant
that
is,
there
might
be
some
registry
changes
that
are
there
that
could
that
are
based
on
what
pac
currently
has,
but
potentially
a
little
bit
simplified
could
be
some
workarounds
for
the
ci
issue
if,
if
push
comes
to
shove,
but
since
I
have
contacts
done
on
that
part
of
it
I'll
I'll
keep
looking
on
it.
A
Cool,
and
that
is
in
the
image,
detail,
repo
or
library-
is
that
right.
B
It
is
yep
and
it's
currently
a
pr
I'll,
throw
a
link
to
it
in
the
notes
here.
A
Cool
yeah,
if
you
could
get
that
working
with
you
know
the
latest
version
of
docker
desktop.
That
would
be
interesting
because
then,
hopefully,
we'll
just
be
able
to
consume
that
and
get
rid
of
our
implementation
in
pack.
B
Yeah,
I'm
not
super
hopeful
that
it
will
behave
all
that
much
differently,
but
it
would
potentially
let
us
not
use
net
host
for
everything
makes
it
easier
to
use
net
nat,
so
it
might
eliminate
one
problem
instead
bring
up
another
but
we'll
see
I'll,
try
it
out,
but
I'll
send
the
link
over
here
cool.
Sorry,
that's
my.
C
Update
yeah,
so
I
guess
this
week
most
of
what
I've
been
working
on
is
kind
of
some
issues
that
come
up
because
of
differences
in
our
tcp
configuration
and
the
life
cycle
and
that
on
docker
hub.
But
I
would
imagine
that
this,
like
some
of
these
changes,
will
be
pretty
relevant
for
any
time.
We're
fetching
build
packs
as
well,
just
since
yeah
we're,
basically
just
using
a
lot
of
the
default
golang
stuff
and
doc.
Hub
doesn't
like
that
when
you
start
doing
a
lot
of
things
in
parallel,
so.
A
Okay,
next
release
planning,
as
I
may
mention,
techton
still
kind
of
stuck
in
the
review
process.
I
do
maybe
want
to
touch
on
pac.
I
know
it's
scheduled
for
next
week.
Is
that
accurate,
should
we
start
ccb
feature
complete
today
or
tomorrow?
I
don't
know.
A
I
haven't
spoken
to
david
here
recently,
but
that's
probably
something
we
want
to
discuss.
I
don't
know
if
david,
if
you
have
any
input
into
that
or
dan.
A
So
you
know
if
no,
if
people
aren't
aware
david,
is
in
the
middle
of
a
transition
right
now,
employment
wise.
So
that's
partly
the
reason
why
he's
probably
a
little
bit
absent
right
now,
so
I'm
gonna
try
to
either
communicate
with
him
or,
if
not
just
step
in
for
this
release
and
make
sure
that
we
clean
up
the
milestone
to
make
sure
that
we
have
the
things
that
we
want
to
have
in
this
release.
A
I
know
that
there's
a
very
particular
issue
that
emily
and
jesse
are
running
into
right
now
in
regards
to
creating
builders
and
essentially
duplicate
layers
for
build
packs
and
some
of
those
not
necessarily
matching
as
far
as
their
digest
goes,
so
digging
into
that.
I
think
that
might
be
of
high
urgency
to
try
to
get
into
this
release
so
continue
to
look
at
that,
but
yeah
I'll,
probably
just
take
on
the
release,
like
I
said
so
more
to
come.
There
I'll
keep
talking
about
it
in
the
platform
channel.
D
D
Concerns
it
might
be
worth
noting
that
we're
planning
to
ship
the
life
cycle,
you
know
soon
right,
it's
a
it's
feature
based,
but
I
think
all
of
the
issues
that
we
need
to
get
into
the
next
release
are
currently
in
flight.
D
A
So
in
its
current
state
I
know
we
have
an
issue
in
pack
that
should
essentially
look
at
the
latest
supported
api
version
right
and
b,
and
I
think
that
should
be
true
like
going
forward,
no
matter
what
for
the
life
cycle,
so
that
should
simplify
it,
but
because
we
don't
have
that
change
right
now,
I'm
somewhat
hesitant,
because
if
there
is
an
issue
with
the
life
cycle
soon
thereafter
that
requires
a
patch.
It
would
require
pac
to
also
ship
a
patch.
A
So
I'd
rather
have
some
sort
of
intermediate
time
in
which
you
know,
people
could
obviously
still
use
the
newest
version
of
the
life
cycle,
but
it
would
be
more
explicit
right
and
then
once
everything
gets
ironed
out,
then
we
should
bump
it
on
pack
for
the
next
version.
I
think
that's
been
our
working
model
and
I
think
it's
worked
pretty
well
so
far.
A
You
are
able
to
see
the
issues
board
right,
cool
all
right,
so
the
first
one
we
have
is
pack
build
pack
packages
should
not
require
the
package
tamil
in
all
circumstances.
A
I
believe
I
added
this
to
the
agenda
yeah
here,
because
there's
apr
from
sam,
who
is
with
us
today
that
kind
of
tries
addresses
this
for
the
most
part,
but
there
are
some
discussions
about
some
options
that
we
want
to
consider
there.
A
D
A
All
right,
I
guess
maybe
we
could
finish
up
this
one,
so
the
ggcr
debug
logging.
I
think
I
made
a
request
dan.
I
believe
you
have
some
more
contacts
here.
If
you
could
provide
that
that'd
be
great,
so
store
image
in
local
docker
daemon
when
using
pack
build,
publish
I've
read
through
this,
but
honestly,
I'm
not
sure.
I
I
really
gather
exactly
what
we're
gonna
do,
especially
as
we're
making
changes
already
to
like
cache
volume,
cache
image
and
so
on.
A
C
Yeah,
so
I
think
you
keep
like
the
basics
are
that
this
person
wants
to
be
able
to
push
a
cash
image
right
but
keep
his
the
bill
artifact
locally,
and
because
we
have
like
one
published
flag.
It
seems
that
like
manages
how
permissions
get
funneled
into
the
life
cycle,
and
then
we
use
the
creator,
it
feels
like
any
split
between
having
everything
go
to
the
registry
or
everything
stay.
Local
is
like
a
little
bit
awkward.
I
guess
doable.
A
A
I
want
to
like
really
grasp
exactly
what
the
proposal
is
right,
like
what
a
possible
solution
or
set
of
possible
solutions
could
be
and
make
sure
that
the
ux
aligns
with
what
the
default
expectation
would
be
and
then
also
enable
all
the
knobs
in
a
sensible
way
to
be
able
to
configure
exactly
how
I
guess
this
individual
desires
and
then
the
last
but
not
least,
is
make
sure
that
there's
enough
of
a
desire
right
to
warrant,
maybe
the
complexity.
C
Yeah
yeah,
okay,
I
mean
I'll
see
if
this
person
wants
to
like
collaborate
or
drive
that
out.
If
they
don't
it's
probably
a
piece
of
work,
I
can
pick
up.
A
C
A
Cool
so
let's
see,
I
guess,
do.
D
Well,
I
just
had
a
comment.
I
don't
know
if
this
is
all
that
relevant,
but
I
remember
one
of
the
options
was
like
pushing
to
a
local
registry
so
like
still
publishing
but
publishing
to
you
know
still
on
your
workstation,
and
I
remember
that
we
talked
about
some
kind
of
workflow
for
pac
that
made
use
of
a
like
either
a
temporary
local
registry,
or
something
like
that.
So
I
don't
know
if
that's
necessary
to
explore
in
this
issue,
but
it's
something
that
could
come
up.
A
Yeah,
I
I
know
exactly
what
you're
talking
about
but
yeah,
I
think
they're
slightly,
you
know,
separated
or
separated
enough
that
the
use
case-
I
guess
maybe
I
don't
see
it
as
tied
to
it,
but
it
could
be
to
your
point
right,
so
I
just
added
the
label
to
it
and
then
I'm
gonna
go
ahead
after
this
meeting.
Add
some
comments
on
here
as
to
why
we
would
want
this
to
be
an
rfc.
Based
on
the
comments
I
made
earlier.
D
Are
we
leaving,
I
guess,
an
invitation
for
the
person
who
opened
this
issue
to
drive
that
rfc
or
we
what
I
forgot
where
we
landed
there.
A
Yeah,
so
my
stance
is,
we
would
need
an
rfc
and
I
would
put
exactly
what
the
why
you
know
why
we
would
need
an
rfc
right
like
the
things
that
we
would
be
looking
for
in
an
rfc
the
you
know
how
to
proceed.
I
think
that's
really
up
to
the
author
or
anybody,
therefore
interested
in
facilitating.
D
A
A
C
D
I'm
plus
one,
but
I
don't
have
a
conflict.
A
Yeah
so
yeah,
I
definitely
think
of
it
as
going
forward
and
I'll
just
increase
the
time
wherever
we
need
to
and
ultimately,
if
we
finish
early,
obviously
we'll
drop
off
as
well
cool,
let's
see
since
we
do
have
sam.
Does
anybody
mind
if
we
bump
this
one
up
in
the
agenda.
D
A
All
right,
so
I
guess
maybe
to
give
a
little
bit
of
context
on
this,
so
this
is
in
relation
to
the
pack
build
package
command
right
and
previously
it
required
you
to
have
a
config
parameter
where
you
would
point
it
to
a
package.tamo
file.
A
A
E
Yeah
it
it
tries
to
provide
like
a
dummy,
minimal,
package.normal
file,
so
it
essentially
creates
one
with
uri
set
to
the
current
directory,
but
that
that's
the
that
was
the
implementation
that
that
was
there.
In
the
previous
video.
D
A
File
and
now
the
proposed
change
from
emily
was
to
have
an
additional
flag
called
build
pack
right,
and
then
this
build
pack
flag
would
allow
you
to
instead
of
specifying
a
package
automo
file
to
point
to
a
directory.
A
A
The
part
where
I
kind
of
had
some
questions
about
was
it
overriding
the
build
pack
uri
if
you
provided
both
the
config
and
the
build
pack
flag?
And
additionally,
I
wasn't
a
huge
fan
of
the
build
pack
name,
because
I
felt
like
when
you
attach
it
to
a
build
pack.
It
just
the
context
or
the
syntax
doesn't
make
sense
when
you
think
about
like
pack
build
when
you
specify
multiple
build
packs
and
that
sort
of
stuff
right.
A
So
we
talked
about
a
little
bit
more
and
I
think,
where
we're
kind
of
hung
up
right
now
is
in
two
options:
right
where
we
have
option.
One,
which
is
a
path
for
all,
so
we
have
a
single
parameter,
that's
called
path
and
it
could
take
a
build
pack
directory
a
package
time
tamil
formatted
file
or
a
build
pack
file.
I
think
someone
ryan
requested
that
it
also
take
a
tarball
right,
so
you
could
point
it
to
a
url
or
a
tarball.
A
That's
already
been
a
pre-packaged
build
pack
and
it
would
just
work
for
option
two
is
we
would
have
still
a
config
for
a
project
tamil
file
and
then
a
path
to
a
build
pack
directory
right,
and
I
would
assume
in
this
case
the
it
would
also
could
be
a
tarball
of
a
build
pack
for
this
path.
Now.
A
I
hope
I
did
this.
You
know
explanation
some
some
good,
but
I
don't
know
sam.
If
you
have
more
to
add
here.
E
Makes
sense
the
the
only
question
I
had
was
like,
which
of
these
files
are
like
actually
in
the
spec,
which
are
unofficially
assumed
to
be
in
the
spec
or
they're
planned
to
be
in
a
future
extension
spec
and
then,
which
of
these
are
just
like
conventions
for
back,
because
for
me
that
was
the
confusing
part
when
implementing
this
pr,
like
does
that
package
terminal
file
have
to
be
called
package
normal
or
can
it
be
anything?
E
A
My
understanding
historically,
is
that,
because
it's
a
configuration
solely
for
a
pack
operation
right,
which
is
the
packaging.
It
is
therefore
a
pack
specific
configuration
file
and
therefore
outside
of
the
spec.
A
The
only
thing
that
we've
specced
out
in
regards
to
packaging
is
the
format
for
which
we
create
the
package
right,
and
so
that
should
be
in
the
distribution
spec
similar.
I
guess
another
similar
file
would
be
the
builder
table
file,
which
is
a
configuration
for
pack
on
how
to
create
the
builder.
But
the
builder
spec
talks
mostly
about
how
the
builder
is
structured
and
not
the
configuration
for
an
operation
that
creates
the
builder.
If
that
makes
sense,.
E
So,
if,
if
it
is
just
pack
specific
like
do
like,
does
it
make
sense
to
have
it
named
something
else,
and
if
it
is
named
something
else,
how
would
we
detect
it?
E
A
And
we're
talking
about
this
section
here
is
that
right,
so.
E
I
was
talking
about
option
one
where
it's
a
single
path
for
everything
like
let's
say
if
it's
an
improperly
formatted
file,
for
whatever
reason:
how
do
we
differentiate
between
an
improperly
formatted
buildpack.normal
file
or
a
properly
formatted
package.tomol
file,
because.
D
E
A
Yeah,
I
could
definitely
see
that.
Does
the
build
pack
tumble
does
that
require
the
api
field
at
the
top
level.
E
D
E
A
E
A
I
don't
know
the
extent
of
the
validation
at
the
different
layers
right.
I
know
that
there's
been
discussions.
A
Like
especially
right
now
talking
about
the
life
cycle
right
and
the
life
cycle,
having
additional
validation
for
certain
configuration
files
and
whether
extra
keys
should
be
allowed
or
not,
and
I
think
the
majority
are
leaning
towards
being
a
little
bit
more
strict
in.
D
A
E
If
it,
if
it
errors,
then
it's
a
different
case
entirely,
but
that
that
was
my
only
like
confusion
with
option.
One
like
how
do
you
differentiate
between
all
of
the
different
like
the
two
different
drama
files.
A
Yeah,
I
wonder
so
that
that's
the
discussion
and
complexity
for
option,
one
right:
what
about
option?
Two,
basically
having
a
the
dash
dash
config,
tell
you
that
it's
a
package,
tommle
configuration
and
the
dash
dash
path,
simply
replacing.
What
is
you
know
named
build
packs
in
this
pr
that.
E
E
I
I
think,
if
we,
if
you
want
to
avoid
that
behavior
where
the
uri
is
being
overridden,
then
I
think
it
makes
sense
to
have
those
to
be
mutually
exclusive,
because
I
I
couldn't
think
of
a
use
case
either
the
reason
I
implemented
it
was
because
it
was
mentioned
in
the
original
issue,
but
right
I.
I
think
it
would
make
sense
if
like.
If
you
have
both
paths
and
a
config,
it
doesn't
make
sense,
because
your
package.normal
should
contain
a
relative
path
to
your
buildback
anyway,
yeah
or.
A
A
A
Cool
and
then
to
ryan's
comment
I
could
reply
or
I
don't
know
if
you
don't
mind
replying
that's
pr,
that's
a
really
good
idea,
but
I
would
probably
defer
that
into
a
separate
issue.
E
D
A
All
right,
so
it
does
seem
like
we're
at
time
for
today
do
we
want
to
continue
going
and
is
there
anything
that
we
would?
You
know
we
should
be
talking
about.
C
C
A
Yeah,
I'm
okay
with
doing
it
right
now.
I
don't
have.
D
C
Okay,
all
right!
Well,
I
don't
think
this
will
take
too
long,
but
so
this
is
kind
of
a
continuation.
I
guess
some
background.
C
C
Directory
and
then
a
bunch
of
packages
inside
of
it
that
are
all
exported
and
external
consumers
can
use
them
and
the
first
go
through
of
this
rfc.
A
lot
of
what
we
were
getting
stuck
on
is
exactly
like
what
the
names
are.
What
belongs
in
here?
What
are
the
possible
other
commands
that
we
are
going
to
have?
Do
we
really
want
those,
and
so
the
last
platform?
C
Sync,
I
think
we
came
up
with
javier
proposed
a
kind
of
good
idea,
which
was
that
we
probably
are
more
worried
about
the
process
about
how
we
want
to
pull
stuff
out
and
just
like
more
generic.
Oh,
we
we
do
want
to
have
some
bits
of
functionality
to
get
pulled
out
into
packages
and
then
eventually,
if
they
need
to
be
pulled
out
into
their
own.
D
C
So
I
guess
this
is
just
like
how
this
should
look
eventually,
where
a
bunch
of
unorganized
stuff
right
now
extract
code
from
internal,
and
here
we
don't
really
want
to
define
exactly
what
this
looks
like
all
the
way
we
can
pull
some
stuff
out
into
individual
commands,
and
eventually
we
have
some
packages,
like
I
believe
archive
that
are
probably
going
to
be
pulled
out
into
their
own
individual
repository,
because
they're
used
a
across
different
rebounds
that
we
have.
C
So
I
guess
with
that
said
this
is
kind
of
like
a
first
mod
like
goal
or
like
the
first
goal
post
that
we'd
want
to
potentially
try
and
get
to,
and
it's
okay,
if
we're
going
through
this
kind
of
like
refactoring
process
and
decide
these
aren't
quite
the
right
seams
that
we
want
to
pull
out.
That's
fine!
I
don't
want
to
have
to
submit
another
rfc.
If
that
is
the
case,
and
then
this
would
be
a
potential
future.
Where
we
pulled
more
stuff
out,
we
have
some
additional
clies,
et
cetera.
A
Cool
I
like
it
a
lot
yeah.
This
totally
makes
sense.
I
wonder,
like
very
you,
know
small
nitpick
here,
but
I
wonder
if
we
can
make
it
more
obvious
that
you
know
this
is
like
the
current
structure.
I
guess
maybe
that's
my
first
question:
do
we
already
have
a
pkg
on
the
current
structure.
D
A
A
What
okay,
it's
interesting
see
it's
things
like
that.
We
didn't
even
know
happen
all
right,
okay,
so
that
is
the
current
structure,
then
second
and
third
cool,
so
maybe
like
labeling
phases
or
making
a
more
like
specific
name,
naming
strategy
right
like
current
structure
after
this
rfc-
and
you
know
long
term
or
something
like
that
right.
Something
that
tells
people
like
hey
don't
make
sure
that
you're
thinking
about
it
in
the
right
context.
For
each
one
of
these.
D
A
Cool
all
right,
so
it
seems
like
I've
got
a
few
action
items.
I'll
definitely
extend
this
meeting
to
an
hour
starting
next
week,
which
I
won't
be
here.
Yeah
I'll
be
out
on
vacation,
but
I'm
sure
someone
will
take
care
of
it
and
yeah
start
doing
that
and
yeah
hopefully
I'll
see
you
all
online.