►
From YouTube: Platform Sync: 2021-03-31
Description
Meeting notes: https://bit.ly/38pal2Z
A
A
I
believe
so,
there's
probably
something
that
we'll
need
to
discuss
there.
I
plan
on
bringing
it
up
tomorrow
in
the
implementation,
subteamsync
and
maybe
kind
of
go
through
some
options
to
try
to
see
what's
best
there
outside
of
that
from
a
platform's
perspective.
I
also
looked
at
the,
I
guess,
the
interface
for
how
you
would
configure
or
execute
this
from
the
docker
cli
perspective.
A
I
think
the
proposal
that
I
have
is
to
try
to
leverage
the
project,
tamil
file
and
format
and
simply
add
some
essentially
like
a
header
comment
to
let
the
docker
build
kit
know
what
I
guess.
What
front
end
to
use
right
and
in
our
case
the
the
build
packs
front
end,
so
it's
very
much
a
proposal,
probably
something
worth
exploring
a
little
bit
more
in
detail.
A
I
know
we
have
to
gather
a
lot
of
built-in
build
kit
context
within
the
project
as
a
whole,
so
I
am
hoping
that
you
know
through
some
of
this
exploration
I
we
could
get.
You
know
basically,
a
meeting
set
up
so
that
we
could
kind
of
discuss,
build
kits
specifically
as
a
whole
across
multiple
sub
teams,
so
probably
going
to
pump
that
over
to
in
office
hours,
but
still
very
much
in
the
works.
B
Yeah,
I
guess
I've
just
been
continuing
to
try
and
get
asset
packages
to
a
place
where
it
can
all
be
merged
in,
and
I
think
that's
actually
getting
pretty
close
and
I'm
hopeful
all
of
the
like
functional
code
will
be
done
by
the
end
of
this
week
and
that
I
can
spend
some
time
making
sure
that
it
like
gets
refactored
and
it's
code
that
people
actually
want
to
work
with.
So
there's
quite
a
bit
of
repetition
between
what
I'm
doing
and
some
of
the
stuff
in
build
packages
with
like
small
differences.
C
A
B
B
C
A
B
B
A
A
So
for
one,
for
instance,
like
the
migration
guide
right.
That
would
take
into
consideration
like
letting
everybody
know
like
hey.
This
is
the
platform
api
change,
maybe
even
a
blog
post
right
as
a
proposal
for
something
that
the
implementation
writes
as
to
why
we're
changing
the
phases
might
be
nice
to
have.
A
A
C
Like,
on
the
one
hand,
the
phases
and
their
order
of
executions
kind
of
hidden
from
the
pac
user,
but
at
the
same
time,
by
flipping
the
order
we
are
enabling
some
extra
functionality
that
may
be
good
to
call
out.
So
I
don't
know
if
that
that
should
be
connected
to
this
issue
or
it's
more
from
a
documentation
perspective
like
you
might
see.
You
know
failures.
A
Yeah,
I
see
yeah,
but
I
I
don't
know.
I
guess
I'm
still
of
the
opinion
that
this
issue
for
the
execution
order
is,
is
very
simplistic
and
well
encapsulated
right
and
I
think
the
greater
scope
of
what
it
enables
like
what
other
feature
sets.
We
have.
You
know
if,
if
you're
thinking
from
a
life
cycle's
perspective,
what
the
migration
of
that
looks
like
those
are
all
very
separate
to
this
particular
issue.
B
A
A
B
A
B
A
A
Right
so
I'm
trying
I'm
missing
the
association
or
disassociation
presented
where
x86
or
386
is
no
longer
being
supported.
I'm
questioning
who
is
no
longer
supporting
it.
Is
it
this
intermediary
individual
that
has
the
unofficial
debian
package?
Where
is
it
go
themselves
right?
If
it's
just
this
individual,
this
intermediary,
then,
can
we
get
rid
of
the
intermediary
and
go
with
a
more
direct
solution.
B
B
From
what
I
understand
about
how
ubuntu
distributes
packages,
the
problem
is
not
that
there
is
go
lang
that
can
be
compiled
on
this
architecture
problem
is
that
they
force
you
to
they
won't
let
you
just
like
download
arbitrary
binaries
during
their
build
process
right.
Their
idea
of
how
things
should
work
is,
like
you
have
a
package
that
has
a
dependency,
that's
declared
in
like
our
format
right,
so
it's
a
dependency
on
another
ppa
and
you
can't
have
binary
ppa.
B
It's
like.
I
would
love
to
just
be
able
to
take
a
lang,
throw
it
in
one
of
these
archives
and
say
thumbs
up.
This
definitely
works.
I
already
know
it,
but
they
force
you
to
build
stuff
from
source
right,
and
so
the
problem
is
that
this
other
person
is
struggling
to
build,
go
from
source
on
the
build
machines
that
ubuntu
provides
for
ppas
right.
A
B
A
I'd
really
hate
to
just
drop
support,
like
I
said,
based
on
an
intermediary
and
I'd
like
to
research.
What
others
are
doing
like.
I
said
it
because
it
does
seem
like
a
big
ecosystem
problem,
and
so
I
I
find
it
difficult
to
imagine
that
everybody
all
of
a
sudden
said
you
know
what
I'm
not
building
x86.
A
Right
like
in
kubernetes,
you
know
cloud
native
world,
there's
a
lot
of
go
that
goes
around.
We
could
look
at
container
d.
We
could
look
at
some
of
the
docker
utilities
and
see
like
a
lot
of
them
are
definitely
providing
ppas
right
and
to
see
whether
or
not
they're
providing
it
for
x86
and
if
they
are,
how
are
they
still
able
to
provide
it?
A
A
A
B
C
C
A
A
C
A
A
A
B
A
Yeah,
I
have
no
no
hard
stance
on
that.
Commas
just
seem
to
me,
like
they're
they're,
more
common
for
list
items
right.
So
therefore
I
could
imagine
that
a
certain
flag,
you,
you
or
a
certain
option-
I
should
say
you-
may
want
to
provide
multiple
values,
in
which
case
we'd
want
to
use
commas,
but
that's
probably
something
worth
at
least
noting.
So
if
you
don't
mind
adding
the
comment,
I
could
add
that
statement.
B
A
A
A
C
A
B
B
A
Changes
so
my
understanding
when
I
spoke
to
micah
about
this,
was
that
there
is
essentially,
I
think,
right
now.
Two
separate
implementations
of
the
registry
test,
helper
or
whatnot,
and
this
option
here
that
he's
providing
in
image
retail
is
now
something
that
hopefully,
we
should
be
able
to
use
in
pack
and
remove
the
duplication.
C
Or
sorry,
a
self-hosted
runner
so
like
before
it
was
because
of.
I
think
it
was
the
fact
that
you
can't
use
the
host
network
on
windows
containers
the
way
that
we
were
pinging
the
test
registry
with
localhost,
which
is
not
going
to
work,
and
so
this
helper.
I
think
it
resolves
the
host
for
you
so
that
you
don't
need
to
have
a
special
configuration
in
docker
desktop.
That
would
could
only
be
achieved
with
a
self-hosted
runner.
C
A
A
No,
but
I
do
appreciate
this
work
all
right
next
naming
suggestions
for
build
docker
host,
okay,
I
I
have
a
problem
with
this
like
either.
I'm
really
misunderstanding
this
flag
or
or
there
there's
a-
I
don't
know
some
some
other
sort
of
limitation.
But
why
do
we
need
to
differentiate
the
docker
host
that
lifecycle
uses
versus
the
docker
host?
That
pac
uses
right
like?
C
A
A
So
to
move
this
forward,
I
think
what
I
want
to
do
is
maybe
add
a
discussions
needed
for
this
and
get
micah
to
be
present
during
these
discussions,
so
that
maybe
he
could
shed
a
little
bit
more
light
into
some
of
the
things
that
I
just
mentioned
right.
They
they
might
not
be
accurate,
then
also,
I
would
assume,
if
it
gets
kind
of
like
hairy
like
or
complex
the
way
that
I
just
mention
things.
A
C
A
A
Sorry,
the
beauty
of
working
from
home,
all
right,
so
review
roadmap.
We
still
do
have
a
little
bit
of
time
here.
I
believe
so.
We
can
go
ahead
and
review
the
roadmap,
and
I
think
what
we're
trying
to
gather
from
this
initial
pass
is
first
acknowledge
that
the
roadmap
does
exist
right
and
then
see.
If
there's
any
sort
of
conversations
we
want
to
have
around
some
of
the
topics
on
the
roadmap.
A
And
lastly,
if
we
find
that
anything
is
missing
from
this
road
map,
how
to
essentially
elevate
that
up
to
the
core
team
members,
so
that
we
could
either
get
it
on
the
roadmap
next
quarter
for
the
year,
because
my
understanding
is
that
the
core
team
is
reviewing
the
roadmap
quarterly,
just
to
make
sure
that
we're
all
inland
or
in
sync,
so
I'm
just
going
to
kind
of
give
you
a
quick
gist
right.
So
we
want
to
do
a
lot
more
with
documentation.
A
I
think
we've
gotten
from
a
community
this.
This
idea
right,
like
this
general
idea
that
documentation
needs
a
little
bit
more
work
in
the
past.
We've
focused
more
on
implementation,
since
we
were
moving
fast,
and
I
think
that
was
all
understandable,
but
now
I
think
it's
time
for
us
to
kind
of
slow
down
and
focus
a
little
bit
more
on
documentation.
A
So
there's
that
right,
there's
the
test
api
right.
So
this
is
the
idea
that
we
should
be
able
to
run
like
for
the
for
the
sake
of
being,
you
know
explicit
with
an
example
something
like
unit
tests
in
the
same
exact
environment
that
the
build
packs
are
being
executed
so
that
when
the
final
outcome
or
the
final
output
is
produced,
it's
been
validated
along
with
the
same
sort
of
dependencies
right
in
the
same
environment.
A
A
A
I
think
the
way
that
we're
looking
at
it
is.
We
want
people
to
be
able
to
try
a
tutorial
for
the
first
time
right
then,
when
they
kind
of
want
to
get
something
done,
maybe
look
at
any
reference
documentation,
which
is
things
that
will
kind
of
give
you
the
inputs
and
outputs
and
then,
if
they
want
to
really
know
the
the
laws
right
of
of
everything
that
is
happening
and
what
the
contracts
are
between
different
components.
A
A
A
Okay,
next
thing
we
have
is
stack,
build,
packs
right.
So
this,
if
you've
been
in
the
community
you're
kind
of
aware
of
it's
the
idea
of
providing
elevated
operations
during
the
build
process
to
build
packs,
so
think
of
like
root
operations
that
you
could
do
on
a
stack.
These
sort
of
build
packs
would
be
special
and
there's
an
rfc
already
for
this.
The
work
has
already
commenced
on
this
and
again
should
enable
a
lot
of
things
like
being
able
to
install
packages
and
so
on
at
build
time.
A
Okay,
next
is
a
develop
api,
so
this
is
speaking
very
similarly
or
yeah
very
similarly
to
the
test
api,
where
developers
are
expecting
things
to
be
validated
in
this
one.
App
developers
are
wanting
this
sort
of
like
what
we
call
inner
loop
development
iterations,
where
it
means
I'm
in
the
middle
of
developing
an
application
right
and,
let's
say,
for
instance,
a
ruby
application.
A
I
don't
want
to
have
to
have
ruby
installed,
and
I
want
to
even
further
make
sure
that
the
same
version
of
ruby
is
installed
in
my
development
environment
as
the
one
that's
going
to
be
used
during
the
build
time
for
the
final
artifact
right.
So
it
kind
of
ties
all
of
that
in,
but
in
a
way
where
you
could
more
rapidly
start
development.
The
development
process
without
having
to
have
a
you
know:
local
development
environment,
to
the
extent
that
you
had
to
do
it
before
again
very
high
demand
for
this.
A
A
So
that's
the
develop
api
and
then,
lastly,
is
integration
with
the
cloud
native
ecosystem
right,
so
on
this
one
we
want
to
be
have
a
better
yeah,
better
integration
with
two
ecosystems.
One
of
them
is
the
kubernetes.
You
know
clustering
on
the
cloud
type
solutions
and
then
the
other
one
is
the
local
docker
experience.
A
A
A
I
think
that's
pretty
much
up
in
the
air
in
tbd,
because
there's
depending
on
the
language
right
and
depending
on
on
the
type
of
test
right,
so
you
could
think
of
a
unit
test
where
it's
typically
operated
at
the
source
code
level
versus
like
an
integration
test.
That's
operated
on
the
outputs,
the
the.
A
I
think,
a
good
example
that
I've
seen
out
in
the
wild
is
the
open
shift,
s2i
model
where
they
have
like
a
pre-hook
and
a
post
hook,
and
so
you
could
in
any
one
of
those
execute
any
arbitrary
operation
and
one
of
the
things
that
some
developers
would
do
is
put
their.
Let's
say
unit
tests
in
the
pre-hook
right
and
basically
they
would
run
their
unit
test.
A
If
they
don't
pass,
then
nothing
works
right
and
then
on
the
post
hook
very
similarly,
you
know
they
would
run
tests
on
the
binaries
that
were
created
at
any
point
in
time
during
the
build
process.
And
then,
if
any
of
these
scripts,
pre-hook
or
post
hook
fail,
the
build
fails
as
a
whole.
So
it
doesn't
generate
the
final
output
of
an
image
right.
A
C
A
There's
certain
languages,
for
instance,
that
would
contaminate
the
the
build
outputs
right
so,
for
instance,
java
like
if
you
instrument
it,
your
classes
would
have
like
a
whole
bunch
of
additional
overhead,
and
so
you
wouldn't
want
those
generated
classes
to
be
your
final
output
right,
like
you'd,
essentially
have
to
reconstruct
all
that.
So
again,
it
might
be.
You
know
specific
to
languages,
but
I
think
we
want
to
create
a
solution
that
applies
to
as
many
you
know
possible
options
as
possible.
That
was
so
weird
yeah.
B
A
B
A
Yeah,
I
think
it
it's
my
understanding
that
the
potato
team
is
actually
working
on
on
a
little
bit
of
this
right.
So
there's
two,
the
potato
team
is
looking
for
some
solutions,
and
I
know
that
they've
done
a
little
bit
of
research
that
they've
published
on
tilt,
and
maybe
even
the
google
build
packs,
because
the
google
build
packs
have
a
dev
mode
associated
to
them
as
well
right.
A
So
I
think
the
the
build
pack
distributors
or
vendors
right
they're
very
much
looking
for
a
solution
to
this,
so
they
might
be
the
ones
that
kind
of
produce
it
because
again
it.
It
may
be
also
very
specific
to
a
language
right
which
they
are.
The
ones
that
have
the
most
knowledge
about,
and
we
would
just
clarity,
build
packs
as
a
whole
would
just
enable
that
sort
of
functionality.
B
A
A
So
having
a
similar
architecture,
I
think
would
be
awesome
if,
like
let's
say,
for
instance,
pack
could
have
this
sort
of,
let's
say
socket
or
our
pc
integration,
where
you
could
communicate
with
it
via
some
other
front
end
or
ide
right
and
it
just
like,
runs,
build
packs
and
all
this
stuff.
So
like
the
ids
themselves,
don't
have
to
implement
everything
from
scratch,
but
use
some
intermediary
sort
of
solution
like
a
pack
or
whatever
other
tool.
We
may
want
to
create
for
something
like.
B
A
So
I
think,
there's
a
slight
action
item
from
a
maintainer
standpoint
in
regards
to
the
roadmap,
where
I
think
we
should
label
the
issues
that
may
be
associated
to
roadmap
items
like
I
think,
we've
done
in
the
past.
So
that
way
we
could
maybe
even
be
able
to
filter
and
focus
on
those
issues
and
make
sure
that
we
try
to
push
those
a
little
bit
more
focus
than
other
issues.