►
From YouTube: Platform Sync: 2021-03-03
Description
Meeting notes: https://bit.ly/38pal2Z
A
All
right,
so,
let's
see
very
first
thing:
we've
recorded
the
meeting
great
status
updates
cool.
I
guess
for
status,
updates
right
now
working
backwards,
going
through
reviewing
some
prs.
I
know
sam
has
added
a
few,
or
at
least
one
that
I
could
recall
joe.
Has
the
new
build
pack
command
that
I
just
added
some
feedback
on
for
acceptance.
A
A
A
A
B
I
guess
I
have
a
first
pass
at
creating
asset
cash
images,
also
kind
of
going
along
with
that
theme
of
cleaning
up
some
of
the
issues
and
pr's.
We
have.
A
Cool
appreciate
it:
tara,
I'm
assuming
you
don't
have
anything
to
add
here.
C
I
don't
think
so.
I
think
the
only
recent
thing
I
did
was
put
in
the
rc
on
projector
stuff,
which
is
about
like
potentially
moving
to
the
reverse
domain
idea
that
we
talked
about.
A
Sounds
good
maybe
we
could
talk
a
little
bit
as
a
precursor
here:
release
planning,
there's
nothing
there,
like,
I
said,
they're
still
we're
still
a
little
bit
stuck
on
techton
side
and
pack,
I
believe,
is
going
to
release
the
17th.
So
we
still
got
a
little
bit
of
time
to
do
that
now
we
might
need
to
look
at
the
milestone
and
see
what
you
know:
how
to
really
prioritize
that
maybe
punt
some
things
out
to
the
next
release
dan
feel
free
to
you
know,
contribute
to
that
I'll.
C
C
Yeah,
I
don't
think
it's
labeled
because
it
hasn't
gone
through
the
wednesday
working
group
shenanigans.
But
do
we
want
to
talk
about
it?
Yeah.
B
C
C
I
feel,
like
my
previous
flexible
project.
Descriptor
rfc
had
the
problem
of
it
felt
very
limiting
for
us,
because
if
we
ever
wanted
to
take
over
other
top
level
keys
like
it
could
break
other
kind
of
folks
who
decide
to
take
advantage
of
that
flexibility.
So
this
allows
us
to
kind
of
live
in
our
own
own
name
space
and
then,
like
here's,
an
example
of
me
just
taking
the
fly
to
io
thing
and
an
example.
You
know.
C
Obviously
they
don't
do
it
like
this,
but
they
could
then
have
their
own
reverse
domain
of
stuff,
where
all
their
fields
would
live
under
there,
and
so
this
also
allows
us
to
then
version
our
own
schema
as
that
changes,
and
so
we
could,
through
the
work
we
have
of
someday,
valuing
the
schemas
we
have.
We
could
have
a
schema
specific
to
the
I
o
bill
pack
space
same
with,
like
any
other
name
space
out
there
as
well.
So
it
could
do
that
and
then
as
a
project.
C
I
guess
we
could
basically
check
for
this
key
to
see
if
they're
doing
like
the
old
style,
slash
new
style
as
we
move
towards
1-0,
but
and
then
I
had
some
other
open
questions
around
whether
project,
I
I
felt
like
projects
should
remain
as
a
thing.
That's
independent,
it
didn't
seem
to
be
a
golf
spat
pack
specific
thing,
especially
related
to
building
the
thing,
and
I
don't,
as
far
as
I
know,
pax
still
doesn't
really
use
anything
in
here.
Right.
A
I
don't,
I
don't
think
so.
If
anything,
maybe
source
url
might
have
been
the
closest,
but
I
don't
think
that
ever
got
implemented.
A
C
Okay,
so
yeah
the
that
was
kind
of
one
of
the
reasons
I
kind
of
kept
it
out,
because
we
aren't
really
using
it
as
a
project,
but
it
exists,
it
seems
to
kind
of
transcend
stuff,
that's
specific
to
builds,
and
then
the
other
question
I
think
that
came
out
last
time
is:
should
this
be
a
table
at
like
this?
C
Where
I
o
is
a
table,
then
bill
pax
is
a
table
or
should
it
be
like
a
quoted
string
or
it's
like
I
don't
know,
packs,
I
think
there's
potentially
some
advantage
for
doing
either
there
but
happy
to
hear
feedback
on
that
interesting
yeah,
that's
the
rfc!
For
that.
A
So
I
I
am
curious,
like
I
honestly
I
guess
I
don't
have
an
opinion
on
whether
it's
a
quoted
string
or
a
nested
table.
A
C
Versus
the
top
level,
I
I
think
there's
so
in
the
spec
changes
section
at
the
bottom.
I
think
there's
actually
two
version
numbers
there.
I
don't
know
if
point
two
is
the
right
one.
Maybe
it
is
point
one,
but
I
think
there's
one
that
is
the
price
descriptor
schema,
which
is
basically
making
the
change
of
like
it's
going
to
reverse
notation,
but
then
I
think
that
should
not
define
necessarily
for
that
schema
like
what
belongs
in
iodopax.
C
I
think
that
there
then
is
a
separate
new
version.
So
main
point
one
is
the
right
number
there.
That
is.
This
is
what
belongs
in
the
bill
backspace,
and
so
my
hope
and
thought
is
that
then
each
kind
of
name,
space
or
verse
domain
thing
can
then
if
they
want
to
have
their
own
version
or
schema.
But
then
the
practice
scripter
basically
backs
out
of
kind
of
what
belongs
in
each
thing,
but
then
kind
of
only
defines
I
think
like
project
and
then
the
fact
that
we
are.
A
A
I
think
so
right
being
this
is
the
second
iteration,
like
I
think,
for
a
platform.
You
know,
I
guess
we
could
kind
of
try
to
parse
it
in
different
ways
and
see
which
one
fits,
but
like
the
pattern
we've
used
for
all
the
other
tamil
files.
Is
we
look
at
that
api
version
and
then
determine
you
know
how
to
parse
it
and
I
think,
that's
easier
for
everybody
to
deal
with
yeah
and
then
on
the
api
inside
of
the
domain
objects.
A
I
guess
that's
optional
right
and
that's
just
a
preference
that
our
project
is
going
with
and
not
something
that
we're
asking
others
to
also
follow.
C
Right
yeah,
like
I
think,
it's
highly
encouraged,
but
yeah
I
can
clarify
that
it
should
be
optional.
The
yeah
I
mean
it.
Obviously
we
will
publish
a
set
of
stuff
that
we
expect
to
be
there
in
our
own
spec
and
what
those
versions
as
we
change
them,
and
hopefully,
if
other
folks
do
do
it
like.
I
know
I'm
talking
internally
in
our
company
at
salesforce.
C
C
The
biggest
con
for
me
is
just
have
verbositis,
but
I
think
it
feels
very
clean
in
comparison.
A
Direction,
cool
all
right
anything
else
on
that
that
one.
A
B
Yeah
I
mean
it
feels
like
this
is
the
place
where
we
should
probably
talk
about
this
before
it
ever
makes
it
to
the
rfc
so
or
makes
it
to
the
like
wider
working
group
meeting.
I
think
there's
been
some
some
changes
and
some
comments
on
this.
I
can
kind
of.
A
So
if
I
recall
correctly,
I
think
emily-
and
I
added
some
comments
around
this,
and
just
you
know
just
I
guess
to
to
add
or
elaborate
on.
It
is
the
way
I
envision
this.
A
It's
like
a
a
promotion
kind
of
strategy
right
where
we
have
a
whole
bunch
of
stuff
in
internal
that
could
probably
be
cleaned
up
and
promoted
into
this
like
package
domain
right
things
that
could
other,
like
programs,
then
incorporate
as
dependencies
and
use
within
their
application
right
and
then,
if,
like
that,
is
phase
one
or
step
one
right
like
I
think,
once
we
see
the
demand
like
you
know,
individual
projects
asking
for
very
specific
things,
then
we
could
put
them
into
this
like
open
public
package
or
pkg
domain
right,
and
then,
if
we
see
that
you
know
a
certain
area
grows
to
a
certain
level
that
requires
its
own
set
of
you
know,
management
or
maintenance.
A
I
think
like
one
of
them
would
be
archive
right
archive
is
something
that
I
think
we've
we've
realized
isn't
specific
enough
for
pac,
but
it's
more
or
less
used
across
multiple
other
things,
or
at
least
we
have
something
very
similar
for
life
cycle
and
image.
Util
then,
maybe
that's
something
that
could
you
know
be
moved
up
or
promoted
into
that
area
right
so
like.
I
think
that
would
be
like
phase
two
right
where
it
becomes
its
own
either
separate
repo
or
it
moves
into
a
whole
different
project.
A
So
that's
that's
one
thought.
The
other
thing
is
as
I'm
writing
the
tecton
task.
A
There's
a
couple
things
like
you
know:
parsing,
environment,
variables
and
stuff
like
that
that
right
now,
I'm
doing
in
bash
that
I
feel
like
I'm
gonna
want
to
put
into
some
like
go
program
right
to
and
then
put
them
into
some
image
so
like
you
could
envision
a
build
packs,
tecton
image
that
has
a
whole
bunch
of
like
little
tiny
utilities
and
then
these
tiny
utilities,
I
think
kind
of
go
back
to
this.
A
Like
idea
of
these
are
common
shared
things
that
we
use
across
maybe
multiple
platforms
and
it
it
would
be
nice
to
again
be
out
able
to
leverage
whether
like
right
now,
I
guess
for
techton.
I
could
import
pac
right,
but
maybe
we
don't
want
to
do
that
and
we
want
a
different
strategy,
but
it
would
be
a
very
good
first
step
for
me
to
be
able
to
import
stuff
from
pac
into
this
techton
utilities
package.
A
At
but
yeah
I
don't
know
exactly
where
we're
wanting
to
end
up
with
this
specific
rfc.
B
B
A
A
I
do
think
that
the
visual
representation
is
helpful,
but
maybe
you
know
either
annotate
that
it's
like
very
abstract,
right
or
maybe
think
about
what
we
want
to
do
for,
like
you
know
the
first
step
right
like
after
we
close
this
rfc.
What
are
we
going
to
do
like
immediately
right
and
then
maybe
some
supporting
you
know
very
future
looking
structure
and
maybe
having
two
right
like
this
is
where
we
want
to
be
right
after
this
rfc-
and
this
is
what
we
can
envision
like
very
long
term-
would
also
help.
C
Anything
else.
First
sorry.
A
Yeah,
I
don't
think
we've
solidified
that
process,
yet
parents,
I'm
not
sure,
exactly
like
we
could
say
that,
but
we're
definitely
trying
to
move
in
that
direction.
B
C
No
yeah
this
one's
great
thanks
for
putting
it
together.
I
I
think
under
the
the
stuff
javier
said,
I
think,
like
maybe
the
how
it
works
section
could
definitely
help
illustrate
like
kind
of
next
step
actions
laid
out
that
way.
A
Cool
and
looking
at
the
rest
of
the
rfcs,
it
looks
like
all
the
other
ones
are
in
fcp,
so
I'm
not
sure
that
they're
worth
discussing
right
now
I
mean
I
think
it's
past
that
point,
so
I
think
we're
done
with
that.
A
Okay,
moving
on
to
another
thing,
discussions
needed
for
pack
issues
share
my
screen:
real
quick.
A
So
maybe
we
could
start
from
the
bottom.
A
B
B
A
B
A
Maybe
for
this
one
we
just
need
a
clarification
of
exactly
what
it
is
that
we
we
need
dan.
It
sounds
like
you
have
a
little
bit
of
knowledge
as
to
what
the
options
are.
Do
you
mind
at
least
adding
those
to
this
issue?
Yep.
A
Okay-
and
we
have
three
minutes
left.
What
is
this
append.cmbp
package
too
fast
created
using
package
build.
A
A
A
So
just
some
background
here
right
so
right
now,
the
source
of
truth
for
what
suggested
builders
are
is
inside
of
pack
right,
and
this
isn't
the
first
time
I
could
think
of
at
least
for
the
tech
time
documentation
where
we
want
to
like,
say
like
hey,
you
know:
what
are
the
possible
options
for
this
builder
parameter,
and
we
say
here
are
some
suggested
ones
right
and
I'm
having
to
like
extract
those
from
pac.
A
C
A
You
know
an
argument
that
could
be
made
as
to
whether
or
not
we
should
be
the
ones
that
dictate
that
notation,
but
we're
already
doing
it.
So
whether
or
not
it's
the
right
thing
to
do,
I
feel
like
we
need
to
solve
that
for
what
we're
currently
doing,
which
is
we're
already
suggesting
builders.
So,
what's
the
difference,
if
we
suggest
the
builders
in
pack
or
if
we
suggest
the
builders
in
you
know
the.
A
C
We're
going
to
be
doing
cb
roadmap
stuff,
so
if
you
want
to
pipe
anything
else
into
that
daniel,
this
would
be
a
good
time.
I
think
we're
meeting
tomorrow.
So,
okay.