►
From YouTube: Office Hours: 2021-07-29
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
B
A
Do
wonder
if
something
similar
to
like
environment
variables
would
work
here
where
the
platform
could
provide
its
set
of
information
right
that
it's
aware
of
into
the
platform
directory
as
part
of
a
file
system
api?
Then
the
lifecycle
reads
from
that.
But
then
build
packs
are
also
able
to
contribute
to
that
and
again,
maybe
tying
it
all
directly
to
s-bomb
format,
but
seems
like
additive
right,
like
everybody
kind
of
wants
to
contribute
their
piece,
and
we
want
to
allow
them
to.
C
C
I
don't
think
the
platform
has
a
way
of
contributing.
It's
only
only
build
packs
right
now
can
contribute
to
s
bomb,
but
we
need
a
way
for
the
base
image
to
specify
its
packages
in
a
label.
That'll
get
right
into
the
s-bomb,
and
so
some
consistent
interface.
There
that's
like
base
image
label,
or
you
know-
or
I
guess,
the
base
image.
A
Thing
yeah
see
I
I
like
that
right
at
first
glance,
that
sounds
really
good.
I
think
that's
sort
of
the
solution
that
I'm
hoping
we
get
as
opposed
to
just
changing
source
into
an
array.
C
Makes
sense,
I
think,
there's
a
question
of
at
what
point
are
we
should
something
communicate
in
cyclone
dx
right
and
I
feel
like
because
the
build
packs
are
going
to
output
cycle
and
dx
and
because
the
base
image
is
going
to
be
labeled
with
cyclone
dx
or
spdx?
I
mean
just
you
know
the
s-bomb
format
right.
The
platform
should
also
probably
contribute
its
things
into
as
spdx,
which
means
pack
should
probably
read
the
app
source
and
convert
that
into
cyclone
and
then
put
that
into
the
extra
platform
s-bomb
contribution
file,
or
something
like
that.
C
B
C
B
C
A
Is
there
a
way
to
capture
that
for
future
work?
Is
that
something
sam
that
we
want
to
incorporate
into
your
current
rfc,
or
I.
B
I
would
I
mean
there
are
a
couple
of
things
right,
so
that
rfc
currently
just
deals
with
buildback
provided
response.
I
think
we
need
like
base
image
as
forms
we
need
platform
provided
as
bombs
here.
I
guess
so.
We
should
probably
have
subsequent
rfcs
that
add
these
files
in
the
current
rfc
is
flexible
enough
to
support
multiple
different
s4
files
from
different
places,
so
should
be
fine.
A
Cool,
so
I
think
I'll
take
an
action
item
then
to
at
least
create
a
rfc
issue
that
specifies
that
we
may
want
to
consider
doing
this
based
off
of
the
rfc
that
you're
currently
working.
A
B
I
had
one
question:
I
don't
know
if
it
came
up
in
the
platform
thing,
but
we're
moving
to
that
the
project
descriptor
over
to
spec
right
and
I
guess
what
happens
if
you
want
compatibility
with
both
of
those
versions
as
an
app
developer.
B
So,
let's
say
you're
again:
this
is
like
an
app
developer
facing
breaking
change,
so
it
impacts
lots
of
applications
that
are
out
of
the
operator's
control.
You
can't
just
update
the
lifecycle
and
buildbacks
and
be
done
with
it,
and
applications
are
also
used
in
different
platforms.
B
So,
in
terms
of
backwards
compatibility,
I
also
meant
backwards
compatibility,
not
just
in
back
but
probably
across
different
platforms.
So
what
happens
if
both
one
and
auto
versions
are
there
is
that
supported?
Is
that
something
we
plan
on
supporting
in
the
meanwhile,
while
other
platforms
get
their
versions
up
to
date?
And
if
not,
that's
gonna
be
an
issue
where
people
will
just
stick
201
for
better
platform
compatibility
until
people
move
over,
which
means
they'll
not
get
a
bunch
of
new
features.
A
So
I
could
speak
to
what
I
do
know
from
pak's
side.
I
think
the
heroku
intern,
I
believe,
yosef
he's
currently
working
on
the
backwards
compatibility,
support
and
implementing
the
new
version.
A
Four
pack
so
from
pax
perspective,
we'll
have
support
for
both
and
it
you
know,
there'll
be
no,
no
actual
breaking
there,
for
I
guess
future
thinking
solutions.
I
know
emily
brought
up
the
idea
of
creating
some
sort
of
mechanism
that
converts
the
project
descriptor
into
a
platform.
Api,
specific
format
that
that
way,
then
the
platforms
don't
have
to
worry
about,
and
only
keep
that
in
mind.
A
I
don't
know
exactly
where
she
is
with
that
she
seemed
very
passionate
about
it,
but
I
don't
know
if
her
availability
availability
is
there.
B
Sorry
by
both
you
mean,
if
both
the
versions
are
there
in
project
descriptor,
it
will
be
able
to
parse,
then
how
will
it
be
able
to
parse
both
of
them?
So
it's
it's
not
just
that.
There's
one
application
with
v1
one
with
v2.
What
happens
if
there's
an
application
with
both
of
them
are
because
you
want
local
testing
with
pac,
for
example,
and
then
remote
builds
with
kpac.
B
A
I
see
that
I
don't
know
if
we
should
support
that
that
functionality
I
mean
that's
my
opinion.
Right,
like
the
complexity,
doesn't
seem
worth
it.
I
feel
like
they
should
just
either
either
they're
going
v2
all
the
way
or
they're
not,
but
I
get
where
you're
coming
from
I'm
just
trying
to
figure
out
exactly
whether
it's
worth
it.
B
So
there
is
a
precedence
there
right
because
technically
you
can,
you
can
have
both
of
those
things
in
your
project.
Descriptor,
there's
nothing
stopping
you
from
doing
that
right.
We
should
clarify
the
precedence
and
that's
sort
of
the
backwards
compatibility
questions.
I
had
around
that
pull
request
and
I
wanted
clarification
on
the
issue.
It's
not.
C
B
B
How
can
you
pick
one
over
the
other
and
then,
if
those
tables
have
different
information,
that's
going
to
cause
other
issues
for
app
developers
just
feels
very
messy,
because
we
didn't
have
a
unique
api
version
field
on
the
top,
and
then
we
moved.
A
So,
okay,
I
see
what
you're
saying
so
basically
like.
If
I
remember
correctly,
the
solution
that
yosef
was
currently
working
on
was,
if
there's
an
underscore
dot
schema
version,
then
he
would
pull
that
schema
version
and
if
it
says
0.02,
then
it's
0.02
right,
oh
that's
or
whatever
the
hell
is
yeah,
so
that
would
be
the
check
the
first
check
and
then,
if
it's
not
there,
then
it
would
fall
back
to
the
unversion
version
right.
You,
oh,
that
one.
B
C
Yeah
as
part
of
the
problem
here
that,
if
you
bump
something
in
project
tamil
to
0.2
and
the
platform,
is
at
0.1,
it's
not
compatible.
I
feel
like
we're
going
to
keep
hitting
compatibility
problems
until
we
we're
willing
to
say
it's
1
0,
and
that
a
thing
that
is
marked
one
point
like
a
platform
at
one
1.0
should
be
compatible
with
a
project
homolet
or
a
the
platform.
At
one
point,
one
should
be
compatible
with
the
project.
C
B
Just
the
first
time
this
is
an
app
facing
api
like
app
developer,
facing
api
version.
So
it's
it's
impacting
people
more.
They
can't
just
make
transparent
changes
in
the
background
and
the
app
developer
will
get
the
latest
thing
that
that
doesn't
happen.
So
it's
a
that's.
Why
I'm
more
concerned
about
it
than
the
other
ones.
A
B
B
D
There's
there's
no
explicit
dependency
right.
You
can
use
project
tom
all
to
set
environment
variables
right,
but
the
explicit
dependency
is
environment
variables.
So
it's
a
loose
coupling
but
you'll
see
lots
of
examples
of
us
using
project
tomml
but
yeah.
There's
no
explicit
dependency
on
project
tunnel.
Okay,.
A
A
B
D
I
mean,
I
would
say
the
kettle
probably
doesn't
have
a
preference,
like
our
thing
is
environment
variables
getting
set,
and
some
folks
are
going
to
want
to
do
that
like
dynamically.
At
the
platform
level
like
in
some
sort
of
platform,
configuration
file
declare
what
the
environment
variables
are
for
that
particular
build
and
other
folks
are
going
to
want
to
do
stuff
like
bake
it
into
the
source
code,
using
something
like
a
project
descriptor
but
like
we
don't
really
care.
Ultimately,
where
that
comes.
B
A
Yeah
I
mean
it
is
unfortunate.
I
guess
maybe
I'm
trying
to
understand.
Do
you
think
if,
if
we
had
emily's
solution
of
where
you
could
specify
any
format
and
then
based
on
the
platform
api,
the
platform
has
a
higher
guarantee
of
support.
A
Then
it
wouldn't
be
a
problem
right,
but
still
you
can't
have
a
mixed
match
of
a
file
that
contains
both
formats
right,
like
you
still
have
to
pick
one
it's
just
now.
You
might
go
to
documentation
for
let's
say
pokado
and
they're
still
using
the
schema
one
version,
but
then
you
go
somewhere
else
and
they're
using
a
schema.
Two
version,
the
I
mean
this
isn't
uncommon
from
an
app
developer's
perspective.
They
just
have
to
know
how
to
migrate
from
one
to
the
other.
B
B
A
A
I
guess
I'm
not
to
maybe
double
on
on
steven's
point.
I
think
a
little
bit
of
breakage
seems
fine
at
this
point
in
time.
A
We
do
apologize
sam
that
you
have
to
go
through
it,
but
we're
not
sure
how
how
big
of
an
ecosystem
breaking
change
this
actually
is
and
then
and
then
yeah
trying
to
get
emily's
proposal
implemented,
would
probably
be
the
best
solution.
Long
term.
A
So
I
could
yeah
I
could
hit
her
up
on
that
and
see.
If
there's
anything,
we
can
do
to
get
some
more
traction.
There.