►
From YouTube: Platform Sync: 2021-04-07
Description
Meeting notes: https://bit.ly/38pal2Z
A
All
right,
the
first
thing
we've
got
is
status
updates,
since
I'm
speaking
I'll
talk
a
little
bit
about
what
I've
been
working
on.
There
isn't
too
much
that's
specific
to
the
platform
sub
team,
but
there
is
an
open
pipeline
pr
to
the
tekton
catalog,
I'm
still
having
issues
with
the
the
catalog
community
and
getting
prs
accepted
the
dependency
like
tasks
that
the
pipeline
uses.
A
A
B
Just
been
working
on
asset
cash
stuff
still,
but
it's
really
just
adding
extra
tests
and
comments
at
this
point
everything
pretty
much
works
so.
A
Okay,
we
will
move
on
to
release
planning.
I
know
david
isn't
here,
but
there's
there
was
a
conversation
brought
up
by
emily
about
the
potential
of
a
patch
release
for
pac.
A
Specifically,
there
are
there's
some
hardship
around
duplicate
layers
and,
more
specifically,
when
the
quote-unquote
same
version
of
the
build
pack
and
yeah
is
being
brought
in
from
two
different
locations,
and
apparently
it's
not
matching
for
whatever
the
reason
may
be.
That
creates
a
pretty
gnarly
error.
That's
really
hard
to
to
troubleshoot.
A
My
feedback
was
more
or
less
on
on
seeing
if
there's
anything,
we
could
do
that
doesn't
require
a
patch.
Given
that
this
issue
has,
you
know,
essentially
existed.
You
know
for
a
very
long
time.
It
sounds
like
david
is
of
the
opinion
that
we
should
be
able
to
do
a
patch
release.
The
only
thing
is
that
I'm
not
entirely
sure
who's
taking
ownership
of
that
right
now.
B
Yeah
I
can
ship
a
patch
release,
for
this
looks
like.
B
B
A
I
can
do
this
cool.
Is
that
again,
I'm
kind
of
letting
david
drive
a
lot
of
this
out
but
yeah.
If,
if
you
need
additional
support,
please
feel
free
to
ping
me.
A
If
there's
anything
on
here
that
you'd
like
to
discuss,
please
speak
up
now.
A
B
Okay,
wait
a
minute.
I
just
exceeded
the
maximum
character
length.
B
A
Does
that
mean
that
you'd
like
to
discuss
it
right
now
or
you'd
like
people
to
just
review
it.
B
I
mean,
I
think
the
discussion
will
take
like
two
seconds
cool.
It's
basically,
I
don't
really
know
if
we
want
to
do
this
because
it's
either
you
get
almost
nothing
or
you
get
like
a
humongous
fire
hose
of
stuff,
which
is
why
I'm
running
into
this
massive
character
limit
trying
to
post
some
of
the
output
but
yeah.
So
it
seems
like.
Maybe
we
don't
want
to
do.
A
B
B
B
A
B
B
A
A
I
don't
remember
exactly
what
the
life
cycle
has,
but
I
feel,
like
log
levels,
seems
a
little
bit
more
appropriate
where
there's
more
than
just
two
tiers,
whether
you're
verbose
or
you
just
do
you
know
standard
output
and
then
I
believe
we
might
even
have
a
quiet
mode
right
to
me.
That
seems
like
maybe
more
trace
level
right,
which
again
is
it's
very
useful
for
troubleshooting
stuff,
but
not
something
that
we
currently
support,
and
I'm
not
sure
if
we
want
to
support.
A
Yeah,
I
think
that's
where,
like
that
intermediate
solution,
I
was
referring
to
right,
like
some
sort
of
filtering
to
only
the
network
traffic
that
we
care
about,
maybe
in
a
verbose
mode,
but
yeah,
I'm
not
entirely
sure
that
there's
there's
like
a
very
specific
solution
at
this
point
in
time.
The
other
thing
I
was
thinking
about
too
is
that
some
of
the
networking
is
actually
occurs
inside
of
the
life
cycle
right
so
posting
up
to
a
registry
and
whatnot,
because
I
was
thinking
about
the
the
hanging
issue
that
they
recently
ran
into.
A
B
A
Interesting,
I
think
it
may
be
worth
you
know.
I
think
you,
you
did
us
a
service
here
by
putting
like
what
the
output
looks
like
it
might
be
worth
adding
the
comments
that
we
just
brought
up
about
like
some
of
the
potential
solutions,
some
of
the
shortcomings
and
then,
ultimately,
the
we
probably
want
to
hold
off
on
this
until
we
see
more
of
a
need
for
it
or
more
of
a
desire.
A
C
A
That's
a
good
call
out.
I
know
I'm
definitely
interested
what
would
be
your
preference,
because
I
think
I
have
it
the
context.
I
just
would
like
to
maybe
discuss
some
of
the
options
and
clarify
some
things.
C
Okay,
yeah
yeah,
so
my
my
summary
of
the
current
situation
is,
we
assume
a
docker
demon
on
a
local
docker
demon
is
the
default
for
all
pac
users.
C
Pod
man
folks
want
to
be
able
to
use
a
podman
demon
instead
and
then
for
use
case.
I
use
a
lot
as
a
remote
demon.
Usually
a
windows,
remote
demon,
communicating
over
tls
so
like
this
was
an
incremental
at
least
the
initial
feature
was
to
add
a
dash
docker
host
flag,
which
was
targeted
just
said,
specifically
sporting
pod
man
with
a
few
iterations,
and
I
think
what
it
landed
on
is
sort
of
potentially
confusing
to
some
users.
C
C
So
I
think
what
I
kind
of
want
to
do
is
the
next
step
is
to
chart
out
all
the
rest
of
the
scenarios
and
different
ways
that
you
might
want
to
provide
an
alternate
demon
and
kind
of
holistically
come
up
with
a
solution
for
what
the
flag
should
be
there.
Obviously,
we
ship
this
and
that
people
might
be
using
it.
C
So
we
kind
of
want
to
keep
that
in
mind
too
so
yet
another
scenario
to
work
in
there,
but
I
think
there
is
kind
of
it's
it's
starting
to
feel
like
there's
a
pretty
simple
way
to
solve.
For
most
of
these
scenarios,
I
just
kind
of
want
to
like
put
all
my
thoughts
out
there
to
get
feedback
on
that
see.
If
people
agree.
A
Okay,
cool,
I
I
think
that
makes
sense,
seeing
all
the
use
cases
would
definitely
help
bring
a
better
picture
to
it.
A
I
know
in
the
last
meeting
when
this
was
discussed,
I
think
I
was
maybe
oversimplifying
it
to
the
point
where
I
was
wondering
why
a
single
flag
wouldn't
be
as
useful,
right
or
or
wouldn't
be
like
the
best
case,
where
we
would
have
just
one
docker
flag
that
does
apply
to
both
pac
and
the
life
cycle
right,
because
I
think
that
is
the
general
expectation,
and
my
hope
would
be
that
that
particular
solution
would
work
for
both
the
life
cycles,
targeting
of
a
dr
damon
as
well
as
pack
of
itself
right
and
I
I
know
that
there
may
be
some
like
networking
use
cases
that
are
probably
the
things
that
you're
speaking
to
where
the
life
cycle
can't
access
the
thing
that
pac
can
access
right
and
in
those
particular
cases.
A
I
think
again.
My
simplification
was
like,
if
that
were
to
happen,
just
providing
the
user
with
more
guidance
on
what
to
set
that
one
value
to
would
be
ideal
versus
having
multiple
flags
for
configuring.
Multiple
aspects
of
how
communication
occurs
right
because
I
I
basically
don't
think
it
would
be
useful
if
the
end
user
needs
to
know
that
there's
something
else
like
there's
this
container
running,
underneath
it
that
the
lifecycle
needs
to
figure
out
how
networking
goes
into
it.
C
100
agree:
yeah,
I
think
a
single
flag
is
the
is
the
right
way
to
go.
I
think
right
now,
there's
sort
of
a
de
facto
two
sources
of
information,
which
is
the
docker
host
environment
variable
exposed
to
pac.
So
if
we
could
make
that
not
be
part
of
like,
if
you
use
docker
host,
it
stops
paying
attention
to
this
other
source
right
just
like
make
a
make
it
straightforward.
C
A
Okay,
yeah,
that
totally
makes
sense.
Do
you
know
I
guess
what
the
strategy
is
for
writing
all
these
opinions
down.
C
What
the
user
is
trying
to
do
the
exact
pack
invocation
and
then
just
hand
wavy
of
what
the
of
what
the
expected
outcome
would
be.
It
wasn't
on
this
issue.
That's
that
link
linked
here.
This
was
a
user
coming
back
and
saying:
hey
the
feature
you
just
introduced
seemed
weird,
but
the
source
issue,
I
think,
is
nine.
I
said
988
or
something
like
that
so
yeah.
To
answer
your
question,
I
would
just
kind
of
lay
it
out,
like
markdown
document,
with
five
different
headers
in
each
one.
A
This
yeah,
I
wonder
if
creating
an
rfc,
that's
targeted
to
the
platform
team,
would
be
the
the
like
a
more
favorable
method.
A
Just
because
then
we
could
iterate
and
comment
on
a
single
document,
because
I
think
the
the
comments
as
they
are
now
for
issues
become
a
little
bit
confusing
to
like
follow
the
story
right,
yeah
it,
and
now
that
I
think
we
could
target
just
a
sub
team.
We
could
have
this
conversation
within
this
scope
and
not
you
know,
have
to
worry
too
much
about
it
being
overly
exposed
yeah.
That
sounds.
A
A
Okay,
so
maybe
we'll
start
at
the
top
anthony,
I
know
you
have
a
draft
rfc.
Is
this
something
that
you'd
like
to
discuss
at
this
point
in
time.
B
Maybe
not
for
this
meeting
I
I
definitely
wanted
to
speak
at
it
about
a
working
group.
Maybe
the
next,
maybe
the
next
implementation.
If
things
move
forward
there
I'll
bring
it
up
again,
but.
A
A
Sounds
good,
okay,
looking
forward
to
that
one
pack,
cash
options.
I
believe
we
reviewed
this
last
time,
and
I
know
that
there's
some
edits
that
I'm
wanting
to
make
to
this.
So
unless
there's
any
questions,
we
could
just
skip
over
this
one
all
right.
A
A
B
B
At
one
point
I
thought
I
heard
somebody
say
that
some
team,
specific
rfcs,
should
actually
be
pr
to
a
subfolder
of
the
rfc
repo
and
not
the
top
level.
Zero.
Zero,
zero,
zero,
but.
A
A
Okay,
now
with
that
we're
done
with
rfcs,
I
think
we
have
some.
I
added
arm
support
to
the
topic.
A
C
Yeah
I'll
say,
most
of
my
inspiration
so
far
has
just
been
out
of
personal
interest.
Hasn't
overlapped
a
lot
with
our
with
our
teamwork.
Unfortunately,
but
there's
perhaps
that
will
change.
C
I
think
that's
that
is,
unfortunately
out
of
my
hands,
but
I
think
I'd
be
super
interested
to
know
if
there's
other
folks
in
the
in
the
community
that
have
you
know
like,
especially
if
salesforce
folks
or
any
other
people
have
interest
in
this,
because
I
think
my
hobby
hobby
approach
to
it
could
probably
be
made
better
by
like
a
direct
product
alignment.
C
I
think
that,
like
the
biggest
pieces
that
feel
like
are
are
going
to
come
up
as
discussion
points
are
how
to
tease
apart
the
fact
that
most
demons
can
sort
of
gloss
over
the
fact
that
arm
support
can
work
and
or
have
emulated,
support
be
in
there.
I
think
we'll
need
to
potentially
know
like
do.
We
need
new
stack
ids
for
things
that
are
going
to
be
arm,
or
do
we
use
mixins
to
differentiate
these
things
apart,
like
all
of
it
kind
of
there's
just
some
interesting
scenes.
C
C
Do
we
need
a
bionic
arm,
stack
md64
and
does
it
balloon
out
from
there,
but
it
says,
like
avoid
going
too
deep
into
the
details,
I
think
I
would
just
love
to
know
like
a
straightforward
user
user
scenario
and
have
that
kind
of
drive.
Some
of
this
out
probably
definitely
warrants
a
big
rfc,
but
I
don't
necessarily
know
just
give
them
the
context
I
have,
if
I'm
the
the
one
to
beat
it
right
now,.
B
Yeah,
I
guess
just
speaking
from
the
salesforce
side,
I
have
not
heard
anything
come
up
with
arm.
Unfortunately,
it's
probably
not
the
news
you
want
to
hear,
but
that's
fine.
C
B
I
don't
know
if
there's
no
desire
just
hasn't
come
up
that
I've
heard
of
in
the
various
channels,
like
maybe
there's
people
who
want
it.
That
are
our
customers,
but
we
definitely
just
haven't
gotten
far
enough,
where
we've
kind
of
seen
that
interest
yeah.
C
Yeah
I'll
call
it
too,
like
just
because
we
I
haven't
heard
a
customer
on
my
side
like
a
windows
customer's
not
going
to
ask
for
arm
stuff,
I'm
I'm
probably
the
worst
source
of
data
on
there
too.
So
I
think
they're
very
well,
maybe
other
folks
around
here
can
leave
that
a
little
bit
more
like
I
said
most
of
it's
just
been
personal
personal
interests
and
I
definitely
would
be
happy
to
dive
deep
into
the
technical
pieces,
but
I'm
looking
for
a
good
thing
to
drive
it
up.
A
I
know
in
one
of
our
either
working
groups
or
office
hours.
There
was
a
google
rep.
I
don't
know,
I
don't
remember
exactly
the
title,
but
they
were
curious
about
arm
support
and
it
did
sound
like
they
were
hoping
to
support
it
right
that,
like
they
were
investigating
the
feasibility
of
support
with
you
know,
build
packs
in
the
picture.
A
So
I
do
think
that
there
are
some
like
use
cases,
product
and
user
use
cases
that
are
probably
worth
exploring,
and
I
think
that
brought
up
a
lot
of
really
good
questions
and,
if
I
remember
correctly,
the
one
action
item
that
we
have
right
now
is
probably
to
create
like
a
a
matrix
of
all
the
possible
like
permutations
of
where
arm
support
right,
comes
into
play
and
like
what
that
would
mean
right.
A
So
is
it
like
a
arm
host
with
you
know
dr
damon
elsewhere
right
like
what
does
that
look
like?
Is
it
the
build
packs
themselves
running
in
arm
architecture,
or
is
it
the
oci
image
you
know
that's
being
produced
in
in
arm
architecture
fashion?
So
like?
I
think
that
those
are
the
the
questions
and
like
we
want
to
create
this
matrix
and
maybe
prioritize
like
which,
which
one
of
those
like
permutations,
makes
the
most
sense
to
really
like
put
a
stamp
behind
and
some
focus
on.
B
Are
you
thinking
of
because
I
feel
like
this
is
one
thing
that
has
come
up
from
some?
I
think
we're
at
time.
Oh
mike
swick
from
some
of
the
I
think,
initial
discussions
around
stuff.
This
spec
was
like
the
build
and
run
image
having
to
be
the
same
architecture,
I
think
arm
probably
is
one
of
those
use
cases
where
it
brings
that
into
question
yeah,
because
I
feel
like
a
lot
of
the
stuff.
C
A
Cool
that
makes
sense.
I
believe
this
meeting
actually
goes
for
another
30
minutes.
If
I'm
not
mistaken,
we
extended
it.
B
A
Yeah
I
mean
I
hate
to
say
this,
but
I
think
I
inadvertently
volunteered
myself
to
do
it
because
nobody
else
did,
but
it
was
in
a
working
group
meeting
that
I
could
maybe
find
a
link
to.
So
if
you
missed
that
conversation
be
part
of
that.
A
Yeah,
no,
I
I
guess
from
my
perspective,
like
I'm
trying
to
I'm
having
issues
on
this
like
determining
exactly
where.
To
put
it
right,
I
think
ultimately,
it
might
set
off
as
a
hack,
md
or
google
doc
and
then
take
it
from
there.
A
Cool
yeah
I'll
definitely
create
something
and
I'll
share
it
most
likely
in
the
arm
slack
channel.
So
if
you're
not
already,
there
that'd
probably
be
where
a
lot
of
this
conversation
takes
place.
B
A
Yeah
we
reviewed
it.
I
it
looks
like
last
week,
I'm
looking
down
here
yeah
last
week
and
I
think
there
wasn't
any
real
outcome
or
feedback
that
was
produced
that
required
an
action
item
other
than
adding
labels
and
yeah
to
all
the
repos,
and
I
believe,
there's
a
pr
to
add
them
to
all
of
the
repos,
because
I
added
it
to
some,
but
I
don't
believe
all
of
them
are
there
just
quite
yet.
B
A
So
I
think,
based
on
the
conversation
that
we
had,
because
these
are
like
project
level,
scoped
items
right,
you
could
maybe
even
consider
them
sort
of
like
epics,
and
so
we
wanted,
like
one
of
the
ideas
was
we
wanted
to
like
identify
issues
that
were
created
that
could
be
associated
with
a
roadmap
item
so
that
we
could,
at
a
high
glance,
give
them
a
little
bit
more
higher
presidents
or
higher
priority
so
that
that's
what
the
general
basis
for
this
is.