►
From YouTube: CNB Weekly Working Group: 2022-01-06
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
I
see
we're
recording
there
we
go
there's
the
live
stream.
Thanks,
don't
forget
to
sign
into
the
document,
looks
like
most
folks
haven't
any
new
faces.
B
B
Nothing
for
implementation
here.
A
All
right,
the
the
only
agenda
item
we
had
from
the
sync
yesterday
was
to
talk
about
the
pac
tunnel
proposal,
the
build
pack
config
proposal,
how
they
relate
to
project
descriptor
in
that
kind
of
general
discussion.
I
think
javier
and
I
have
kind
of
gone
back
and
forth
on
this
a
bit,
but
we
probably
need
to
refresh
since
the
break.
So
I'm
not
really
sure
where
to
start
that
discussion,
and
it
probably
is
one
that
could
go
on
for
a
long
time.
A
A
A
For
what
I
was
calling
a
special
case
of
project
tamil,
in
which
the
everything
under
the
I
o
dot
build
packs
name,
space
would
be
used
in
a
pack
tombl
file.
That
would
also
have
things
that
configuration
that
was
specific
to
pac
and
I
think
the
the
goal
there
was
like
to
enable
parity
in
the
pack
options
like
things
like
dash,
dash,
publish
or
other
any
flag
that
you
might
add
on
the
command
line
to
pack
build
that
it
could
have
an
analog
in
a
descriptor
file.
A
And
I
think
in
the
past
that's
been
difficult
or
not
possible,
because
there
are
things
about.
Those
options
that
are
unique
to
pac,
like
publish,
might
be
a
good
example.
Not
every
platform's
potentially
going
to
have
that
or
maybe
maybe
publishers
isn't
great.
A
So
when
we
talk
about
marketing,
you
know
you
know
the
the
marketing
aspect
of
having
a
file
in
your
repository.
That
indicates
this
project
can
be
built
with
pac.
I
feel
like
a
pack.
Tommle
does
a
pretty
good
job
of
that.
It's
not,
you
know,
meant
to
be
cross-platform,
but
that's
sort
of
that's
the
stance.
A
I'm
taking
the
other
proposal
was
build
packs
config
from
javier,
which
I
think
is
a
meant
to
be
just
just
jump
in
and
correct
me
if
I'm
saying
this
wrong
javier,
but
meant
to
be
a
a
descriptor
that
would
be
build
pack
like
generic,
build
packs
and
all
platforms
would
and
could
support
it.
I
think
you
may
even
say
that,
like
if
you
can't,
if
something
is
provided
in
this
configuration-
and
you
can't
support
it,
then
the
build
would
have
to
fail.
C
I
think
at
minimum
warn
right.
That
was
the
real
requirement,
but
yeah
other
than
that.
I
think
everything
else
is
accurate.
A
So
yeah,
so
that's
probably
a
good
place
to
start
discussion
I
feel,
like
I
mean
my
stance
is
definitely
that,
like.
A
Aiming
for
something
that
can
be
supported
across
all
platforms
feels
ambitious,
and
I
I
guess
like
limiting
like.
I
worry
that
there
there
are
aspects
of
the
pack
like
like
the
pack,
the
cli
user
experience
in
in
in
terms
of
the
flags
that
you
would
provide
and
how
you
might
serialize
those
into
configuration
file
that
we
might
compromise
on.
If
we
were
to,
if
we
were
aiming
for
something
that
was
more
generic,
and
so
that's
where
that's
why
I
was
favoring.
The
pack
tunnel.
C
Yeah
and
I'm
trying
to
recall
as
well
where,
where
we
left
off-
and
I
think
I
have
a
pretty
good
idea,
but
I
want
to
add
to
this-
you
know
kind
of
context,
and
and
maybe
do
it
in
the
form
of
a
question
where
we
have
the
project
descriptor
and
then
the
pac
tumble
right.
I
guess
I
would
ask
what
are
options
that
go
in
project
descriptor
as
opposed
to
things
that
go
into
pak
tummle
or
does
pak
tamil,
replace
altogether
project
descriptor.
A
Actually
in
in
my
proposal,
I
talked
just
a
little
bit
about
how
they
could
co-exist
and
because,
because
paktamo
would
be
like
a
special
case
of
project
tamil,
we
could
actually
have
like
an
order
of
precedence
where
it's
like
project
tamil
and
then
pakhtaml
takes
precedence
and
then
anything
you
provide
on
the
command
line
takes
precedence
over
either
of
those
so
yeah.
I
was
imagining
that,
like
project
toml
would
be
the
place
where
you
would
put
things
that
are.
A
C
C
Are
there
certain
options
that
we
know
cut
across
all
platforms,
because,
ultimately,
that's
my
concern
right
is
that
on
a
project
descriptor,
if
I
take
it
from
platform
a
to
platform
b,
and
I
have
certain
options
set
if
the
platform
doesn't
know
or
doesn't
have
sort
of
a
conventional
recommendation
that
it
should
warn
or
air
out
when
those
options
are
present,
then
the
ending
result
from
a
user's
perspective
could
be
wildly
different
across
different
platforms,
and
I
think
that's
an
experience.
I
you
know
we've
seen
for
one
and
something
I'd
like
to
mediate.
A
A
It
feels
like
not
a
great
experience
to
me
because
we're
saying
that
this
descriptor,
you
know,
has
a
an
element
that
is
builder
and
you
can
configure
your
builder,
but
really
you
can't
and
you're
in
a
sense
lying,
and
I
mean
in
terms
of
the
pack
descriptor
I
I
you
know,
I
just
did
like
a
pack
help
and
pack
build
help
and,
like
literally
every
one
of
these
I
feel
like
could
or
should
be.
A
You
should
be
able
to
serialize
them
into
a
just
descriptor,
so
you
don't
have
to
add
them
every
time
or
you
don't.
You
know
you
can
ensure
that
whoever's
running
pack
build
against
your
repo
will
get
the
same
result.
Kind
of
thing.
C
Yeah
and
I
I
definitely
don't
question
and
and
have
no
real
push
back
on
the
pack
tamil
piece,
it's
really
the
project
descriptor
right,
like
I
asked
the
question
of
what
is
the
project
descriptor,
if,
like
you
said,
we
can't
come
to
a
consensus
on
what
the
finite
finite
properties
should
be
that
go
into
that
file.
That
then,
are
really
truly
cross-platform
right
and
I
guess
I
would
throw
in
the
proposal
that
maybe
we
shouldn't
have
that
right,
like
maybe
those
things
don't
exist
and
really
everything
is
platform
specific,
that's.
A
A
C
Yeah,
I
mean,
I
think
my
last
thought
process
was
what,
if,
in
the
project
descriptor,
we
did
still
have
the
I
o
book
packs
namespace,
but
at
the
top
level
it
there's
not
really
anything
to
configure
the
build
itself
per
se,
but
more
or
less
platform
specific.
What
is
it
called?
Platform-Specific
configuration-
and
I
think
sam
might
have
brought
this
idea
up
where
that
platform-specific.
C
It
configuration
obviously
be
different
between
pack
and
there's
another
section
for
kpac.
So
then
you
could
configure.
You
know
each
individual
platform,
all
within
one
descriptor,
without
having
any
real
overlap
and
then
allowing
the
platforms
to
select
and
choose
their
configuration
and
use
that.
C
Yeah-
and
I
think
that's
one
of
the
things
where,
at
least
from
my
proposal,
it's
a
step
back
and
saying
like
hey,
I
don't
want
to
create
a
new
file
right
or
or
restructure
the
existing
file.
I
think
reverse
domain
names
still
would
work,
I'm
convinced
of
that
now,
but
yeah.
I
think
the
part
where
I
still
have
a
lot
of
hesitancy
and
reservation
is
trying
to
create
like
a
centralized
set
of
configuration
that
not
all
platforms
are
going
to
respect.
E
I
remember
whenever,
in
the
past,
we've
talked
about
like
platform,
specific
configuration
was
this
just
like
project
specific
configuration?
The
point
has
come
up
that
as
a
user
like
there
are
things
that
you
think
are
like
part
of
the
entire
application
configuration
you
don't
care
about,
whether
that's
being
executed
by
a
build
pack
or
the
platform,
and
I
I
think
that's
why
we
didn't
want
like
separate
sections
for
like
the
like.
E
Okay,
this
functionality
is
controlled
by
a
platform,
so
it
goes
under
a
different
table
and
this
functionality
is
controlled
by
like
a
build
pack
or
something
that's
universally
applicable
to
all
platforms.
It
goes
under
a
different
table
and
so
on
at
the
the
other
idea
I
had
was
so
it's
it's
largely
inspired
by
how
pip
defaults
to
different
backends.
E
So
you
can
specify
that
hey.
This
is
this.
Is
the
binary
or
this
is
the
back
end
I'll,
be
using
to
parse
this
file
and
like
select
or
apply
configuration
from
it
and
the
platform
just
being
able
to
say
that?
Okay,
I
know
how
to
fetch
this
back
in
this
build
or
project
descriptor,
parser
back
and
parse
things
and
then
get
things
out.
E
So
that
way,
like
each
platform
could
have
like
an
allow
list
of
build
back-ends
it
supports.
So
if
for
pack
it
can
be
like
packed
since
it's
pretty
flexible,
it
can
be
like.
I
support
all
project,
descriptor
back-ends
and
obviously
it
it's
pretty
complicated,
because
now
you
introduce
this.
Another
piece
of
technology
which
is
pluggable
like
you'll,
have
to
figure
out
how
different
organizations
like
there's
a
sales
force
or
heroku
project
descriptor
back-end
that
supports
certain
properties.
E
A
C
Transforming
part
of
I'm
a
little
bit
curious
about,
because
I
think
last
time
we
had
this
conversation
sam,
correct
me
if
I'm
wrong,
but
it
wasn't
so
much
that
we
ended
up
finding
out
that
there
was
no
need
to
do
the
transform
itself,
since
it
would
most
likely
do
the
applying
of
the
configuration,
as
opposed
to
like
nothing
else,
wants
to
read
it
afterwards.
Right.
E
C
Is
there
a
need
to
do
that?
If
I
guess
maybe
an
alternative
right
is
if
we
simply
had
because
no
matter
what
I
envision,
that
whatever
the
quote-unquote
back
end,
is
right,
we're
going
to
still
run
into
the
same
struggle
where
I
select
the
back
end
and
let's
say
that
the
backend
is
not
supported
by
kpac
right
like
it
says.
No,
I
don't
want
to
use
that
or
I
can't
use
that
for
whatever
reason
right
like
I
feel
like
we
run
into
the
exact
same
thing.
C
So
what
if
you
know
still
leaning
on
that,
but
we
say:
okay,
every
platform
has
its
own
set
of
configuration
right
and
then
they're
still
able
to
replace
that
functionality.
That
piece
of
function
that
parses
that
that
set
right
like
I
think
we
called
it,
the
preparer
phase
or
whatever
right
the
prepare
phase
is
swappable
right.
So
the
k-pack
preparer
phase
could
be
very
different
from
the
pack
preparer
phase
and
and
so
forth.
So
every
prof
platform
could
have
its
preparer
phase,
which
looks
for
its
specific
configuration.
C
E
E
C
The
so
I'm
going
to
go
back
to
a
simplistic
solution
right,
my
simplistic
idea
of
multiple
configurations
with
different
preparers
that
could
all
apply
their
set
of
configuration
separately
and
I
think,
maybe
trying
to
to
adhere
to
some
of
the
things
that
might
look
good,
where
you
have
a
central
set
of
configuration
that
could
apply
to
multiple
platforms.
Right,
I
think,
like
include
exclude
right.
C
That
would
be
nice
if
pack
and
kpac
and
techton
all
applied
the
same
include
exclude
type
stuff
and
you
didn't
have
to
specify
it
multiple
times
in
in
all
these
separate
configurations.
So
I
think
that
could
easily
be
resolved
by
something
like
defaults
right,
so
maybe
at
the
top
level,
instead
of
calling
it.
You
know
things
that
are
required
by
prop
by
platforms,
it's
more
of
like
defaults
that
are
applied
and
overlaid
to
the
individual
platform
configurations.
C
And
if
we
wanted
to
right
hypothetically,
we
could
only
talk
about
defaults
for
the
most
part,
but
then
say:
oh
now,
you
could
override
it.
If
you
want
to
change
the
behavior
4k
pack,
whatever
that
may
look
like
the
we
could,
you
know
obviously
dive
into
the
overlaying
aspect
of
it.
But
that's
something
I
think
might
work.
B
Yeah,
I'm
kind
of
with
you,
javier,
I
think,
having
consistent
builds
through
multiple
platforms.
Is
it's
pretty
much
a
pipe
dream
once
things
get
complicated
like?
I
think
you
know
right
now.
If
you
build
something
in
pack
and
then
build
something
on
a
platform,
there's
a
good
chance,
there's
like
an
environment
variable
that
is
on
the
platform
that
isn't
being
provided.
B
When
you
do
a
pack
build
right
like
there's
just
they
could
be
running
a
completely
different
platform
version
right,
because
that
has
to
be
explicitly
defined
on
the
platform
than
it
does
and
like
pack
pack
runs
its
own
platform
version.
I
don't
know
I
feel
like
this.
Drift
is
not
gonna
like
go
away
or
resolve
itself,
so
I'm
not
sure
I
feel
too
strongly.
B
You
know
about
introducing
things
that
would
make
that
gap
any
any
different
like
I,
I
don't
think
we're
gonna.
I
don't
know
I
don't.
I
don't
see
that
being
enough.
No
problem.
C
Yeah
I
mean
I,
I
want
to
be
clear
that
I
think
the
reason
why
I
brought
this
up
is
to
try
to
to
minimize
that
gap
right,
especially
when
we
talk
about
us
having
a
project
descriptor
things
that
we,
you
know
start
throwing
into
our
documentation
and
and
say
we
support.
But
then
you
you
throw
it
onto
certain
platforms,
and
you
end
up
essentially
not
knowing
that
the
what
you
expected
to
happen
happens
right,
and
you
end
up
with
two
very
different
images:
the
different
platforms
and
stuff.
Like
that.
I
could
see
them.
C
D
D
C
I
guess
I
would
ask
the
question
of
like
if
we
had
separate
files,
then
what's
the
point
of
project
descriptor,
but
I
will
say
that
everything
that
I've
stated
thus
far
doesn't
necessarily
mean
that
pac
tumble
cannot
be
a
thing
right,
like
basically
pack
tamil
could
in
one
way
or
another
by
pack
itself
be
merged
into
this
project.
Descriptor.
A
It's
for
platforms
that
support
project
descriptor,
to
use
it
for
other
things,
and
a
really
good
example
of
this
would
be
like
salesforce
functions,
having
an
event
type
and
that
event
type
actually
influencing
like
the
build
packs
you
use
or
something
like
that,
and
what
it
allows
us
to
do
is
have
a
configuration
that
can
actually
apply
to
salesforce
functions
as
well
as
other
salesforce
products,
and
do
it
in
a
uniform
way
and
in
a
way
that
doesn't
require
having
you
know,
three
or
four
different
config
files
for
all
these
things
that
are
part
of
the
same
project.
A
So
even
if
even
if
project
descriptor
doesn't
support
every
build
pack
feature
on
the
under
the
sun,
I
think
it
still
has
a
lot
of
value,
certainly
to
salesforce
as
a
subset
of
build
pack
configuration
and
and
and
right
now
I
mean-
I
think
our
stance
is
that
we're
aiming
at
a
subset,
that
is
that
platforms
are
able
to
support
across
the
board.
C
I
mean
I
say,
like
it
becomes
very
difficult
to
try
to
promote
anything
from
a
platform.
Specific
thing,
like
mistake
builder,
for
example,
and
move
it
to
a
now
quote-unquote
mandated
option
right
because
we
don't
have
that
control,
and
maybe
we
don't
want
that
sort
of
enforcement.
On
the
platform
side
of
things.
D
A
A
Unless
I
mean,
unless
we
have
a
really
good
plan
for
how
you
advertise
what
features
you
support
or
what
keys
you
do
or
don't
support,
I
feel
like
at
that
point.
It
becomes
really
difficult
to
know
that
a
like,
so
you're
using
pac.
You
write
that
build
pack
descriptor,
that's
supposed
to
work
on
all
platforms,
but
you
don't
really
know,
and
I'm
not
sure
you
really
have
a
way
to
validate
that
it
would
so
it's
a
totally
reasonable,
like
congestion
as
a
mechanism,
but
I
think
I
worry
about
the
experience
you
know.
E
C
E
Yeah
and
asd
prepare
phase
could
say
which
platforms
it's
compatible
with.
I
don't
know,
or
vice
versa,
so
the
the
prepared
face
says:
hey,
I'm
compatible
with
takedown
and
back
so
they
don't
once.
It
follows
that
platform
api
which
supports
this
prepared
phase
in
the
future.
You
can
say:
okay,
this.
This
looks
like
I'm
compatible
with
it
I'll,
try
running
it
and
it
gets
back
the
output.
It
expects
it.
It's
it's
a
whole
new
api
which
I
think
project
descriptor
already
is
like
we.
E
We
have
the
specification
out
there,
but
we
don't
have
a
good
way
of
saying
that.
Okay,
here's,
how
the
platform
overrides
things
and
in
project
a
like
project,
descriptor,
here's,
how
you
handle
different
versions
of
project
descriptor
with
different
platform
api.
So
all
of
that
is
currently
option.
We
just
have
to
spec.
So
we
need
a
translation
layer
anyway,.
A
I
think
so
maybe
a
good
way
to
move
it
forward
is
to
kind
of
return
to
what.
A
Our
our
customers
are
asking
for
and
see
if
we
can
like
see
if
we
can
keep
what
like
the
kinds
of
things
we're
talking
about,
while
delivering
some
subset
of
that,
or
something
like
that.
That
that
addresses
those
needs
and
the
needs
I
hear
well,
some
of
our
some
of
the
goals
are
our
own,
but
I
hear
people
wanting
to
serialize
pack
flags,
like
that's,
definitely
a
thing
like
I
I'm
providing
this
thing
on
the
command
line.
A
I
want
to
be
able
to
put
it
in
my
my
descriptor
as
well
as
other
things
like
that.
You
know.
The
images
table
is
a
good
example
that,
even
if
it's
a
little
bit
misaligned
with
pac,
another
goal
from
our
end
is
to
have
a
descriptor
that
is
specific
to
us
in
the
in
a
very
generic
sense,
whether
it's
build
packs
or
pack
or
whatever,
something
that
indicates
that
a
project
can
be
built
with
build
packs
or
with
pack.
Those
are
the
two.
A
I
think
the
two
concerns
that
I
think
are
more
immediate
and
and
need
addressing,
and
if
we
can,
if
we
can
address
those
and
not
box
ourselves
out
of
some
of
the
more
I
don't
mean
it's
like
in
a
bad
way,
but
like
elaborate
solutions
like
like
we're,
like,
I
really
like
some
of
the
stuff
that
that
sam
is
talking
about,
and
we
can
always
execute
on
that
later
or
something
I.
C
I
would
like
to
throw
in
a
third
request
from
the
users,
and
that's
the
one
that
I'm
focusing
on
is
having
the
project.
Descriptor,
be
recognized
by
multiple
platforms
or
across
platforms.
E
I
think
that's,
but
I
I
would
second,
that
that's
also
something
our
users
really
like
about
our
platforms
right
now
like
when
they're
testing
things
locally,
they
can
use
back
and
like
have
some
like
the
same
logic
I
spoke
about
earlier,
like
that's.
That's
just
the
main
selling
point
that
like,
even
if
you
want
to
locally
reproduce
those
bills
you
can,
it
may
not
be
an
exact
copy,
but
it's
a
functional
copy
so
like
at
least
functionally
it
would
sort
of
behave.
The
same.
E
A
E
B
A
Yeah
yeah,
you
could
use
both
and
we
have
an
internal
tool
that
uses
both
and
we've
had
a
lot
of
trouble
with
viper.
So
I'm
curious
why
you
brought
that
up,
but.
E
I
was
asking
because
a
lot
of
our
tools
use
viper
in
conjunction
with
cobra,
and
it
makes
it
really
easy
to
have
multiple
configuration
files
at
different
levels
so,
like
you,
can
have
a
global
one
and
a
project
specific
one
like
similar
to
how
git
works,
where,
like
there's
a
system,
user
project,
specific
git,
config
and
it
it
just
works
along
with
specifying
the
same
things
using
command
line,
flags
or
environment
variables.
So,
like
all
of
those
options,
are
consistent
and
abstracted
away
by
wiper.
E
A
C
So
I
missed
a
lot
of
what
was
said
so
I
do
apologize,
but
I
was
going
to
throw
in
that.
If
we
were
to
have
a
pact
tamil
file
at
the
project
level,
then
we
could
very
easily
also
include
that
at
the
kind
of
home
directory
pack
config
and
use
that
as
sort
of
defaults
for
any
project
stuff.
So
we
can
actually
move
away
from
or
or
kind
of
overlay
that
as
well.
A
I
mean
maybe
but
yeah
I'm
not
even
sure,
though
some
of
those
things
I'm
not
even
sure
matter
like
if
we're
really
making
a
pack
specific
thing
do
we
do.
We
want
to
put
those
things
like
version
and
project
name
that
are
in
project
descriptor,
I'm
not
sure
they
belong
in
pack
like
that's,
not
I'm
not
necessarily
sure.
That's
something
that
dude
that
pack
would
ever
care
about
agreed.
B
A
And
if
you
did,
if
you
did
care
like
you
were
like
no,
I
want
pap
to
generate
like
we
don't
do
this
today,
but
I
want
like
the
image
to
default,
to
the
name
of
the
image,
to
default,
to
the
name
of
my
project
and
the
tag
to
default,
to
my
version
or
something
along
those
lines,
then
maybe
that's
where
you
should
be
using
something
like
project
descriptor
and
a
platform
like
you
know,
salesforce
could
default
the
the
image
name
to
the
whatever
project
name
is
under
com.salesforce
or
something
like
that
or
the
tag
could
be
based
on
the
event
type
in
the
salesforce
table.
D
I
feel
like
there's
a
set
of
tables
like
images
or
builder,
and
things
that
I
guess
made
at
sam's.
Point
is
like
somewhat
shared,
but
is
not
necessarily
recognized
by
root
platform
or
would
want
to
be
used
by
a
pre-platform.
D
I
guess
they're
thinking
of
just
like
even
like
builder
right,
like
a
multiple
platform
support
builder.
Obviously
pack
would
support
it
right,
but
are
there
a
share
set
of
like
tables
or
even
like
images
like?
I
can
imagine,
yeah.
A
A
D
Having
a
canonical
like
like
it
like
you're,
saying
javier,
it
would
be
awkward
to
force
this
into
kind
of
the
buildbacks
namespace,
because
not
every
platform
would
support
it.
So
then
you
get
into
that
case
where
it's
just
like.
D
Like
you
know
not
like
a
rare
thing
for
a
platform
to
want
to
support
these
set
of
features,
so
I
I
feel
like
there's,
probably
a
set
of
things,
I'm
sure
if
we
sat
down
and
thought
about
it,
those
are
kind
of
the
two
that
I
thought
off
the
top
of
my
head,
but
I
think
we
were
being
more
probably
thorough
and
complete.
There's
probably
a
set
of
tables
like
those
that
are
probably
common
configuration.
But
it's
not
like
absolute,
like
we
expect
every
platform
to
support
all
these
things.
C
D
D
Wasn't
even
advocating
like
they
should
be
in
kind
of
the
I
o
build
packs
or
whatever,
like
kind
of
default
configuration
I
guess
like
to
some
greedy
knowing
if
people
had
just
different
builder
schemas,
even
if
or
they
have
to
like
figure
out
right
like
I
just
look
at
even
like
the
images
table
kind
of
discussion
like
there's
lots
of
ways
to
slice
that
and
if
we
actually
got
to
a
place
where
we're
happy
with
where
that
is,
it
actually
tackles
a
lot
of
use
cases.
D
D
D
I
don't
know
it's
not
like
a
fully
fleshed
out
thought,
but
I
just
been
thinking
about
some
of
these
things
where,
like
we,
don't
feel
comfortable
kind
of
uplifting
it
into
common
configuration.
That's
that
we
expect
every
platform
require,
but
it
is
probably
somewhat
common
configuration
if
that
makes
sense.
C
Yeah,
I
wonder,
are:
are
you
thinking
about
trying
to
solve
for
defining
types,
essentially
right,
yeah.
D
C
I
don't
know
yeah,
so
I
guess
what
I'm
thinking-
and
maybe
I
heard
joe
say
this-
where
the
rxc
that
that's
currently
out
there
right,
how
it
defines
the
the
kind
of
deconstructed
images
or
image
names,
and
we
would
define
that
if
you
are
describing
an
image.
It
must
be
in
this
format
or
should
be
in
this
format.
Whatever
right.
E
C
D
Yeah
I
mean
that
could
be
an
option.
It
could
just
be
part
of
documentation
under
platform
operator.
Maybe.
B
D
I
don't,
I
don't
think
it
would
be.
I
don't
think
we
wouldn't.
We
would
be
opposed
to
it
to
have
a
winter,
but
I
mean
we
don't
even
do
winter
stuff
for
project
tamil
right,
which
is
specked.
So
there's
an
rvc
for
that.
C
D
I
mean
one
of
the
things
we
could
do.
I
I
guess
onlines
of
what
aiden
is
saying,
is
that,
depending
on
the
kind
of
validate
or
whatever
things
we
could
define
kind
of
like
predefine,
at
least
certain
schema
things
that
they
could
pull
in.
Potentially,
if
someone
wanted
to
build
their
own
validator
based
on
some
of
our
kind
of,
I
guess,
tables.
D
I
don't
like
we
had
to
build.
We
need
to
build
some
of
this
stuff
out
for
salesforce
for
our
project
nominal
table,
so
I
I'm
at
least
aware
of
some
of
that
stuff,
but
that
could
be
potentially
a
way
that,
even
if
it's
not
required
it,
you
at
least
get
there's
at
least
a
small
carrot
at
the
end
of
that
stick
of
just
like.
Oh,
if
you
do
use
this
kind
of
savage
convention,
you
can
kind
of
use
these
primitives
already
for
at
least
getting
validation
stuff
like
that.
C
Yeah
I
know
we've
talked
about
schemas
in
the
past
and
how
that'd
be
great
for
this,
like
I,
I
still
strongly
believe
in
that
I
think
I
might
have
maybe
in
the
next
mentoring
session.
I
might
try
to
throw
that
as
something
people
could
work
on,
but
the
linters
is
definitely
new,
and
so
I'm
thinking
like
that
that
seems
pretty
cool
to
be
able
to
start
inventing
stuff
based
on
those
schemas.
A
Yeah,
so
we
got
five
minutes
left.
I
want
to
make
sure
that
we
come
away
from
this
with
something
that
will
keep
us
moving
forward.
So
if
anybody
has
ideas-
including,
if
you
have
suggestions
for
things
for
me
to
do,
it-
doesn't
have
to
be
something
that
you're
doing
I'd
love
to
hear
it.
We've
got
the
two
proposals
out
there.
A
C
So
I
I
wanted
to
first
confirm
I
added
very
light
notes
on
what
our
goals
are
joe
on
the
document.
Could
we
confirm
that
those
are
accurate
because
I
wrote
them
after
the
five.
C
C
I
know
my
my
goals
are
to
create
yet
another
proposal
based
on
my
my
vision
of
this
and
then
kind
of
you
know
iterate
on
that.
But
I'd
be
happy
to
also
see
other
people's
proposals
and
see
if
we
could
inch
closer
to
some
sort
of
unified.
A
I
mean,
if
you
don't
mind,
starting
that
I
mean
I
think
that's
a
good
or
yeah.
I
think
it's
a
good
place
to
start
and
I'd
be
happy
to
like
review
early
if
you
like,
if
you
want
to
potentially
short
circuit
work
that
you
wouldn't
need
to
do,
or
something
like
that.
So
if
you
want
to
do
it
more
in,
you
know,
with
a
tighter
feedback
loop
than
just
like
submitting
a
full
on
rfc
like
happy
to
do
that
too.
So.
C
Cool
yeah-
I
might
hit
you
up
on
that.
I
might
use
hacker
md
or
hackmd
to
do
that.
A
little
bit
faster,
yeah.
B
E
E
Api
is
a
common
way
to
like
for
all
platforms
to
implement
some
common
functionality,
but
not
in
a
bunch
of
these
options
are
simply
like,
like
they're,
not
transferable,
across
platforms,
because
the
the
api
that
the
lifecycle
provides
is
not
flexible
enough
or
like
for
buildbacks
or
something
else
to
add
those
kind
of
extensions
like
there's
nothing,
stopping
a
buildback
right
now
from
looking
at
the
project,
descriptor
parsing
it
and
adding
processes,
labels,
environment
variables,
whatever
else
but
like
as
soon
as
you
get
into
concepts
like
like
changing
the
builder
or
changing
the
run
image
or
the
output
image
tag.
E
That's
where
it
all
gets
hairy.
So
the
the
other
option
could
simply
be
like
if
we
could
figure
out
like
a
platform
level.
Api
drain
introduce
all
of
these
things
that
that
can
be
controlled
by
an
api.
Like
the
buildback
api,
which
is,
is
more
restricted
so
that,
like
a
platform,
can
choose
that
gives
the
subset
of
functionality
or
things
I
want
to
execute,
and
that
would
also
solve
a
bunch
of
these
problems.
E
So,
like
that's,
that's
one
criteria
you
can
think
of
like
putting
things
in
io
buildbacks
table
like
let's
see
if
a
build
back
into
it.
If
buildback
can
do
it,
then
the
platform
can
obviously
do
that
and
it
has
to
support
it
because
the
buildback
is
already
doing
it,
and
then
that
way,
that's
a
clear
criteria
for
hey.
This
goes
in
the
I
o
buildbacks
table.
This
goes
somewhere
else
and
for
all
of
those
features
we
can
figure
out
like.
B
A
All
right,
I
need
to
drop
yeah,
let's,
let's
keep
it
going.
This
is
a
this
is
a
really
important
topic
to
me
and
I
feel
like
it's
a
nebulous
one
too,
but
let's
just
keep
trying
to
move
things
forward
and
let
me
know
how
I
can
help.