►
From YouTube: Platform Sync: 2021-06-02
Description
Meeting notes: https://bit.ly/38pal2Z
A
B
B
All
right,
so
the
first
thing
in
order
is
a
note
taker.
I
think
this
is
a
new
role
within
our
meetings.
Does
anybody
volunteer
on
taking
notes
for
today.
B
All
right
to
start
off
status
updates.
I
personally
haven't
been
focusing
on
the
platform
all
too
much
so
I'll.
I
can't
speak
to
that
myself.
Anybody
else
have
any
status
updates.
C
Yeah,
well,
I
guess
we
released
another
version
of
pack,
so
that's
out
in
the
wild
and
you
can
actually
download
it
and
use
it
version
19.
Oh,
I
guess.
Oh.
C
C
B
D
This
isn't
one
for
me
specifically,
but
ben
went
ahead
and
split
up
your
spec
pr,
daniel,
and
so
hopefully
we
can
get
that
merged
in
to
move
forward
with
that
ask
cash
work.
C
B
I'm
teasing
all
right
moving
on
to
release
planning,
I
believe
we're
we're
setting
up
the
milestone
for
0.20.
I
know
that
there
were
a
couple
things
on:
oh
19
that
didn't
get
completed.
Those
would
probably
be
migrated
over.
B
There
was
one
thing
to
maybe
call
out
here
for
the
tecton
pipeline
or
catalog
that
one's
still
stuck
in
review
and
the
there's
a
teton
hub,
which
is
essentially,
like
you
know,
think
of
docker
hub,
like
where
you'll
be
able
to
look
for
tasks
and
pipelines
within
the
tecton
ecosystem,
they're,
adding
the
support
for
multiple
catalogs.
B
So
instead
of
trying
to
push
this
pipeline
through
it's
already
available
right,
but
just
not
through
the
catalog,
I'm
going
to
wait
and
maybe
push
put
more
effort
in
us
hosting
our
own
catalog
for
just
the
build
pack
related
tasks
and
pipelines
and
that'll
make
it
a
lot
easier
to
maintain
and
reduce
a
lot
of
the
toil
for
the
release
of
further
tecton
related
work.
B
What's
the
trade-offs,
the
initial
trade-off?
The
reason
why
we
didn't
do
it
initially
was
this
discovery
right?
I
did
put
it
in
the
issue.
I
could
look
for
it,
but
basically
there's
the
discovery,
part
of
it
where
the
tecton
catalog
posted
all
of
them
right,
and
so,
if
people
went
in
there,
they
wouldn't
find
build
packs.
Well,
now
that
they're
kind
of
moving
to
a
ui
focus
one
with
tefton
hub
and
us
being
able
to
plug
in
our
catalog
into
that
the
discoverability
concerns
are,
you
know
moot
now.
B
The
other
part
was
kind
of
the
flip
side
of
us
being
held
up
on
review
is
that
they
actually
did
review
stuff.
So
like
it
added
to
a
lot
of
our
you
know,
I
guess
stability,
and
so
now
we
will
be
losing
that
review
process
from
a
lot
of
tectonic
community
or
maintainers,
but
I
will
say
that
that
has
you
know
increasingly
gotten
slower
and
more
lacking.
So
I
don't.
B
So
from
the
technical
side,
it's
all
just
file
system
based
as
long
as
you
follow
a
certain
structure,
it'll
just
catalog
it
or
index
it.
B
C
B
B
I
guess
I'm
I'm
having
trouble
understanding
how
this
is
a
podman
specific
issue,
because
we
communicate
to
podman
via
the
docker
socket,
in
which
case
like
we
don't
have
access
to
the
file
system
right
unless
we're
talking
about
like
volumes
and
stuff.
B
So
I
feel,
like
the
issue,
might
not
be
descriptive
enough
and
it
would
be
nice
to
call
out
like
what
files
he's
seeing
that
are
in
the
temp
directory,
and
I
was
trying
to
read
it.
But
it's
not.
It
seems,
like
builder
layers,
are
maybe
placed
in
the
temp
directory
by
pack
itself
before
actually
putting
them
into
the
container
and
we're
just
not
clearing
them.
And
if
that's
true,
and
if
we're
not
deleting
them
after
the
build,
then
we
probably
should
be-
and
maybe
that's
the
discussion
that
we
have
to
have.
C
C
C
B
Yeah
so
I
mean
for
contacts
this.
The
person
reporting
is
somebody
from
pogba.
A
B
B
So
I
think
again,
I
just
it'd
be
nice
to
have
a
little
bit
more
clarification
as
to
what
files
he's
talking
about
specifically
or
maybe
just
you
know,
digging
into
it
a
little
bit
deeper.
B
Good
all
right,
I
guess
it
seems
like
there's
an
action
here
for
additional
clarification
or
testing
before
we
make
any
further
or
have
any
further
discussion.
Does
anybody
want
to
take
that
on.
A
B
I
mean
so
we
support
the
damon,
socket
api
right,
and
so
I
think
that's
as
far
as
our
support
goes.
B
B
All
right,
let's
see
so,
if
we've
taken
care
of
all
that.
B
Starting
from
the
bottom
pack
cache
options,
this
is
something
that
myself
or
steven
was
supposed
to
merge
in.
I
know
I'm
working
on
an
issue
creation
bot
that
is
kind
of
taking
a
lot
of
my
focus,
but
this
should
go
in
and
should
allow
for
a
lot
of
work
to
be
done.
B
A
On
that,
first
of
all,
I
still
don't
know
what
to
do
with
this
interact
mode.
The
previous
one,
like
I'm,
fully
happy
to
close
it
right
in
favor
of
the
newer
one
as
per
your
instructions,
but
the
visual
mode,
one,
the
one
on
the
top
again,
I'm
really
just
waiting
for
next
steps.
Here,
it's
as
we
recall
it's
just
a
more
pared-down
version
of
you
know
the
original
idea.
It's
it's
basically
not
interactive,
but
it's
just
purely
a
visual
visual
representation
of
what
you
do
when
pac
is
building
right.
A
B
And
you
have
a
prototype
if,
if
we're
thinking
next
steps,
how
close
is
the
prototype
to
actually
being
implemented
like?
Is
it
production
ready.
A
Okay,
I
was
that
is
I'm
sorry
that
I'm
sorry,
that
is
not
production
ready
at
all,
that
is,
it
does
absolutely
nothing
to
do.
That
is
really
just
a
visual
mock-up
like
it.
You
know
it's
a
bunch
of
sleep
statements,
I'm
printing,
the
right
colors
on
the
screen
it.
It
has
absolutely
no.
B
I
love
it
all
right,
well
good
to
know.
That
being
said,
I
think
if
we
step
back
to
what's
necessary,
I
know
I
already
approved
it.
It
seems
like
we
have
two
other
maintainers
that
need
to
we
need
at
least
one
more
would
be
my
my
statement.
B
B
We
might
need
it,
but
yeah
if
david
could
approve
it.
I
think
we'll
definitely
be
fine.
A
All
right,
forgive
me
for
speaking
out
of
turn
here,
but
a
big
t,
big
terrance.
Are
you
not
a
platform
maintainer.
D
I'm
not
that
was
steven.
I
mostly
started
coming
because
stephen
does
not
come
and
there
should
be
someone
from
the
core
team
who
is
part
of
each
of
these
sub
teams
are
involved.
I
mean
for
the
most
part.
I
think
javier
can
he's
part
of
basically
all
the
leadership
meetings
that
we
have,
but
I
think
it's
still
good
to
have
someone
on
the
court
team
there.
D
It's
probably
something
we
will
talk
about
tomorrow
and
are
one
of
some
of
the
discussions.
We're
gonna
have
on
the
core
team
and
leadership.
B
I
I
hear
where
you're
coming
from
anthony.
I
will
try
to
get
on
these
other
individuals
and
make
sure
that
we
get
this
in
as
soon
as
we
can.
B
A
E
Okay,
let's
see.
B
D
I
I
just
add
this.
I
asked
a
question
I
think
anthony
responded
to,
and
I
was
just
curious,
not
in
the
specifics
of
platform
06
but
kind
of
what
is
the
policy
or
I
guess,
like
a
deal
for
when
pack,
I
guess,
supports
a
platform
platform
api
when
it
comes
out.
I
think
this
kind
of
goes
in
line
with
some
of
the
previous
discussions
around
like
documenting
what
platforms
are
supported
and-
and
I
guess
for
context
like
this-
came
up
because
we
implement
our
own
pipeline
somewhere.
D
I
guess
like
capec
or
whatnot
on
the
salesforce
side
for
our
own
platform
and
we
were
supporting
using
the
latest
lifecycle
on.
So
we
had
like
platform
06
as
a
thing
and
then
we
realized.
We
also
tell
customers
to
use
pac,
but
they
can't
use
platform
106
and
I
don't
think
that's
a
big
deal
generally,
but
it
does
mean
that
potentially
they
could
build
and
run
stuff
locally.
That
may
function
a
little
differently
than
what
is
supported
on
our
platform
and
obviously
we
could.
D
I
guess
like
choose
to
use
an
older
version
of
the
platform
api,
but
mostly
on
my
team
that
we're
working
on
and
just
kind
of
assumed,
pac
supported
the
latest
thing
that
was
released,
and
I
guess
we
were
kind
of
surprised
that
it
didn't
again
like
not
not
a
huge
thing,
but
just
more
curious
on
kind
of
where
that
stands.
If
that
makes
sense,.
B
Yup
that
makes
sense,
let's
see
so.
I
know
that
the
pack
specifically
works
very
different
than
life
cycle.
As
far
as
release
cadence
right,
we
don't
block
for
completion
of
a
specific
api
support,
so
there's
that
historically,
we've
also
gone
in
with
the
mindset
of
supporting
n
minus
one
right,
which
is
supporting
the
latest
version
of
a
platform
api,
and
you
know
the
previous
version
and
then
dropping
support
for
any.
You
know
I
guess
older
apis
after
that.
As
far
as
I'm
aware
that
may
not
be
encoded
anywhere.
B
I
do
know
that
this
is
something
that
we
you
know
recently
have
discussed
and
dan
was
working
on,
maybe
adding
some
of
that
to
the
release
notes.
If
I
remember
correctly,
I
don't
know
exactly
where
that
effort
is
then,
if
you're
still
there
do,
you
have
something
to
speak.
C
Up
yeah,
I
have
not
added
this
to
the
release
notes
but
like
in
terms
of
the
like.
B
Yeah,
I
think
if
we
once
we
have
this,
you
know
compatibility
list
essentially,
then
we
could
start
creating
sort
of
strategies
for
supporting
full
releases
of
platform,
api
or
any
other
form
of
api
right
where
those
themselves
can
become
epics,
and
that
way
they
become
a
little
bit
easier
to
track.
B
Something
else
that
I've
also
kind
of
thought
about.
Considering
is
once
we
have
epics
with
very
defined
things
that
we
need
to
achieve
for
for
a
certain
group
of
tasks.
They
can
easily
become
projects
for
mentorship
programs
right,
and
so
I
think
we
could
leverage
a
lot
of
of
that
as
well
there.
So
I
think,
just
being
a
little
bit
more
organized
in
that
fashion
would
be,
would
yield
a
lot
of
really
good
results.
B
D
Awesome
how's
this,
I
guess
on
the
cincinnati's
here
on
the
lifecycle
side.
They
must
do
something
similar
right
for
supporting
the
various
apis
as
they
come
out.
D
I
guess
by
very
nature
of
it
being
life
cycle
and
having
to
be
much
more
stringent
about
it.
How
how
do
you
all
handle
that
on
that
sub
team.
D
I
guess
just
tracking
implementation
not
really
like
managing
the
code
itself.
I
assume
that
is,
you
know
handled,
however,
that's
best
per
project,
but
I
wonder
if
it
makes
sense,
I
guess
like
when
we
do
spec
release
planning
to
basically
create
like
when
a
spec
is
released,
to
create
milestones
or
something
in
the
respective
projects
that
we
then
like
as
a
sub
team,
can
then
populate
the
issues
based
on
that
spec
or
whatever.
E
On
the
life
cycle
side,
it's
fairly
clear
cut
for
us
because
we
aim
to
tie
each
release
at
least
each
minor
version
to
a
api
bump
right
now,
that
is
platform
and
build
pack
api
like
they're
kind
of
moving
in
lockstep,
although
they
don't
necessarily
have
to
be.
But
for
us
it's.
It's
always
very
clear
what
needs
to
go
into
the
next
release
because
it
is
just
going
to
be
implementing
whatever
whatever
is
in
the
spec.
B
The
platforms
and
in
this
case
pac,
don't
get
that
same
sort
of
input
right
because
they're
always
lagging
behind.
They
need
the
life
cycle
to
provide
it
first
and
then
pack
can
implement
it
afterwards.
So
we
don't
get
to,
I
guess,
have
as
much
input
as
to
what
set
of
changes
go
into
the
spec
for
any
given
platform,
api
version
or
any
api
version
that
we
need
to
support
or
integrate
with.
B
Did
I
misspeak
there
not
only
at
all.
E
No,
that's
that's
totally
fair.
We
we've
definitely
kicked
out
issues,
you
know,
or
at
least
pushed
them
to
the
next
spec
release,
because
we
wanted
to
ship
at
a
certain
time
frame.
I
think
I
agree
that
the
platform
side-
you
don't
have
that
same
level
of
freedom.
B
Yeah,
so
I
think
for
us
you
know
I
mean
we
could
discuss
whether
we
want
to
bulk
release
right.
Let's
say
the
next
upcoming
platform
api
and
say:
okay,
we
will
we're
going
to
try
to
ship
this
all
together,
so
it's
complete
or
continue
our
current
pattern,
which
is
kind
of
like
almost
best
effort
for
any
api.
B
But
I
think
what
we're
definitely
missing
is
just
any
form
of
formal
notification
of
what
the
state
is
right,
and
so
I
think
two
two
things
would
help.
There
is
to
your
point
turns
like
creating
issues
out
of
the
spec
releases.
That
then
point
to
things
that
could
be
implemented,
but
also
on
the
release
notes
themselves.
D
Yeah
I
mean,
I
think
that
helps
I
mean.
I
also
wonder
like
if
the
premier
platform,
that
is
kind
of
one
of
the
one
of
the
major
platforms
that
we
release
as
part
of
the
project,
should
have
input
on
what
goes
and
does
not
go
into
the
spec
like
it
makes
sense
for
a
life
cycle
to
have
the
level
of
control
it
does.
But
it
also
seems
like
the
platform
sub
team
by
the
name
should
have
something
to
put
on,
should
also
have
some
input
there.
D
You
know
probably
not
the
same
old
control
that
implementation
does,
but
I
guess
that's
like
a
reference
point
right
like
platform.
Api
06,
which
I
mentioned,
was
released
on
march
29th
and
it's
like
june
2nd
right
now,
and
so
you
know
like
it.
I
I
do
think
that
the
platform
team
should
have
input
and
say
on
kind
of
those
things
as
well.
B
B
You
know
completely,
you
know
an
aside
on
something
like
tekton
quote-unquote,
these,
like
simpler
platforms,
we've
chosen
to
stay
a
couple
platform,
api
versions
behind,
just
because
the
builders
themselves
don't
haven't
updated
their
support
right,
so
we're
trying
to
kind
of
like
level
set
or
base
set
on
all
the
builders
compatibility
as
well,
but
that's
completely
different.
B
C
Oh,
I
was
just
gonna
say
that
we,
I
think
there
is
like
pr
here
to
support.
C
C
I
don't
know
what
our
philosophy
is
on
cutting
patch
releases,
but
it
feels
like-
or
maybe
that's,
there's
like
too
much
stuff
to
throw
in
one.
But
it
feels
like.
D
C
I
agree
that
this
pro
stuff,
probably
should
have
gone
out
like
we
were
missing,
05
and
o6
and,
like
I
don't
even
I
don't
even
want
to
look
up.
105
was
written
and
finalized
because
that
was
probably
a
long
time
ago.
D
Yeah
and
and
on
my
half
behalf
for
at
least
the
salesforce
side,
it's
not
like
we
don't
need
an
emergency
patch
release
for
this
platform.
Api
real
thing,
it's
more
of
just
trying
to
figure
out
like
what
the
stance
and
policy
is
of
kind
of
what
the
expectation
of
one
stuff
should
will
get
supported
and
not
like.
We
need
something
done
today,
kind
of
thing,
so
I
I
would
just
patch
in
the
normal
set
of
release,
cans
that
going
to
do
and
that's
fine.
B
All
right,
so
I
added
an
action
to
create
epics
for
apis,
as
they
come
out
I'll
kind
of
keep
an
eye
on
that,
but
I
also
relay
it
to
david,
who
is
in
here
just
so
that
he's
aware
of
it
and
b.
Hopefully
he
could.
You
know,
take
on
some
of
that
burden
as
well
for
pac,
and
I
try
to
do
it
for
the
other
platforms.
A
B
All
right,
we
do
have
some
more
time.
If
anybody
has
anything
they'd
like
to
discuss.