►
From YouTube: Working Group: 2021-03-25
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
There
we
are-
and
we
are
done
with
the
first
item.
Let's
see
I
do
want
to
maybe
give
some
time
for
other
people
to
join
in
later
to
discuss
some
of
the
topics
below.
I
think
the
first
one
standardizing
artifact
names.
B
I
mean
we
recently
had
a
twitter
thread
around,
like
buildback
naming
and,
like
name
spacing,
if
you
remember
correctly
like
there
was
some
thread
where,
like
people
were
confused,
whether
the
buildbacks
required
by
the
registry
need
to
have
a
namespace
or
not,
and
I
noticed
that
in
the
spec
or
anywhere
else,
we
don't
really
mention
like
a
standard
way
of
naming
and
even
on
the
documentation.
B
Some
of
the
build
packs
were
previously
named,
like
com
dot
like
io
dot,
build
packs,
something
which
are
not
name
spaced,
no,
not
name
spaced.
In
a
way,
that's
that
works
with
the
registry.
So
let's
say
you
were
following
that
tutorial
and
you
created
like
that,
has
now
been
fixed.
But
previously,
if
you
were
following
the
tutorial
until
you
did
back
register,
you
would
not
know
that
your
build
pack
is
actually
not
following
some
naming
conventions
said
by
the
registry,
and
then
we
sort
of
now
have
these
two
kind
of
naming
standards.
B
One
is
the
reverse
domain
specification
and
the
other
one
is
like
build
packs
where
you
have
a
namespace,
slash
the
the
name
of
the
buildback,
which
is
sort
of
confusing
like
we.
We
have
two
different
sort
of
ways
of
name
spacing
because,
essentially
with
the
reverse
domain
naming
convention,
you
could
still
name
space
in
in
in
some
way.
So.
B
It's
just
confusing
to
me
that
house,
stacks
builders
or
like
well
packs
should
be
named
or
like
what
what
should
be
their
naming
convention.
I
guess
for
builders,
it's
sort
of
said,
because
it
has
to
be
a
oci
image.
So
it
has
to
look
like
something
that
can
be
published
to
an
oc
registry,
but
for
something
like
stacks
or
like
build
packs.
B
A
Cool
that
that
makes
a
lot
of
sense.
Okay.
So
so,
when
we're
talking
about
stacks
right,
we're
not
talking
about
the
like
the
image
names
for
the
images
that
compose
a
stack
right,
we're
talking
about
the
stack
id
yeah.
Let's
see
like.
I
definitely
agree
that
there's
some
sort
of
confusion,
and
I
want
to
maybe
like
inject
the
context
of
like
the
historical
conversation
of
what
came
to
be
the
registry
name
spacing
and
if
I
recall
correctly
as
part
of
that
rfc,
the
discussion
did
come
up
about.
A
You
know
whether
or
not
that
name
spacing
concept
should
be
enforced
on
the
build
pack
id
level
right
on
the
build
packs
versus,
as
opposed
to
just
being
a
registry
specific
format
requirement,
and
at
that
point
in
time
I
think
the
decision
was
made
for
it
to
be
just
a
registry
specific
right.
So
I
think
you
know
to
your
point,
like
maybe
like
there's,
definitely
some
confusion
that
grew
out
of
that
and
maybe
there's
a
disservice,
that's
being
done
there.
A
So
there's
that.
I
am
curious,
though,
about
the
reverse
domain.
A
Ultimately,
the
way
I
see
the
spec
currently
formulated,
it
has
like
no,
no
enforcement
of
that
that
I
could
really
recall
right,
like
it
doesn't
care
what
you
name
it,
and
it's
just
the
registry
itself
that
says.
Oh,
if
you
want
to
put
it
into
the
registry,
then
it
has
to
follow
this
id
structure
or
format
which
includes
any
spacing.
A
Does
that
coincide
with
your
understanding
as
well.
C
D
I
remember
we
just
didn't.
We
also
didn't
want
to
invalidate
the
existing
build
packs
that
are
out
there
like.
If
you
never
work
with
the
registry,
I
think
we
didn't
want
to
basically
force
people
down
a
path.
D
I
think
the
assumption
was
kind
of
going
forward.
Most
people
prob,
ideally
if
we're
successful
with
the
registry
like
we'll,
want
to
put
stuff
into
the
registry
and
probably
will
kind
of
fall
on
the
design.
I
think
there
was
opportunities
or
opportunities.
B
Potentially,
the
the
only
thing
is
that
I
still
think
it's
valuable
to
have
like
some
convention
like,
for
example,
python
has
like
pepe,
which
includes
some
naming
conventions
which
are
not
enforced,
but
there's
still
a
good
guideline
for
new
users,
so
they
like
it's
not
necessary
for
them
to
follow
it,
but
it
still
like
sort
of
makes
sense
to
everyone
else
like
what
they
should
do,
so
that
I
guess
later
on.
B
D
I'm,
for
I
mean
I'm
for
having
guidelines
there.
I
think
initially,
we
just
didn't
want
it
in
the
spec
per
se
to
say
like
you're
now,
bill
pack
is
now
an
invalid
bill
pack,
just
on
name.
D
A
A
D
Sam's
comment
is
that
their
guidelines
right
and
not
necessary
requirements
are
enforced
right,
but
the
benefit
of
a
guideline
is
that
it
means
most
people
probably
will
follow
the
guideline
and
it
will
take
that
shape,
even
if
at
the
kind
of
life
cycle
or
kind
of
spec
level
like
we
won't,
we
won't
like
refuse
to
run
your
build
pack
because
it
doesn't
follow
the
guideline
right,
but
instead
we
just
have
documentation
that
more.
E
D
D
To
even
more
than
just
naming
right
like
in
the
future,
too,.
B
Yeah
I
mean
in
general,
there
are,
I
guess,
things
which
are
not
enforced
by
the
life
cycle
or
a
platform
or
a
spec,
but
you
still
don't
want
users
to
do
to
to
prevent
them
from
like
a
foot
gun
or
something
like
that.
Like
you
know,
some
things
work
with
with
the
api,
but
you're
likely
to
do
it
incorrectly
or
cause
problems
for
yourself
in
the
future.
If
you
do
certain
things
so
like
another
thing
that
we
talked
about
yesterday
in
the
last
meeting,
was
that
build
packs
could
technically
modify
each
other's
layers.
B
So
I
guess
there
is
the
spec
and
there
is
like
some
sort
of
guidelines
which
are
good
to
follow,
which
may
not
be
enforced
but
they're
there
just
to
help
you
not
to
miss
like
not
commit
mistakes
or
put
yourself
in
a
hole
in
the
future,
or
something
like
that.
A
Yeah
that
definitely
makes
sense.
Do
we
have
any
idea
on
where
these
guidelines
would
live.
D
Voting
team
somewhere
will
be
my
default
response
because
I
feel
like
you,
do,
want
them
separate
from
the
spec
right.
A
D
D
A
We'll
we'll
have
them
recorded
in
this
video
right
and
you
just
point
them
to
this
point
in
time
in
the
youtube
or
we
say
that
that's
a
guideline,
oh
just
kidding,
cool
all
right
I'll
I'll,
definitely
add
some
notes
about
that
in
the
meeting
notes.
A
A
B
Should
the
process
of
creating
guidelines
be
an
rfc
so
that
others
can
pitch
in
like
what
should
go
in
there
or
like
how
we
should
organize
this
and
what
should
be
the
process
of
adding
new
guidelines
in
the.
D
D
Sure,
I
think
that's
fine.
I
do
think
potentially
that
potent
even
fits
under
like
a
sub
team
rc
that
probably
belongs
in
our
learning.
That
doesn't
necessarily
need
votes
from
everyone
in
the
core
team.
But
that's
my
opinion
on
that.
A
A
All
right,
moving
on
to
alternatives
for
process,
environment
variables,.
B
Yeah,
this
also
came
out
of,
like
a
convo,
a
conversation
on
a
per
request
with
the
paquito
folks
that,
let
me
just
pull
up
the
request.
Actually.
B
B
So
this
was
the
full
request
and
the
essentially
the
issue
that
was
there
with
the
keto
maintainers
were
that
in
order
to
set
environment
variables
for
a
process
which,
like
currently,
you
can
define
a
process
without
associating
it
to
a
layer.
But
if
you
want
to
set
environment
variables
for
it,
you
have
to
create
a
specific
layer
for
it
which,
like
semantically,
a
process
may
like
you,
could
have
processes
that
are
not
associated
with
one
specific
layer.
B
So
now
you
have
to
create
a
layer
just
for
that
process
and
its
environment
variables,
and
the
alternative
that
we
were
thinking
of
was
just
to
include
it
in
the
launch
chamber
and
launch
domino
under
the
process
key
and
just
follow
like
the
with
the
environment,
sort
of
format
where
you
have
the
name
and
dot
append
or
dylan
and
the
values.
B
But
I
guess
the
downside
is
that
we
now
have
a
fourth
way
of
specifying
environment
variables.
But
essentially
the
issue
was
that
currently
it's
a
bit
clumsy
to
specify
processes,
but
in
the
launch
terminal,
but
not
there
and
for
their
environment
variables
to
create
like
there
or
associate
those
things
with
a
specific
layer.
B
It's
I
don't
think
it's
about
like
not
the
inability
to
do
something.
It's
just
that
it
looks.
It
is
a
bit
clumsy
in
the
way
how
it's
currently
done.
A
C
B
The
the
proposal
is
just
to
decouple
setting
environment
variables
for
a
specific
process
from
a
specific
layer.
So
currently,
processors
are
not
tied
to
a
layer
like
the
definition
is
not
tied
to
a
layer
but
setting
environment
layers.
Sorry
setting
environment
variables
for
them
is.
A
E
It
makes
sense
to
be
I'd,
be
interested
in
seeing
an
rfc
that
goes
over
this
in
details,
because
I
think
there
will
be
some
with
the
whole
process
overriding
and
things
like
that.
It
gets
a
bit
complicated
because
if
you
do
put
them
in
like
the
process
launch
table
like
I'm,
not
sure
what
that's
going
to
look
like
when
further
buildbacks
can,
you
know,
contribute
and
modify
the
the
the
process.
But
I
think
I
think
it
makes
sense
to
explore.
D
Yeah
I
feel
like
this
came
up
in
the
original
spec
design.
I
feel
like
I
actually
raised
this
issue,
but
I
think
the
work
around
of
just
creating
a
layer
to
do
it
was
fine
at
the
time
just
like
write
a
layer,
that's
specific
to
doing
that
for
the
process
for
now,
and
then
we
kind
of
having
never
kind
of
looped
back
around
on
it.
E
I
think
some
of
the
I
think
I
remember
some
of
that
discussion
is
because
now
you
sort
of
have
to
decide
whether
you're
going
to
reimplement
like
override
and
append,
and
things
like
that.
Yeah
another
format,
that's
not
file
based,
and
so
it
makes
things
you
know
it's
just
another
way
of
doing
in
bars
and
at
the
time
it
was
blocking
process
specific
and
vars.
Just
as
a
you
know,
implementation
at
all
so.
A
I'm
adding
some
notes
about
this
real,
quick,
so
yeah.
I
think
we're
on
the
same
page
right
like
it
makes
a
lot
of
sense
to
add
it,
but
there's
a
couple
things
that
we
need
to
iron
out,
and
most
of
that
would
probably
be
things
that
we'd
want
to
discuss
during
rfc
process
just
so
that
we
make
sure
that
we
think
of
everything
like
presidents
and
implementation
details.
A
C
A
That
yeah
that
definitely
makes
sense
anything
else
to
discuss
here.
Sam
I
mean
do
you
feel
comfortable
with
with
the
answer
that
basically,
an
rfc
would
be
best
for
this.
C
B
There's
no
like
there's
no
issue
with
creating
a
layer
for
for
setting
environment
variables.
I
don't.
I
don't
think
that
would
cause
any
issues.
It's
just
like
semantically
processes
are
not
currently
associated
with
their
some
properties
of
them
are
so
that
was
the
only
thing
it's
got.
It's
got
nothing
to
do
with.
What
can
you
cannot
be.
C
A
Yeah
that
definitely
makes
sense,
and
you
know
I
think,
maybe
like
a
lot
of
things
depending
on
how
much
desire
there
really
is
for
this
sort
of
change
depends
on
whether
you
know
whatever
individual.
I
guess
cares
for
it
deeply
to
create
the
rfc
and
then
start
those
kind
of
conversations
to
make
those
changes.
But
you,
you
know,
as
you
mentioned,
there's
no
actual
limitation
right.
It's
just
to
use
your
words
clunky,
and
I
totally
agree
with
that.
A
C
I
was
just
going
to
add
one
thing
to
that
last
bit,
which
is,
I
haven't,
really
thought
this
through
all
the
way,
but
rebuilds
with
a
bunch
of
build
packs
that
modify
like
one
directory
where.
C
B
All
right
I
mean
currently
launch
dot
dominant
is
also
ephemeral
right,
so
each
time
something
has
to
contribute
a
process.
It
has
to
do
it
each
time
right
understand
like
misunderstanding,
that
works
so
when
you're
contributing
the
process,
whatever
thing
is
doing,
that
would
also
contribute
to
its
environment
variables.
I
guess.
C
A
All
right,
caching,
interplay
with
bill
of
materials,
this
this.
B
Is
sort
of
the
opposite
problem
so
since
bill
of
materials
are
part
of
the
launch
from
which
are
not
restored
between
different
builds,
what
happens
is
let's
say
you
have
a
layer
that
contributes,
let's
say,
ruby,
gems
or
like
the
packages,
and
now
you
want
to
generate
a
bill
of
materials
containing
all
of
the
packages
and
gems
that
were
installed.
You
have
to
essentially
recreate
or
rerun
this
process
of
querying
the
installed
like
packages
and
generating
a
bill
of
materials
for
them
each
time
and
typically
like
there
are
a
yes.
B
So
the
idea
here
was
whether
we
could
move
the
bill
of
materials
to
the
lariat
so
that,
when
it's
restored,
it
also
restores
people
of
materials
attached
to
it,
which
I
mean,
I
think
that
makes
more
sense
than
it
being
ephemeral
and
being
just
in
the
launch
drama,
which
has
to
be
created
each
time
and
regenerated
from
the
existing.
E
E
I
don't
think
we
have
heavy
users,
not
build
materials
on
the
heroku
side
yet,
but
that
makes
sense
to
me,
but
I
can
also
see
I
guess
it's
just
a
problem
for
existing
buildbacks
if
they
don't
store
whatever
they're
gonna
put
and
build
materials
in
the
layer
like
we,
we
quite
often
put
things
in
the
you
know
the
build.
A
C
E
B
C
How
is
that
going
to
work
for
layers
that
are
reused
from
the
previous.
C
C
C
E
E
B
A
C
E
C
I
feel
like
running
up
against
our
the
the
feature
that
we
just
merged
right,
which
is
that
build
packs
most
explicitly
opt
into
layer,
reuse
right,
so
we're
like
restoring
that
layer
tommle
with
all
of
the
build
launching
cache
flags.
That's
false
right
would
be
weird
if
that
layer
tunnel
was
restored
with
well.
Maybe
not
I
don't
know,
but
it
was
like
everything
falls,
but
then
here's
bomb
stuff
that
you
either
have
to
modify.
B
F
Sorry,
I'm
late.
Judging
from
context,
this
is
about
like
how
you
recreate
the
bomb
when
you're
using
layers
and
on
the
java
build
pack
side.
We
just
stick
everything.
We
would
need
to
do
that
into
the
layer
metadata,
sometimes
exactly
as
we
would
put
it
into
the
bomb
sometimes
not
like.
We
could
recreate
it
from
the
data
in
there.
A
We
have
a
quick
summary,
hopefully
good
enough
notes
in
the
document
about
some
of
the
discussions,
but
this
last
topic
is
essentially
moving
the
bomb
from
being
in
the
launch
tunnel
into
the
layers
directory
or
yeah
into.
F
B
Yeah
we
we
could
have
the
bomb
being
composed
of
both
of
those
things
right,
so
you
could
compose
it
from
the
buildback
level
or
the
layer
level,
and
this
would
also
be
useful
because,
currently,
like
you
can
also
apart
from
figuring
out,
which
build
pack
it
came
from.
You
can
also
then
figure
out
which
layer
that
the
materials
came
from.
F
I
do
think
we
can't
necessarily
merge
it
with
the
metadata
like
there
may
be
things
you
want
in
metadata
that
you
don't
want
in
the
bomb
or
you
want
them
in
different
formats,
but
I
could
definitely
see
it
being
in
that
file.
F
I
feel
like
the
one
note
of
caution
would
be
on
editing
like
if
you
have
a
cache
layer
and
then
the
build
pack
is
editing
it.
You
would
need
to
know
like
it
already
knows,
to
change
the
metadata.
So
I
guess
this
isn't
really
that
different,
but
it
would
have
to
know
to
change
the
bomb
and
if
it
didn't
do
that,
you
would
get
old
entries.
E
C
C
A
The
problem
with
this
one
is
that
it
sounds
like
it's
more
effort
right
to
have
to
do
this
additional
work
just
so
that
it
works
as
you
would
expect
it
right.
I
think
that's
that's
the
difference
between
a
guideline,
something
that
you
know
no,
but
not.
Everybody
has
to
adhere
to
and
then
like
functionality
right,
because
there's
a
lot
of
stuff
that
you
know
functionally,
we
could
have
not
included
in
in
the
life
cycle
or
you
know
overall,
build
packs,
but
we've
done
so
to
make
people's
lives.
A
A
A
I
assume
silence
means
yes
was
saying:
are
we
good
with
this
topic?
Yes,
all
right,
all
right,
cool,
moving
on
to
process
for
changing
lib,
cnb
design,.
B
Like
just
so,
we
using
lip
cnd
to
create
like,
along
with
the
path
to
create
some
some
buildbacks,
and
there
are
some
things
I
noticed
which
are
a
bit
clunky
about
it.
So
one
thing
that
is
like
particularly
opinionated
about
it
is
the
fact
that
each
layer
is
a
like
the
layers.
B
Output
of
a
build
result
is
a
contributor
that
that
has
a
very
specific
interface
and
you
can't
modify
things
like
labels
etc
as
part
of
a
contribution
process,
because
those
are
like,
like
slice,
values
and
they're
like
values,
you
can't
change
them
as
part
of
the
contribution
process.
F
How
some
things
you
can't
control
during
the
build
process
like
in
the
build
function,
some
of
them,
you
can
only
control
in
a
function
that
you
return
and
then
I
feel
like
the
the
interfaces
get
wonky,
because
because
things
like
bomb
are
a
pointer
and
sometimes
based
on
the
the
content
of
your
function,
you
want
to
change
the
bomb
and
you
can-
and
we
do
because
we
have
to,
but
the
only
reason
that
works
involves
knowing
how
glib
cmb
is
implemented
and
that
it
won't
write
the
bomb
until
you're
done
contributing
it's
just
kind
of
bad.
B
So
like
essentially,
because
of
that,
I
have
to
do
like
things
like
make
a
contributor
that
not
so
strong
that
has
a
bomb
pointer
and
then,
when
I
later
do
the
contribute.
I
access
the
bomb
through
that
pointer
and
then
update
it,
and
then
it
essentially
works,
because
you
now
have
to
know
the
details
of
how
the
build
process
inside
look
cmd
works
and
which
steps
it's
taking
so
you're.
Not
even
sure
if
modifying
that
would
is,
is
whether
that
bomb
is
being
modified
at
the
right
time.
B
F
You're
100
right,
there's
been
a
giant
rant.
I
went
on
like
almost
word
for
word
like
two
months
ago,
is.
F
Cnb
has
not
always
followed
the
processes
of
the
project
in
a
lot
of
ways
like
we've
not
treated
it
like
a
first
class
citizen,
I'd
like
to
get
to
a
point
where
we
do,
and
rather
than
just
been
changing
it
at
will
or
now
me
changing.
It
will
because
I
need
to,
and
we
don't
have
the
processes
around
it.
I'd
like
to
make
libsyn
be
more
of
a
something
we
can
promote
in
the
project
and
have
processes
around
haven't
gotten
there.
Yet,
though,.
B
So
essentially,
when
I
started,
I
had
the
choice
of
lip,
cmd
plus
lip
back
versus
packet,
and
the
reason
I
went
with
lip
cnd
in
the
back
was
because
they
followed
the
latest
buildback
spec
and
I
needed
the
bomb
stuff
for
my
buildbacks
and
then
they
contributed
like
lip
back.
Oh
sorry,
packet
doesn't
make
these
assumptions
and,
like
it
has,
I
think,
a
bit
senior
api
around.
B
C
B
When
it
is,
in
fact,
very
opinionated
around
how
it
does
things.
B
That
would
be
amazing.
The
the
other
thing
that
I
feel
missing
from
the
lip
back
plus
lip
c
and
d
combo
is
occam.
B
Currently
I'm
using
both
of
those
were
talking,
which
means
that,
even
though
I'm
not
using
packet
directly,
I
am
dependent
on
it
through
occam
because
of
like.
I
don't
think
that
pac
has
a
way
of
integration
testing
those
backs
like
having
some
nice
wrappers
around
back
in
docker
again
like
this.
This
does
not
involve
the
box
organization
and
it's
going
more
into
like
the
keto,
but
it
would
be
nice
to
have
like
a
testing
library
that
complements
lip
cmd.
F
Different
models
because
it's
been
maintained
historically
by
two
different
teams
who
couldn't
quite
agree
on
what
to
do.
But
what
makes
that
hard
is
that
things
aren't
standardized
and
also.
F
A
So
what
are
some,
like?
You
know
very
tangible,
next
steps,
because
I
know
we
talked
about
like
the
just
like
this
pipe
dream:
right
pie
in
the
sky,
like
of
a
complete,
almost
complete
refactor,
and
then
there's
the
very
what
seems
imminent
about
you
know:
maintenance
and
process
for
libs
cmp.
F
F
A
Yeah
I
know
in
the
past
lib
cnb
was
supposed
to
be
right.
I
know
we
kind
of
threw
a
little
bit
of
salt
on
the
non-opinionated
term,
but
it
was
supposed
to
be
non-opinionated
where
I
think
the
that
term
might
be
thought
of
very
differently
by
different
individuals.
F
F
The
cmd
has
a
little
bit
of
a
awkward
interface,
but
I
wouldn't
call
that
an
opinion.
It's
just
a
little
a
little
awkward
lib
pack
is
sort
of
an
extension
that's
compatible
with
lipscan
b
that
he's
a
bit
more
opinionated
about.
F
You
know:
here's
how
you
log
the
title
of
your
build
pack,
so
it
looks
like
the
other
ones.
Here.
Are
the
rules
we're
going
to
apply
when
deciding
whether
to
reuse,
a
layer
or
not?
So
that
is
opinionated,
and
I
think
we
should
start
by
norming
on
the
non-opinionated
part
and
making
it
less
awkward,
and
then
we
could
talk
about
whether
we
wanted
to
make
any
of
those
opinions,
something
that
people
could
opt
into.
F
A
Cool,
so
I
missed
one
of
the
next
steps,
the
alternative
you
said
to
take
what
they
have
right.
Do
you
mean
in
the
sense
of
cloning,
or
essentially
restructuring
lib
cnb,
starting
fresh
with
the
lib
cmb
repo.
A
You
said
we
could
have
the
potato
team
donate
right
or
talk
to
them
to
see
whether
they'd
be
willing
to
donate
packet
to
the
bill,
pax
io
project
or,
alternatively,
we,
you
said
we
could
take
and
I'm
trying
to.
B
B
Yeah,
exactly
that's
probably
the
only
thing
that
needs
to
change.
Everything
else
is
fine,
with
lip
c
with
packet.
I
think
you
also
get
a
lot
of
other
things
like
it's
also
opinionated
about
like
how
you
should
package
your
buildbacks.
They
have
like
a
different
cli
tool
which
lip
cnb
like
currently.
Doesn't
you
just
create
a
binary
and
then
it's
up
to
you
to
package
it?
However,
you
want.
A
So
to
me
it
sounds
like
the
alternative
is
more
tangible,
at
least
immediately
right,
like
essentially
trying
to
redesign
libc
and
b.
We
would
only
need
kind
of
buy-in
from
ben
right
as
like
the
original
maintainer
and
then
to
kind
of
incorporate
some
of
the
processes
that
we've
used
for
other
repos.
Those
two
seem
very
tangible
and
very
short
term
like
is
there
a
reason
why
we
wouldn't
want
to
go
that
that
route.
F
A
If
but
we
could
change.
F
I
think
the
other
thing
that's
a
bit
awkward
about
lip
cmd
is
that
it's
technically
part
of
the
implementation
sub
theme,
but
I
don't
think
we
really
act
like
it
is.
I
wonder
if
it
needs
its
own
sub
team,
that's
focused
on
build
pack
authoring
experience
like
I
don't
think
it
actually
sits
nicely
with
life
cycle.
A
Terence
volunteers,
as
the
first
maintainer
sounds
good.
B
Yeah,
that's
that's
another
thing
that
I'm
interested
in,
which
is
like
alternative
language
findings
for
yeah.
Like
I
think
like
we,
we
do
a
lot
of
like
we
encourage
a
lot
of
bash
scripting
and
the
documentation,
as
well
as,
like
other
things
and
and
the
other
scripting
language
that
you
can
think
of
which
is
used.
Often,
although
it
doesn't
have
a
nice
way
of
packaging
things,
I
can
still
imagine
be
useful
to
have
language
paintings.
D
I
mean
it's
not
always
true,
but
that
bash
will
be
there
on
the
kind
of
stack
image
that
you
run
at
least
the
build
stack
image
that
you're
running
it
on.
I
think
you
can
make
a
similar
argument
for
python,
but
probably
the
difficulty
is
going
to
be
around
if
you
are
pulling
in
dependencies,
because
then
it's
not
just
what's
on
the
stack
image
like
you're,
saying
right,
but
python
is
definitely
like
around
on
linux.
Distros
for.
D
A
Cool
so
it
sounds,
it
looks
like
we're
getting
really
close
to
our
time.
This
has
been
really
insightful
and
I
think
we
came
up
with
a
lot
of
really
good
stuff
there.
There
are
a
couple
things
you
know
that
we
can
do,
there's
nobody
assigned
to
it.
I
don't
know
if
we
want
to
do
that
here,
but
if
not,
you
know,
please
feel
free
to
take
some
of
those
items.