►
From YouTube: Working Group: 2021-02-10
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).
C
Oh
yeah,
I'm
aussie.
I
work
for
red
hat
these
days,
I'm
doing
bits
and
pieces
with
with
build
packs,
including
you
know,
a
java
build
pack
client,
I
guess
you'd
call
it
our
platform.
Implementation
and
we've
got
a
bunch
of
teams
that
are
looking
at
using
build
packs
for
our
supported
platforms
for
node
and
java
and
quarkus
and
amongst
other
bits
and
pieces,
and
in
the
past
I've
been
involved
in
projects
like
absolutely
and
odo
and
stuff.
So
I'm
familiar
with
concepts
of
containerized
build
and
that
kind
of
bits
and
pieces.
B
Awesome
great
to
have
you
here,
anybody
else
who
hasn't
been
here
before
want
to
say
hi.
A
Hi
brian
I'm
I
work
with
google.
I
work
with
a
maintainer
of
scaffold
and
on
the
cheese
people
tax
and
I've
been
meaning
to
come
to
these
meetings
and,
finally,
I've
freed
up
some
time
to
be
able
to
show.
D
B
Awesome
great
to
have
you
here
as
well,
unless
there's
anybody
else
we'll
move
on
to
the
next
item,
which
is
release,
planning
and
updates,
I
guess
emily
or
javier.
You
want
to
take
this.
E
There
are
no
updates
for
pac,
as
of
yet
on
techton,
starting
to
work
on
a
monthly
cadence.
So
there's
a
couple
tasks
and
a
pipeline
coming
up
by
the
end
of
february.
So
there's
a
milestone
set
up
for
that.
B
Awesome
unless
there's
anything
else,
do
any
updates
on
distribution
or
registry.
Anything
else.
B
Awesome,
it's
gotta,
look
pretty
all
right,
so
we'll
jump
right
into
reviewing
outstanding
rfcs.
Give
me
one
second
to
share
my.
B
B
All
right,
everybody
see
that
cool
first
thing
on
the
list
is
pac
command
to
create
build
pack
repo.
Where
are
we
with
this
one.
B
Yeah,
it
looks
pretty
good.
Can
this
enter
fcp.
A
I
was
reading
it
right
now,
so
you
can
move
to
fcp
and
a
vote
will
come.
Simultaneous,
that's
good.
B
Sounds
great
so
I'll
just
make
a
note.
Fcp.
B
Cool
and
next
on
the
list
move
analyze
phase
before
detect.
This
is
nfcp.
Someone
just
need
to
merge
this
20
days
ago.
Yep.
This
looks
ready
to
go
thanks
for
ben.
I
guess
to
merge.
B
D
What
I
got
out
of
it
was
the
things
that
I
want
to
make
sure
weren't
going
to
be
a
problem,
aren't
going
to
be
a
problem
so.
B
Okay
sounds
good
to
move
forward
next
thing
on
the
list
is
group
additions
to
builder
order.
A
I
I'm
plus
one
moving
that
to
fcp
unless
phantom
jacks
now
go
ahead
and
go
to
fcp
I'll
comment
in
fcp.
If
it's
necessary,
that's
good.
B
G
B
A
Yeah
star
hit
you
a
little
bit
just
jump
the
line,
because
this
will
just
take
a
second,
hopefully
natalie,
and
I
are
my
name's
sam
by
the
way
I'm
a
product
designer
that's
working
on
the
cmb
research
and
natalie,
and
I
are
pretty
close
to
moving
into
the
usability
testing
phase
or
we
want
to
like
work
with
a
couple
real
developers
to
watch
them
succeed
or
struggle
with
customizing
a
build
using
build
packs
and
so
right
now.
A
The
way
that
we're
approaching
it
is
is
around
taking
a
docker
file
and
then
trying
to
replicate
that
with
build
packs.
But
I
know
that
we
also
have
a
couple
new
kind
of
features
or
abstractions.
The
pack
build
pack
new
and
inline
build
packs,
which
are
both
really
exciting
and
speak
to
a
bright
future
for
customization.
A
F
F
So
I
don't
know
what
kind
of
time
frame
you're
looking
at,
but
if
you're
willing
to
take
like
a
preview
version
of
pac
or
something
like
that,
it
could
be
available
pretty
quickly
for
inline
build
packs.
The
specification
was
was
decided
on
and
I
well
in
the
rfc,
I'm
not
sure
if
I
actually
included
it
in
the
in
the
extension
yeah.
I
think.
D
F
So,
but
if
you
want
to
test
it,
I
could
probably
create
a
build
pack
that,
like
emulated
the
behavior
that
we
want
very
quickly.
So
that's
I'd
be
willing
to
do
that.
If
it's
something
you,
if
you
want
to
try
it
that
way,
I
mean
the
only
reason
we
avoided
implementation
was
we're
just
waiting
for
some
other
things
like
life
cycle
prepare
and
stuff.
F
So,
if
you're
interested
in
having
like,
if
you
don't,
if
you
don't
think
it
would
compromise
what
you're
trying
to
test
you
could
have
users,
add
an
inline,
build
pack
build
pack
and
get
this
working.
A
Okay,
cool
yeah.
I
think
that
would
be
great,
both
an
early
cut
of
pack.
That
includes
pack
build
pack
new.
I
mean
you
tell
me
natalie
if
I'm
wrong
here,
but
or
or
a
a
sample
build
pack
that
would
be
edited
in
a
manner
similar
to
how
inline
build
package
will
be
edited
both
of
those
sound
great.
They
might
fit
into
the
scenario
that
we
have
that
are
sort
of
our
working
scenario
we
want
to
test,
or
they
might
sort
of
be
an
add-on
to
that.
A
A
Okay,
when
do
you
think
would
be
in
terms
of
the
amount
of
time
you
I'll
pay
you
on
the
on
slack.
F
B
Is
it
great
to
have
product
design
resources
allocated
to
our
open
source
efforts
here?
Next
in
the
list
is
stack
packs.
F
Yeah
I
put
this
on
there
because
ozzie
and
I
were
chatting
about
it,
so
I
don't
know
if
you
would
just
like
to
share
the
kind
of
things
we
were
talking
about
with
regard
to
rpms,
but
I
think
it'd
be
great.
Just
to
you
know,
make
sure
we're
aligned
with
what
you
need.
C
Oh
yeah,
so
from
a
red
hat
point
of
view,
let's
say
we're
looking
at
using
these
build
packs
so
that
we
can
produce
images
that
would
be
supportable
and
that
leads
to
certain
requirements
from
our
business
that
the
resulting
application
has
to
run
on
a
base
image.
That
is
one
of
a
select
number
that
we
claim
we
support
on
and
that
the
runtime
that
the
application
is
running
on
top
of
it,
the
node
go
or
java.
C
Whatever
else
is
the
red
hat,
supported
runtime
and
then
you
get
to
the
fun
part,
which
is
the
red
hat.
Runtime
has
to
be
installed
onto
that
base
image
somehow
and
because
red
hat
is
red:
hat
they're
using
rpms
to
do
that
installation
and
rpms
install
at
the
operating
system
level.
So,
as
we've
found
at
the
moment,
if
we
try
putting
up
together
a
common
builder
image
that
has
build
packs,
you
know
a
bit
like
pequito's
got
with
their
their
layers.
C
Then
the
build
pack
becomes
the
part
that
would
need
to
install
the
rpm,
and
it
can't
do
that.
So
this
starts
falling
apart.
We've
had
some
groups
try
and
take
apart,
rpms
and
install
it
into
directories,
but
then
they
find
that
the
binaries
inside
the
rpms
are
hard-coded
with
paths
to
where
they
expect
it
to
be
placed
because
they
were
rpms
after
all,
so
yeah
we're
also
chasing
down
internally
to
see
if
we
can
get
those
groups
to
agree
to
tarball
type
distributions.
C
But
then
that
means
we've
got
to
get
them
to
agree
to
support
those.
So
then
we
find
the
rfc
that's
talking
about
stack
packs
and,
of
course,
that
looks
like
it
will
solve
a
great
deal
of
our
issues,
because
if
we
can
run
as
a
stack
pack,
an
installer
that
will
run
the
rpms
for
the
selected
build
packs,
then
we're
kind
of
halfway
there
right,
because
we
can
start
with
an
empty
base
image
and
we
can
apply
the
rpms
we
need
from
each
build
pack
so
that
that
part
works
out.
C
The
the
part
that's
kind
of
a
bolt
onto
this
I
see
is
the
next
agenda.
Thingy,
underneath
it
which
is
kind
of
tied
together,
is
we're
not
clear
at
this
point.
C
A
B
Yeah,
so
that
the
stackpack
rfc
does
specify
a
way
for
extending
run
images.
It's
it's
not
very
simple.
It
requires
running
another
container
to
install
packages
on
top
of
run
images.
You
know
moving
stackpack
logic
onto
or
I
forget
exactly
how
we
move
the
stackpack
logic
onto
that
image,
but
but
it
would
allow
you
to
install
rpms
into
you
know
a
unified
runtime
based
image.
Does
that?
C
I
I
saw
that,
as
in
I
saw
the
fact
that
a
stack
pack
seems
to
be
capable
from
the
build
pack
side
of
things,
to
specify
that
the
build
pack
can
run.
Rpms
essentially
could
could,
for
our
case,
install
the
rpms,
and
there
was
a
layer
that
said
that
those
same
things
would
then
get
involved
in
customizing
the
run
image
so
that
they
could
run
rpms
against
a
base
run
image
as
well,
and
I
think
that's
the
part.
C
I've
got
to
chase
and
go
back
with
to
figure
out
whether
our
support
teams
would
be
happy
supporting
applications
that
ran
on
top
of
a
base
image
that
had
been
had
the
runtimes
installed
through
rpms
versus
the
model
today,
where
they
install
they
support
an
application.
That's
running
on
a
particular
run
image
where
that's
already
been
done
in
the
background
again,
this
is
not
technical
side
of
stuff.
This
is
political
side
of
stuff
for
the
support
arguments.
F
Yeah,
if
you're
already
maintaining
the
set
of
base
images
that
like
ubi
node
or
you
know
that
have
the
rpms
pre-installed,
the
plan
that
we
have
in
the
rfc
does
allow
for
you
to
have
like
build
packs
that
define
a
stack
they
depend
on.
That
has
mixins,
which
are
essentially
the
the
rpms,
and
then
I
think
I've
got
this
right.
Please
grab
it
if
I'm
wrong,
but
like
the
sort
of
selection
process
for
determining
the
stack,
would
incorporate
that
and
and
pick
the
right
base
image
as
long
as
they
were
tagged
correctly.
D
I
think
the
difference
between
what
we
have
now,
what
you're,
just
describing
joe,
is
that
we,
basically,
in
a
builder,
only
have
a
single
run
image
that
can
be
our
destination
like
we
can
have
mirrors,
but
they're
just
supposed
to
be
more
locations
to
find
the
same
image
so
that
you
can
avoid
copying
layers
between
repository
machine
registries.
So.
F
D
You'd
end
up
like
making
like
a
node
builder,
and
you
know
one
builder
for
each
runtime,
which
probably
isn't
what
you
want.
C
D
I
do
think
it
would
be
cool
if
a
builder
could
specify
multiple
run
images
that
all
have
the
same
stack,
maybe
different
sets
of
mixes,
and
we
could
find
the
one,
the
smallest
one
that
satisfies
all
of
the
requirements.
I
can
think
of
like
a
couple
cases
where
that
would
be
useful,
even
when
you're
not
talking
about
installing
the
runtime
on
the
stack
image.
B
I
think
it's
a
lot
more
complexity
than
what
you're
asking
for,
which
is
just
the
same,
build
time
image
right,
maybe
extended
with
stack
packs
during
build
time,
but
then
some
dynamicness
on
which
run
image
gets
chosen
so
that
you
don't
have
to
dynamically,
extend
the
run
image.
Do
you
need
that
stack
pack
functionality
on
the
build
image?
If
you
have
that
dynamic
run
image
selection,
could
you
just
throw
everything
on
to
that?
One
giant.
C
Image
because
it's
just
real
time
yeah,
we
discussed
that
earlier
today
and
that's
one
of
our
backup
plans
is
to
go
with
an
incredibly
big
fat,
build
image,
but
then
override
the
run
image
for
each,
which
is
less
than
ideal,
because
you're
going
to
end
up
with
a
multi
gigabyte
builder
image.
Now
maybe
you're
only
going
to
get
that
down
once
in
theory,
but
then
the
problem
happens.
Then
every
time
we
ship
any
update
to
any
other
run
times
involved.
B
B
C
C
Either
but
I'd
have
to
get
the
support
guys
to
agree
that
they'd
support
the
model
where
we
modify
the
run
image
and
then
put
the
app
on
top.
That
should
be
okay,
touchwood.
You
know,
because
it's
the
sort
of
thing
that
a
customer
could
do
if
they
weren't
running
in
a
container
and
would
still
support
them
in
that
environment.
B
B
If
we
had
the
ability
to
select
the
run
image,
I'm
curious
how
you
you
would
imagine
that
selection
process-
maybe
this
is
getting
into
the
second
the
item
below
it,
but
how
you'd
imagine
that
selection
process
taking
place
given
that
we
have
in
the
build
configuration,
is
a
kind
of
nested
grid
right
where
it
kind
of
expands
out
into
you
know
a
lot
of
like
a
giant
two
by
two
grid
of
all
the
different.
B
You
know:
options
for
you,
know
combinations
of
modular,
build
packs
where
what
what
component
would
express
would
the
user
would
it
be?
The
person
who
creates
the
builder
would
express
you
know
for
different
groups
configurations.
What
run
image
got
you
know
should
be
used
in
the
end.
Would
this
be
something
that
build
pack
needs
to
express
and
then
gets
overwritten.
C
I
mean
if
I
was
doing
this
I'll
put
it
at
the
build
pack
level,
because
then
it
would
be
like
the
node
build
pack,
the
detect
would
run
the
detect
would
say
hey.
Yes,
this
is
a
node
project.
Therefore
I
will
look
at
the
supplied
list
of
ram
run
images
that
would
be
passed
to
the
builder
as
an
argument
or
something
equivalent,
and
then
it
would
basically
veto
all
the
run
images
that
wouldn't
be
suitable.
B
So
then,
then,
if
you
have
10
build
packs,
acting
in
concert
in
a
group
which
one
which
one
wins.
C
D
C
C
D
So
you
could
find
the
set
that's
going
to
run
and
then
find
the
smallest
image
that
has
everything
they
require.
This
actually
wouldn't
be
very
hard,
except
it
fights
with
the
stackpack
proposal,
which
wants
us
to
figure
out
what
all
the
mixes
that
are
gonna
be
available
are
up
front
to
provide
them
to
the
bill
pack
like
we
just
reordered
this
in
a
rfc
to
make
it
impossible,
even
though
it's
not.
A
B
I
would
also
challenge
the
having
each
individual
build
pack
express,
exact
image
location.
You
know,
I
think
that
works
for
a
lot
of
use.
Cases
that
are
you
know,
maybe
very
distributed
or
like
purpose-built,
build
packs,
but
a
lot
of
people
who
use
build
packs
might
want
to
relocate
all
the
images
they're
going
to
use
into
their
own
registry
and
suddenly
now
you
have
registry
references
that
are
pointing
in
the
wrong
place
right,
and
so
we
had
to
deal
with.
C
That's
why
I
figured
you'd
pass.
The
list
of
you
know
currently
still
living
run
images
to
the
bill
packs
when
you're
running
the
detect
phase,
because
then
it
yeah
each
build
pack
then
sees
the
stuff
that's
available.
So
the
platform
can
pass
that
whilst
it's
running
because
the
platform
will
know
which
run
images
are
available
for
a
given
builder
and
when
it's
invoking
each
build
pack,
it
could
tell
the
bill
pack.
C
C
That's
better
sorry,
paul's
coming
in
from
random
places
yeah.
So
then,
if
you
have
the
the
builder
images,
knowing
that,
so,
if
you
have
a
build
pack
within
running
knowing
which
images
are
available,
then
it's
up
to
it
to
figure
out.
You
know
if
image
one's
called
node,
something
or
other
an
image.
Two
is
called
java
dash,
something
rather
and
I'm
in
node
build
pack
I'll
just
veto
the
java
image,
and
that
means
that
the
next
build
pack
that
runs
will
only
see
a
node
image
because
the
java
one's
gone
away.
C
If
you're
trying
to
build
a
node
java
combined
project.
Now
you
can't
build
it
anymore,
because
your
build
packs,
don't
let
you
so,
but
on
the
other
hand,
you
could
decide
that
you
could
allow
them
to
happen.
If
you
don't
have
the
daft
restrictions
that
require
you
to
run
on
such
a
supportive
platform.
At
the
end.
B
C
I'm
never
going
to
have
a
build
pack
suggest
an
image
location,
I'm
going
to
have
the
build
packs,
be
told
which
run
images
are
currently
available
so
like
today
your
build
pack
is
running
and
there's
only
one
run
image
yeah,
so
it'll
get
past
that
one
run
image
and
say
you're
going
to
be
running
against
this.
The
bill
pack
doesn't
specify
it.
C
It's
told
that
that's
the
metadata
that's
currently
available
for
this
builder
effectively
you're
modifying
the
list
of
available
run
images
that
would
be
would
have
been
specified
on
the
builder
image,
but
only
by
reducing
the
set.
Never
by
adding
to
it.
So
the
builder
creator
is
still
in
control
of
the
absolute
set.
The
image.
E
C
It's
there's
arguably
less
to
deal
with
if
it's
done
through
mix-ins
as
well,
because
you
don't
end
up
with
hockey
bits
of
code
trying
to
figure
out
from
a
run
image
name
what
the
dependencies
are
and
what
it
actually
depends
upon
inside
the
image,
because
the
mixins
express
would
explicitly
define
the
the
parts
that
they
cared
about.
So
if
you
ended
up
with
a
run
image
that
could
support
node
and
java
together,
it
would
tolerate
both.
E
D
B
D
B
D
Do
it
without
the
stackpack
contract,
in
terms
of
like
how
buildbacks
can
already
statically
require
make
sense
right?
So
the
fact
that
a
build
pack
group
detected
the
set
of
mixins
they
require
would
have
to
match
one
of
the
round
images
like
you
know,
we
need
to
put
it
in
the
build
plan,
although
we
want
to
enable
that
to
happen
dynamically
as
well.
C
B
B
We
would
try
to
match
the
resolve
that
the
dynamically
generated
and
statically
generated,
mix
and
requirements
into
the
run
image
list
to
try
to
select
a
run
image,
select
the
best
candidate
run
image,
and
then,
if
there's
a
stack
pack
that
can
install
additional
packages,
pass
the
remaining
mixes
onto
the
stack
pack
so
that
you
get
you
get
the
best
candidate
image
with
the
most
possible
makes
sense,
and
you
get
the
stackpack
installing
mixins.
On
top
of
that,
something
something
like
that.
C
A
B
If
you're
interested
in
you
know
opening
an
rfc
contributing
here
that
that
seems
like
it
would
go
pretty
well,
it
would
be
non-breaking,
I'm
kind
of
surprised.
We
ended
up
with
something
that
fits
in
so
well.
E
A
I
have
an
additional
use
case
that
this
might
play
into
and
it
has
to
do
with
almost
like
a
cross-platform
compilation.
E
So
if
you
think
of
one
of
the
things
that
we
did
for
a
prototype
for
arm
building,
is
we
had
the
build
packs
running
in
x86,
basically
building
everything,
but
using
go
to
compile
it
over
to
an
arm
binary?
E
And
so
I'm
wondering
if
this
could
somehow
you
know
tie
into
that
where
basically,
the
run
image
is
now
an
arm
specific
run.
Image
that
the
go
build
pack
would
say:
okay,
I'm
you
know
being
told
to
compile
this
for
arm.
So,
therefore,
I'm
going
to
select
this
front
image
and
again
all
based
on
make
sense
right
and
the
mix
could
be
arbitrary,
like
platform.
E
E
B
Image
just
back
on
that
architecture,
specific
thing
cross-compiling,
you
know
two
arm
from
x86
is,
is
pretty
common
or
like
I,
I
think
I
see
that
more
than
cross
compiling
stuff
on
arm
for
arm.
You
know,
even
if
it's
not
super
safe,
you
know
as
long
as
the
layers
you're
generating
are
all
built
to
run
an
arm
and
we're
exporting
it
for
arm,
and
the
build
pack
is,
you
know,
has
that
contract
right
where
it
says?
Yes,
this
is
definitely
what
I'm
going
to
expect
to
do.
C
So
it
might
be
handy
for
power,
pc
and
system
390
chipsets
yeah
cpus
there
they're
quite
common
in
my
world
as
well,
so.
D
A
B
It
could
be,
you
know
we,
you
could
have
a
stack
id.
That
literally
means
you
know,
build
pack
expects
to
run
on
the
on
an
x86
image
and,
or
you
know,
and
then
build
stuff
for
an
arm
image
so
that
the
pack
has
to
explicitly
say
I
support
the
stack
id
in
order
for
it
to
you
know.
Do
it
to
give
you
that
opt-in
contract,
I
think
we
already
have
that
that
capability.
B
But
I'm
not
sure
if
we
need
the
soul,
dynamic
selection
of
run
images
to
support
the
functionality,
given
that
it's
so
build
pack
specific.
If
that
makes
sense
it's
like
is
there
it
seems
similar
in
that
we're
exporting
to
it.
You
know
for
a
different
kind
of
run
image
that
we
built
on,
but
I'm
not
I'm
not
sure.
If
the
mixing
contract
is.
B
Yeah,
you
know
javier,
were
you
thinking
of
something
I
guess
more
specific,
around
cross
compilation
for
for
selecting
like
where
you
might
want
that
to
be
decided,
dynamically.
E
I
think
we
didn't
find
a
like
a
really
neat
way
of
doing
it
with
the
current
structure,
and
so
I
was
thinking
of
this
as
a
very
specific
way
of
of
solving
that
issue
right.
Otherwise,
like
I
don't
like
the
way
we
ended
up
solving,
it
is
having
a
whole
different
stack
right
like
a
whole
different
builder
that
had
two
different,
like
a
different
run
image
and
a
different
build
image
on
different
architectures.
E
B
I
wonder
if
that,
because
this
doesn't
feel
like
you
know,
our
arm
doesn't
feel
like
a
mix
in
right
like
mixing
is
like
something
on
top
of
you
know
it's
like
extra
packages
or
it
doesn't
affect
the
base
contract
right,
but
a
wholly
different
run.
Image
is
a
really
different
contract
right.
So
I
wonder
if,
along.
B
B
B
You
know
a
selection
of
different
stack,
ids
and
then
those
stack
ids
can
even
be
sorted
into.
It
can
be
stack
id
and
then
run
images
and
stack
id
and
run
images
and
that's
how
the
run
images
get
fed
through
and
evaluated
along
the
mix,
sense
or
something.
E
D
I'll
go
through
all
the
way,
but
I
wonder
if,
at
a
certain
point,
if
we
enable
this
functionality
like
we
can
support
multiple
run
images.
Multiple
stack
ids,
like
is
the
stack
id
abstraction
breaking
down.
Do
we
just
want
to
use
more
primitive
concepts
like
the
architecture
and
the
operating
system
and
the
operating
system
disk
draw
the
only
thing
that
I
think
doesn't
fit
nicely.
D
B
At
this
point,
the
stack
id
we
had
a
rsc
a
while
ago
that
kind
of
standardized
the
stack
ids
towards
distribution.
So
at
this
point
the
stack
id
represents
the
you
know,
essentially,
distribution
in
its
abi
compatibility
contract.
Like
you
know,
ubuntu,
1804
or
ubi8
or
whatever
right.
Then
it
represents
the
architecture
at
the
same
time
right
and
it
represents.
B
I
guess
that's
it
right.
Instead
of
bundling.
D
B
Some
flexibility,
that's
missing,
there
is
with
the
stack
id
you
can
say
yeah,
you
know
technically
this
was
ubuntu
1804
or
whatever,
and
then
I
made
all
these
weird
changes
to
it
and
I'm
just
gonna,
you
know
call
this
a
new
thing
right
that,
maybe
wouldn't
you
know,
could
fit
into
that
distribution
field,
but
have
to
think
about
what
those
use
cases
look
like,
but.
F
In
the
in
the
interest
of
time,
I'd
like
to
request
that
we
move
ahead.
If
that's
okay,.
A
I
added
this
so
last
thursday
in
the
implementation
implementation
subsync
meeting,
we
had
a
discussion
that
we
thought
we
should
bring
to
this
forum
a
little
background.
So
then,
I
implemented
a
new
feature
that
will
be
introduced
in
buildback
api,
zero
06.
A
We
were
wondering
whether
what
we
should
do
in
case
that
an
old
build
pack
that
supports
like
an
old
buildback
api
adds
the
default
equals
true
line.
We
decided
in
this
case
we
should
just
ignore
it
and
print
a
warning
to
the
user,
but
this
is
like
an
example
for
a
broader
question
about
bill
packs
that
kind
of
implements
new
features,
although
they're
using
old
apis.
A
We
think
that
we
should
always
ignore
the
feature.
The
new
feature
that
is
not
supported
in
their
buildback
api
and
sometimes
depends
on
the
case.
We
should
also
print
a
warning
like
in
our
case,
but
we
would
love
to
hear
others
thoughts
about
this.
D
D
I
do
because
failing
is
a
is
a
behavior
change
like
you
had
a
build
pack
that
was
working
and
then
somebody
upgraded
the
life
cycle,
and
now
your
bill
pack
isn't
working
anymore.
A
Do
do
we
not
validate
the
schema.
D
B
I
I
don't
understand
how
would
upgrading
your
life
cycle
to
a
version
that
now
supports
an
additional?
You
know.
Like
another
point,
you
know
another
minor
on
the
bill
pack.
Api
contract
then
change
the
behavior
of
that
build
pack.
If
the
build
pack
is
still
on
the
old
miner
of
that
contract-
and
you
know
like
feels
like.
A
I
think
there's
an
edge
case
even
more
like
if
you
happen
to
use
this
true
flag
or
default
thing
in
your
when
you're
writing
out
that
tamil
file,
but
it
was
never
supported
before
right
and,
like
I
only
just
said,
we
aren't
failing
for
the
cases
before
because
we're
not
about
in
the
schema.
So
if
it
happens
to
be
there-
and
we
now
implement
that
feature,
potentially
your
behavior
will
now
change.
B
A
Guess
the
question
is:
do
you
warn
because
clearly
they
wrote
default
equals
true,
which
was
not
supported
before
so
you
kind
of
expect
them
to
want
to
have
that
behavior.
So
writing
out
a
warning
lets
them
know.
They've
made
a
mistake
on
their
bill
pack,
api
version
but
ignoring
it
feels
better
to
me
completely.
B
A
We
ignore
it,
it's,
I
think
those
family
just
told
me
yeah,
okay,
so
we
are
thinking
about.
I
mean
continue
to
ignore
it.
Even
we
upgrade
our
lifecycle
version,
but
in
this
case
we
thought
that
it
will
be
better
to
also
print
a
warning
to
the
user,
that
I
mean
pay
attention
you're
using
an
old
buildback
api.
This
is
why
we're
not
supporting
this
default
equals
true,
but
I
I
wonder
if
it's
worth
printing
a
warning
for
anything
that
isn't
specked
like
instead
of
the
default
thing
in
general.
A
Otherwise,
you
need
to
have
four
knowledge
of
future
things.
Future.
D
I
agree
with
that
like
if
we
go
back
in
time
and
make
that
change.
I
wonder
if
we
should
even
fail
in
that
case,
rather
than
warn
like
I
feel
like
failing
might
be
better
if
we're
going
to
go
as
far
as
printing
and
warning
anyways,
but
that
would
be
a
change
we'd
only
make
for
new
apis.
B
Is
that
I
mean,
if
we're
you
know
using
struck
marshalling
everywhere?
Is
that,
like
an
annoying
implementation
thing
to
try
to
figure
out
if
there
are
extra
things,
it
was
a
reason
why
we
didn't
make
the
decision
to
fail?
Initially,
I
guess
it's
really.
My
question
wasn't
just
that:
it's
not
the
most
fun
thing
to
validate.
E
E
But
I
mean
I
put
in
my
vote
for
warning
right
because
I
think
people,
especially
as
as
we
think
about
like
we
don't
maintain
different
versions
of
the
docs
most
of
the
time,
and
so,
if
you
have
a
you're
looking
at
a
new
version
of
the
dock
and
you're,
putting
that
into
a
build
pack
that
you
have
pre-existing
like
this
default
flag
and
nothing
happens
right.
I
think
it'd
be
nice
to
at
least
have
that
verbatim.
D
I
think
we
should
do
that
when
we
release
a
new
api,
but
an
older
buildback
is
using
the
version
and
they
were
on
a
version
of
the
api
that
didn't
fail
for
unknown
fields.
I
think,
like
a
new
api
should
fail
for
unknown
fields,
because
people
might
not
look
at
the
logs
in
that
much
detail
when
they're
testing
and
releasing
fill
packs
and
an
error
will
get
people's
attention.
A
So
you
suggesting
basically
point
we're
on
bill
paco6.
Is
that
right?
That's
what
this
is
in
to
warn
and
then
on
seven.
D
E
Ben's
got
a
couple
comments
that
he's
chosen
to
voice
via
chat,
which
I
agree
with
as
well.
E
I
think
strictness
is
a
little
bit
harsh
at
times
and
I
think
it
could
bite
us
in
the
long
term.
B
I
think,
as
long
as
the
big
danger
I
see
is,
if
we
completely
ignore
you
know
fields
that
you're
setting,
and
there
are
cases
where
you
think
you
set
some
field,
but
you
misspelled
it
and
we
don't
say
anything
and
you
know
set
the
other
result.
You
know
as
long
as
that
doesn't
as
long
as
we're
warning
or
failing
or
something
I'm
okay
with
it.
E
I
do
recall
someone
suggesting
that
we
actually
have
schema
like
an
actual
schema
for
all
of
our
tamil
files
and
then
that
would
enable
even
better
validation
than
the
serialization.
D
G
G
G
That
was
one
of
the
major
discussion
points
that
was
on
here.
We
also
accepted
a
lot
of
the
feedback
around
like
allowing
files
for
cserts
or
your
or
urls,
and
the
other
big
thing
was
the
stack
metadata.
G
Emily
made
a
comment
around
whether
we
should
allow
this
information
to
be
specified
separately
for
each
image,
which
I
guess
we're
a
little
bit
indifferent
on
not
really
sure
there,
but
we
left
it
at
the
top
level
as
something
that
would
get
applied
to
both
images.
For
now,
and
we
also
changed
around
the
interface
for
stack
by
itself,
a
tiny
bit.
G
There
was
some
there
the
sense
that
some
of
these
flags
were
a
little
bit
unclear.
So
we
went
with
base
image
and
destination,
and
then
you
can.
You
would
pat
instead
of
passing
an
image
type
and
then,
like
passing
the
string
builder
on
you
could
just
either
pass
dash,
build
or
dash
dash,
run
and
finally,
there's
another
comment
around
like
pack
stack
create
should
be
able
to
handle
either.
G
You
know
one
or
both
of
the
two
images,
and
so,
if
you
only
wanted
to
modify
one
image,
you
could
only
do
one
of
them
and
that,
coupled
with
emily's
comment
that
maybe
we
should
pass
these
in
as
flags
rather
than
in
the
config
file,
to
standardize
with,
I
think,
the
create
builder
interface
and
create
build
package
or
something
or
package
bill
pack.
G
So
we
accepted
that
and
then
in
that
case
you
would
either
pass
one
or
both
of
these
things,
depending
on
both
of
these
flags,
depending
on
which
images
you
wanted
to
customize
yeah.
E
D
E
A
G
So,
right
now,
on
day,
one
of
this
being
out,
we
were
envisioning
this
working
only
for
the
one
stack
id,
that's
supported
by
the
project.
The
bionic
stack.
C
G
So
it
would
only
work
on
ubuntu,
bionic
images,
but
the
hope
would
be
in
the
future
to
work
with
more
base
images.
Essentially-
and
I
guess,
even
on
day
one
if
you
passed
a
different
stack
id,
but
the
base
image
was
still
ubuntu
bionic
based.
We
would,
you
know,
default
to
checking
what's
in
seo,
os
release
and
like
if
it's
bionic
will
install
packages
regardless
of
your
stack
id,
but
in
the
future,
expand
that
to
allow
installing
packages
with
other
types
of.
B
Os's
wonder
if
you
could
express
the
stack
specific
logic
using
stack
packs
somehow
in
the
future,
like
modularized
the
components
that
know
how
to
install
packages
and
things
like
that
on
top
of
the
stackpack
api.
But
I
don't
I
mean
certainly
not
for
this
rfc.
Just
like
you
know,
it
seems
like
a
place
where
we
need
modular
functionality
for
installing
packages
and
we're
doing
that
over
in
a
clean
place.
Right
definitely.
A
Is
adding
support
for
red
hat
stuff,
something
that
or
rpm
something
that
red
hat
would
want
to
contribute
upstream
to
this.
A
G
B
Ozzy,
would
you
have
contacts
on
that?
I
don't
know
if
you're,
maybe
already
cool.
E
Yeah
and
again,
it
feels
like
something
that
could
be
easily
added
right.
You
could
pass
in
your
eyes
on
the
packages,
add
uris
to
rpms
potentially
and
get
them
installed.
That
way.
G
G
G
Cool
well,
if
there's
no
other
comments,
I
guess
yeah
just
waiting
for
a
resolution,
a
bunch
of
the
conversations
in
the
actual
rc
and
then
yeah
just
for
views.
B
You're
open
for
approval
now
or
ready
ready
for
people
to
start
giving
thumbs
up
thumbs
down.
B
B
Kind
of
seems
like
no
in
that
case,
we'll
skip
over
that
one
for
now
and
go
to
new
contributor.
B
Awesome,
congratulations,
and
that
is
the
last
thing
we
got
we'll
make
sure
injecting
runtime
environment
variables
makes
it
onto
the
agenda
for
tomorrow
forever,
for
whoever
put
that
on
the
list.