►
From YouTube: Working Group: 2020-12-17
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
done
sign
into
the
document.
Please,
if
you
have
not.
A
A
My
question
is
just
whether
or
not
there's
there's
something
that
we
should
know.
I
should
know
if
you
know
I
guess
the
weeks
ahead
are.
I
know
we
don't
have
a.
I
guess,
working
group
meetings
for
a
lot
of
the
common
rituals
is
the
release
still
anticipated
to
happen,
even
if
it
doesn't
happen
this
week.
B
Yeah,
I
think
it
will
happen
today.
Reason
for
the
delay
has
been
partially
just
due
to
a
smaller
group
with
less
availability
this
week
than
usual.
But
there
are,
I
don't
run
into
big
problems
in
the
life
cycle.
The
one
thing
we
have
run
into
big
problems
with
is
validating
with
tecton.
B
What's
going
on
there,
it
doesn't
seem
any
more
broken.
So
if
we
can't
figure
out
what's
going
on
with
tecton,
we'll
probably
just
release
it,
because
we've
validated
found
other
ways
to
validate
all
those
off
cases.
So
we
know
that
they're
working,
but
it
feels
a
little
bit
bad
to
see
persistent
off
problems
in
tecton
and
still
ship
it.
So
I'm
going
to
time
box
trying
to
figure
out
what's
going
on
there,
but
it
could
just
be
some
other
tecton
bug.
That's
out
of
scope
for
this
lifecycle
release.
A
Cool,
I
know
natalie
reached
out
right
before
lunch.
I'll
probably
get
in
touch
with
her
and
maybe
yourself
and
see.
If
there's
anything,
I
could
also
help
with.
C
C
D
D
The
main
driver
for
me
right
now
is
actually
like
order
path.
For
instance,
order
path
can
be
passed
into
life
cycle
as
an
argument,
or
it
can
be
passed
in
as
an
invar
or
it
can
be
defaulted,
but
in
sort
of
a
kubernetes
situation
where
you
may
be
kind
of
doing
some
pre-processing
of
the
source
code
you're
about
to
build
it.
D
Maybe
in
our
case
we
would
like
to
create
an
order
file
based
from
like
a
project
descriptor
and
there's
really
no
way
to
do
that
in
the
same
pod,
because
the
you
know
the
pod
definition
in
a
kubernetes
world
is
sort
of
you
know
it's
set
as
soon
as
you
create
it,
and
so
this
would
allow
us
to
be
able
to
kind
of
admit,
with
our
own
binary
as
a
pre-step
to
the
lifecycle
stuff.
This
configuration
file
and
then
have
lifecycle,
read
this
in
and
use
that
when
it's
sort
of
negotiating
the
configuration
for
itself.
A
The
intent
of
this
be
that
essentially,
almost
every
argument
that
you
could
pass
into
creator
right,
because
I
think
that
encompasses.
D
Not
even
argument
individuals,
basically
just
every
invar,
that
you
can
configure
today,
everything
you
can
figure
from
lifecycle
with
an
invar.
You
know
cnb
underscore
whatever
would
be
able
to
be
configured
through
this
tomo.
D
C
D
And
including
the
arguments
like
you
said,
if
there
are
life
cycle
arguments
that
can
be
passed,
then
maybe
those
would
show
up
here
as
well,
but
I
think
right
now,
I'm
just
sort
of
concentrating
on
the
c
and
b
prefixed
in
cars.
D
B
Based
is
a
better
way
to
pass
things
between
containers.
I
am
curious
about
some
of
these
other,
the
ones
that
are
actually
files
like
the
order.
B
I
guess
I'm
sort
of
wondering
about
like
a
file
that
you
use
to
configure
the
relation
the
location
of
a
file
like
is
there.
D
Yeah,
that
would
also
be
yeah
exactly
yeah
if
that
was
a
part
of
a
normal
sort
of
path
that
it
would
do
after
it
didn't.
You
know
if
it
looked
in
like
cmb,
slash,
config,
and
then
it
had
to
order
tommle
and
if
it
was
there,
it
would
use
that
that
would
that
would
definitely
work
for
these
file-based
ones.
B
Like
we
may
still
want
to
have
another
file
in
there
for
the
ones
like
no
color
and
log
level
that
aren't
file
based
right
now,
but
I
wonder
if
that
might
be
better
than
sort
of
look
up
a
path
to
find
the
default
for
a
path,
because
then
you
get
into
the
natural
question
of
like
well.
Should
the
config
path
be
configurable,
you
know.
D
Actually,
yeah
yeah
I've
got
like
a
cmb
yeah
cmd
config
path,
which
yeah
I
didn't
really
talk
about,
the
recursiveness
of
it,
but
yeah.
C
C
File,
but
I
think
it
makes
sense
for
the
stuff
that
you
just
said.
D
Yeah,
I
don't
know
if
it
I
mean,
I
think
it.
I
think
it
makes
sense
and
that's
where
I
would
prefer
to
be
able
to
just
write
a
file
like
cnb
slash.
You
know
config
and
then,
like
I
said,
mount
that
in
all
the
steps
and
then
it
would
just
automatically
pick
that
up.
I
don't
know
that.
I
don't
know
that.
I
like
that.
Suddenly
you
have
to
know
the
ones
that
are
file
based.
D
A
A
D
D
I
just
don't
know
if
it
outweighs
the
simplicity
of
understanding
like
what
what
you
can
configure
in
a
single
file,
but
I'm
kind
of
okay
either
way.
D
B
D
B
Unless,
like
we
put
outputs
in
layers
like
at
least
outputs
from
one
phase
that
are
inputs
to
another,
because
it's
a
convenient
place,
that
is
a
volume
right
that
gets
passed
between
things.
I
guess
we
could
establish
the
convention
that
config
is
of
volume
right,
because
that's
what
you'd
be
wanting
to
do
in
this
case.
B
B
Directory
here
right
where
it
should
be
mounted
as
a
volume,
and
we
if
we
find
things
in
there,
they
get
first
precedence,
but
because
you're
going
to
want
to
mention
this
volume,
you're
not
going
to
have
to
repeat
default
config
that
you
weren't
trying
to
change
like
if
we
don't
find
it
there.
And
then
we
go
look
in
the
location
that'd
be
like
baked
into
the
builder
in
this
case
right
for
an
order.
Tomml.
D
A
So
I
guess
just
so
it's
clear
for
me:
are
we
saying
that
there'd
be
like
a
cnb,
slash,
lifecycle,
slash,
config,
slash
and
then
in
there
you
could
have
like
a
config.tamble
that
has
individual
options
and
alongside
of
it
you
would
have
stack
tamal
order,
tamil
and
then
project
metadata,
and
so
those
are
inputs.
Then
what
about
the
outputs?
Would
they
also
go
in
there
or
would
they
go
in
layers.
B
B
B
We
don't
do
a
lot
to
restrict
that
sort
of
like
platform
and
stack
honor
system
there,
but
I
guess
it's
about
where
we:
what
locations?
We
give
the
packs
to
suggest
that
they
should
use
them,
but
actually
the
top
level
in
the
layer
stir
isn't
one
of
those
places.
We
only
tell
build
packs
about
their
corner
of
the
layer.
Stair.
D
Right,
I
guess
I'm
thinking
from
like
a
kubernetes
perspective
like
being
able
to
mount
this
as
a
read-only
volume
would
be
important
to
me.
I
think
so,
once
it's
created
it
would
only
be
writable
for
the
first
container
and
then
read
only
from
containers
from
there
on
out,
and
so
I
think,
the
outputs.
I
don't
know
that
I
would
want
them
to
at
least
by
default,
to
kind
of
assume
to
be
written
to
this
directory
if
it
exists.
D
D
Yeah,
well,
I'm
not
expecting
to
solve
this.
I
was
just
trying
to
get
some
feedback.
I
think
if
you
want
to
throw
some
feedback
onto
the
pr
that
will
be
useful
and
maybe
I'll
have
some
time
to
circle
back
before
the
next
meeting
to
to
tweak.
C
D
A
little
bit,
but
I
think
the
it
might
make
sense
to
just
do.
D
B
D
Yeah
yeah
yeah,
I
started
thinking.
Oh
life
cycle
is
going
to
go
ahead
and
just
import
everything
in
platform
in,
but
that's
only
for
the
context
of
the
build
packs
not
for
itself,
because
that
would
be
the
other
option
right.
I
would
have
like
a
platform,
slash
m
lifecycle
or
something
which
would
be
like
the
things
it
loads
into,
and
that
would
prevent
a
config
file,
but
it
just
means
that
you
still
have
that
sort
of
indirection
and
path
thing
right.
The
same
things
sort
of
exist
there.
A
A
A
B
D
Yeah,
I
think
that's
really
gonna
make
sense
to
either
to
have
a
config
file
now
what's
in
the
config
file
is
still
debatable
because
I
think
the
m
stuff
is
interesting
and
still
might
be
useful
for
something
one
day,
but
like
configuring,
the
life
cycle,
the
invars
in
a
directory,
does
seem
sort
of
convoluted,
for
you
know
little
game,
there's
no
schema
ability
and
stuff
it'd
just
be
like
you
writing.
Whatever
end
vars,
you
want
and
hoping
for
the.
A
B
E
E
E
The
range
of
errors
did
you
do
care?
What
range
we
use
for
extender
errors.
E
B
B
C
E
Yeah,
I
have
a
hard
time
like
it's
fine
I'll,
try
to
do
it.
I
have
a
hard
time
with
it,
though,
because
I
do
think
of
these
things
like
more
holistically,
so
I
feel
like
when
I
break
them
down.
I
just
start
mentally
losing
track
of
things
like
I'm
gonna
do
this
refactor
to
put
like.
I
know
you
want
to
put
the
mixing
mix
in
stuff.
First
right,
that
was.
E
E
B
Like
we've
talked
about
how
this
has
gone,
slow
and
been
difficult
before,
I
think
part
of
that's
sort
of
like
the
big
bang
of
getting
it
all
done
at
once.
Right,
because
there's
so
many
things
to
think
about
how
they
intersect
or
places,
we
could
have
forgotten
to
think
about
something
I
feel
like
in
some
ways.
It's.
C
E
B
Yeah,
I
would
say
like
provide,
mix
and
still
livestock
is
the
first
thing,
because
sex
packs
literally
can't
get
off
the
ground
without
that
right.
The
whole
description
of
what
happens
in
detect
is
predicated
on
the
fact
that
we
have
that
information.
C
B
Yeah,
but
I
wouldn't
want
to
like
cut
a
release
of
the
spec
that
had
a
build
pack
type
section
that
left
that
one
of
our
types,
I
feel
like
an
easy
thing
to
do.
There
would
be
just
start
by
introducing
the
concept
of
types,
because
we
already
have
two
types
and
like
make
it
clear
what
parts
of
the
spec
apply
to
which
type
of
build
pack,
because
then
we'll
have
a
framework.
We
can
plug
the
new
type
of
bill
pack
into.
E
Yeah
I'll
take
a
look
at
it.
It's
probably
not
too
hard
to
add.
C
B
E
B
B
B
How
do
we
reprovide
that
during
rebase,
but
what's
nice
about
the
mixing
case,
is
the
name
has
all
of
the
information
in
it?
So
we
don't
have
to
worry
about
like
oh,
is
the
path
to
this,
you
know
is
the
content
of
the
search,
something
we
actually
want
to
put
on
a
label
like
maybe
that's
not
safe,
like
there's
a
lot
of
complexity
around
the
plan
as
an
input
to
rebase
that
doesn't
exist
in
the
mixing
case,
because
the
mix-ins
like
right.
B
D
Yeah,
let's
see
that
can
has
been
kicked
down
the
road,
at
least
from
what
I've
understood
on
the
other
side.
Solutions
exist
other
in
other
ways.
I.
B
Actually
had
a
thought
about
if
we
wanted
to
do
ca,
search
those
make
sense.
What
bothered
me
about
it
before
was
the
like
the
mixing
name
that
we
were
providing
like.
I
think
you
had
an
original
example
or
ca
search
for
mix
and
it
was
sort
of
like
a
path
on
the
file
system.
But
what
I
didn't
like
about
that
was
that
the
name
itself
didn't
capture
the
description
of
what
the
set
of
changes
was.
B
It
was
contextual
based
on
the
state
of
the
file
system
at
the
time
right,
but
I
was
wondering
like
we
could.
Actually,
I
think
we
could
define
mixing
definitions
for
ca,
search
where
you
take
the
open,
ssl,
canonical
hash
of
the
certificate
which
basically
uses
the
name
and
does
some
transformation
on
it.
You
get
a
hash
back
like
we
could
come
up
with
some
mixing
schema.
D
There's
there's
still
a
case
for
like
a
stack
pack,
that
is,
that
executes
that
does
nothing
with
make
sense
right.
It
just
needs
to
do
its
work
and
that
might
be
reading
some
like
search
that
are
in
a
volume
that
it
knows
will
be
there
during
build
and
rebase
time.
That's
like
configured
through
the
platform
and
some
you
know
that
the
user
doesn't
really
have
any
say
in
directly
in
like
the
build
plan
or
build
pack
plan,
it's
just
provided
by
the
platform
and
those
need
to
be
installed
and
configured,
and
things
like
that.
D
B
B
Chrome
driver
what
we
want
is
really
a
root:
build
pack,
a
root,
app
pack,
not
a
stack
pack
like,
rather
than
being
able
to
modify
it
anywhere
except
layers.
You
wanted
to
modify
layers
and
maybe
the
app
so
it's
something
that
only
runs
a
build.
It
doesn't
run
at
rebase.
I
don't
think
you
want
your
rebase
upgrading
your
chrome
driver
like
he
could
break
your
app.
E
B
E
I
think
no,
we
might
not-
and
I
think
part
of
the
reason
that
I
pressed
that,
even
though
it
felt
like
do,
we
really
need
it
is.
I
was
testing
the
abstraction
right
like
because,
if
you,
if
you
boil
this
down,
you
could
start
to
get
to
a
point
where
it's
like.
Oh,
I
don't
need
detect
and
then
maybe
this
isn't
really
a
build
pack.
E
You
know,
and
that
worried
me,
so
I
think
that's
why
I
was
pushing
so
hard
to
see
if
it
was
possible
that
we
wanted
stack
packs
that
didn't
use
mix-ins,
and
I
think
I
think
it's.
I
think
we
decided
it's
possible
enough-
that
the
abstraction
makes
sense
so
yeah
that
I
mean
all
I'm
saying
is,
I
think,
you're
right.
D
Because
you
still
need
it
to
run
on
the
run
image
and
you
need
it
to
yeah
yeah.
I
guess
I
guess
the
difference.
I
think
that
stephen
really
had
about
stack
packs
versus
like
at
brew,
back
root,
bill
pack
or
whatever
were
was
about
rebaseability
right,
maybe
at
compatibility.
B
Maybe
there's
some
things
you
want
to
do
as
we
root,
but
you
don't
want
to
rebase
it
and
like
that
it
might
be
better
if
it's
a
build-only
type
situation,
I
think
cs.
Certs
and
packages
are
the
kind
of
thing
I
want
to
upgrade
on
rebase.
But
if
we
could
fold
both
of
those
into
the
mixing
framework,
it
could
just.
B
E
Okay,
coming
back
to
the
build
pack
types,
I
worry
that,
like
I
get
what
you're
saying,
but
I
worry
that
it's
like
a
chicken
and
egg
thing
like
once.
I
try
to
include
both.
I
have
to
have
this
big
pr.
That's
both
the
the
multi-build
packs
and
the
stack
packs
in
one
I
mean
if
you're
talking
about
a
like
a
like
an
api
version
release,
that's
fine,
I
can
do
them
in
separate
pr's.
B
I
think,
if
we're
going
we're
targeting
the
07
version
of
both
apis
for
this
right,
we
still
have
an
o6
that
hasn't
come
out
yet
like
if
we
got
providing
make
sense
to
the
life
cycle
in
an
o6
and
if
we
got
types
as
a
concept
in
an
06
like
there's,
no
stack
pack
into
this
concept,
but
we
already
have
two
types
of
bill
packs.
E
Yeah,
so
that
makes
sense
and
well
getting
it
in
for
zero.
Six
sounds
great
and
I
think
we
can
do
that,
but
still
I
I'm
talking
more
like
procedurally
with
how
things
go
into
zero.
Seven,
like
all
right,
like
I
guess,
I'm
what
I'm
asking
is
when
you
say
both
when
we
do
the
the
build
pack
types
in
the
spec
and
we
capture
all
of
them.
E
B
B
E
Actually
do
we
already,
we
already
captured
the
schema
for
build
pack
tunnel
for
that,
I'm
pretty
sure.
So
it's
just
a
matter
of
calling
it
out,
but
it
is
a
distinct
thing.
Are
we
cool
with
multi-build
pack
or
do
we
want
like
composite
build
pack?
I
feel
like
meta.
Build
pack
was
never
really
the
right
thing.
D
B
I
also
want
in
the
build
pack
interface
section
I
feel
like
right
now.
It's
not
clear
that
it
only
applies
to
what
type
I
want
sort
of
like
different
interface
sections
for
different
types.
I
know
for
stack
back.
This
is
going
to
look
a
heck
of
a
lot
like
the
regular
one,
but
rather
than
having
a
bunch
of
inserted
deep
in
text.
A
bunch
of
this
only
applies
to,
but
also,
if
it's
a
stack
pack,
this
one
thing.
I'd
rather
just
have
separate
sections
where
there's
a
lot
of
duplication.
E
Yeah,
that
makes
sense
I
thought
of
a
couple
other
things
I
wanted
to
bring
up
today.
I
think
we're
ready
to
move
on.
E
Okay,
some
folks
from
astana
added
themselves
as
adopters,
and
so
I
was
looking
through
their
build
packs.
E
And
they
document
that
you
should
use
the
from
equals
builder
thing
which
bothers
me,
because
it
feels
that
feels
like
a
hack,
and
I
think
we
even
say
it's
deprecated
and
I
think
we
should.
It
is
a
thing
a
lot
of
people
have
asked
for.
We
should
start
thinking
about
whether
to
spec
that
or
like
formalize.
It.
E
E
C
B
E
B
B
Stuff
like
there
have
been
a
lot
of
bugs
and
edge
cases,
but
we
keep
fixing
them
so
it
gets
better,
but
I
just
ran
into
like
a
thing.
The
other
day
where,
like
pull
policy,
doesn't
work.
If
it's
a
registry
build
pack
stuff
like
that
yeah,
that's.
Why
there's
a.
E
That,
okay,
something
must
have
changed
because
it
actually
the
the
first
time
I
ran
into
that.
It
was
a
problem
because
I
we
had
pull
policy
never
and
then
it
wouldn't
pull
our
build
pack.
It
was
like.
I
didn't,
want
it
to
pull
the
builder,
but
I
needed
to
pull
the
build
pack,
and
so
that's
why
I
created
pack
pull
build
pack,
so
something
must
have
changed.
If
that's
the
case
and
now
it
just
always
pulls
it
or
something.
D
You
know
we
talked
about
extending
the
pull
policy
to
have
like
a
bill
pack
pull
policy
or
something
as
well
right,
because
you
you,
like
you
said
you
might
want
to
always
like
you
might
be
testing
a
builder.
You
never
want
to
pull
the
builder,
but
you
always
want
to
pull
bill
packs,
especially
explicitly
express
build
packs
from
like
pack.
E
Yeah,
okay
and
then
the
other
thing
was
the
search
api.
E
E
E
Search
api
did
you
vote
for
it,
yet
I
think
it
was
waiting
on
yours,
okay.
Well,
once
you
do
that
we
will.
B
B
E
B
D
D
Kind
of
circling
back
a
little
bit
to
the
pack
build
like
from
builder.
I
think
I
wonder
if
we
should
invest
some
more
resources
into
like
what
it
would
look
like
to
inject
or
override
in
a
build
pack
group
through
project
descriptor,
so
that
you
don't
have
to
like
fight
with
these
command
line.
Args,
because.
C
D
E
Yeah
position
whatever
yeah,
but
I
think
I
think
what
came
to
my
mind
was
like
piggybacking
on
another
build
pack
like
I
think
in
most
of
these
cases,
it's
like
oh
yeah.
I
just
want
to
run
before
the
java
build
pack
and
not
like.
I
want
to
run
in
position
three
and
like
that
that
might
actually
solve
the
problem
where
there's
like
the
the
builder's
order,
that
has
multiple
groups
where
it's
like
any
time
the
java
buildback
runs.
I
want
to
run
this
agent
java
agent
build
pack
with
it.
E
E
I
think
it's
one
of
those
things
like.
Actually,
what
emily
was
saying
too,
like
the
the
dash
dash
build
pack
flag,
is
a
pain
in
the
butt.
Always
will
be
just
because
you're
usually
talking
about
a
list
of
things
and
it's
a
fairly
it's
an
ordered
list,
and
it's
a
long
list
sometimes
and
the
reality.
B
B
D
Yeah,
that's
yeah!
That's
tough,
because
yeah
when
the
metabill
packs
are
usually
like
the
ones
that
are
named
the
way
you
want
as
well.
You
know
it's
like
heroku,
slash
java,
like
that's
the
name
someone's
going
to
know,
even
though
it's
like
a
composite
build
pack
of
like
five
different
things
that
they're
probably
not
going
to
be
familiar
with,
and
you
don't
really
want
to
make
them
explode
that
out
into
project
tamil,
because
then
you're
no
longer
safe
to
change
the
group
and
add
new
ones.