►
From YouTube: Working Group: 2021-05-19
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
A
B
Wait
a
second
guys
well
hi.
I
I
already
have
like
I
don't
know
three
weeks
I
think,
or
two
or
four
weeks
with
the
cnb
team
with
anthony
natalie
daniel,
so
yeah,
I'm
in
colombia
and
I've
been,
you
know,
learning
a
little
bit
about
all
the
products
pack,
life
cycle
and
other
ones.
I
already
did
my
my
first
pr,
so
I'm
still
learning
and
I
hope
that
I
can
help
with
the
product
and
move
forward.
A
Thanks
welcome
and
sorry
if
you've
been
in
here
before
I
just
didn't
know
if
you'd
had
a
chance
to
say
hi
yet
to
the
different
folks
different
companies
all
right.
So
next
thing
on
the
agenda
is
spec.
Sorry
next
thing
is
release
planning
and
updates
click
that
off
with
I
don't
know
platform
when
I
go
first.
C
B
Happy
too
so
we're
gonna
enter
code
freeze
on
monday
for
a
pack
release.
That's
pretty
much
it.
A
A
Oh,
I
guess
I
can
give
a
quick
update
from
the
implementation
team.
We
are
actively
working
on
issues
for
the
next
life
cycle.
A
A
All
right,
any
other
updates
from
subteams.
D
Distribution,
we
met,
I
think
this
morning
to
talk
about
potentially
builders
in
the
registry,
so
there
may
be
an
rfc
coming
in
the
next
week
or
so
about
that,
with
the
hope
that
maybe
it
could
help
supplement
or
help
with
the
pack
suggest
builders
command,
instead
of
it
just
being
a
hard-coded
list
and
also
from
the
registry
you
could
like
for
each
individual
build
pack.
Having
that
data
now
would
mean
you
could
see
what
builders
say.
A
And
I'm
gonna
share
my
screen
all
good
awesome.
A
C
D
Yeah
there's
been
some
comments
and
suggestions.
This
is
just
combining
emily
and
sam's
drafts,
plus
some
of
my
own
stuff.
So
the
three
of
us
kind
of
putting
this
together
went
up
last
thursday,
so
we
haven't
had
a
chance.
I
think
it's
ready
for
review.
D
There's
been
some
good
discussion
discourse,
so
I
still
have
to
make
a
few
updates,
but
I
don't
think
there's
like
a
ton
of
drastic
requests
or
changes
in
the
rc,
but
if
people
do
want
to
talk
about
it
more
and
have
it
added
as
an
indent
item.
B
A
A
All
right
make
build
layers
read
only
for
subsequent
build
packs.
B
I
just
wanted
to
separate
it
out
because,
like
I
tried
to
show
on
in
that
whole
shared
layer
stuff,
and
it
wasn't
going
well
with
the
existing
rfc.
So
I
just
decided
to
separate
that
out
makes
sense.
A
It
seemed
like
organizationally
it'd,
be
easier
for
people
to
parse
but
feel
free.
To
put
because
I
know
everybody
seemed
to
feel
like
we
couldn't
do
one
without
the
other
you'll
freak
out
in
even
in
the
rfc
text,
for
either
of
them
put
a
codependency
on
the
other,
so
that
people,
even
when
you're
reading
the
rsc.
You
know
this
thing
wasn't
done
in
isolation.
You
go
here
for
how
you
do
it
now
right.
I
think
that
should
be
like
part
of
the
text.
A
Do
we
want
to
put
this
on
the
agenda
or
all
all
good
for
today,
maybe
we'll
we'll
see
when
we
go
over
the
next
one?
Did
you
open
a
new
one
yeah?
It
seems
like
not
yet.
A
A
About
this
today,
it
seems
like
we
got
to
a
pretty
good
conclusion
at
the
kind
of
deep
dive
we
did.
But
if
you
want
to
talk
about
it.
B
A
Want
to
make
sure
you
do
one
time
this
week
add
bomb
to
layer,
content
metadata.
This
is
in
fcp.
Fcp
closes.
This
was
been
an
fcp
for
a
long
time.
C
I'll
preempt
you
on
shaming
me
on
this
too.
I
actually
did
start
the
rfc
for
the
new
proposal
for
bachelor's
process
types.
I
found
a
little
bit
of
time
to
work
on
it.
It's
about
halfway
done,
maybe
I'll
just
throw
up
the
very
rough
web,
so
people
can
see
it
after
this
meeting,
but
progress
is
happening.
A
A
B
This
thing
is
like
these
last
few
cases
I
know
we
were
still
divided
between
alternate
four
and
the
proposed
solution
and
the
the
new
shared
layers
rfc
that
I'm
planning
to
write.
I
was
hoping
that
if
we
use
this
new
structure,
that
would
actually
fit
in
nicely
on
where
to
put
that
shared
layers
directory,
because
otherwise
you'll
have
to
we'll
have
to
figure
out
yet
another
place
and
mount
for
that
one.
B
Those
are
here
that
that
actually
combines
everything.
So
this
is
this
also
combines
like
the
app
door.
I
think
I
I
I
don't
know.
If
maybe
we
can
discuss
this
like
I'll
put
it
on
these.
C
C
A
C
Yeah
I
mean
I
do
want
to
buy
on
the
directory
names.
I
just
worry
that
we've
done
this
a
couple
times
and
we
say
things
out
loud
like
we
should
add
app
and
rename
it
to
workspace,
but
it's
sort
of
hard.
I
think
we
keep
coming
back
instead
of
making
it
actual,
and
I
was
wondering
if
in
a
small
group
we
could
actually
collaborate
on
writing
something
up
in
a
way
that
incorporates
those
suggestions
in
a
way
that's
not
as
appropriate
for
the
working
group.
That's
not
good.
A
A
And
then
actually
that's
it.
Those
are
all
the
rscs.
This
week,
I'm
gonna
stop
sharing
and
we'll
jump
into
the
agenda.
D
So
is
that
rfc
not
in
fcp,
then,
if
we're
still
discussing
it
bike
shedding.
C
I
think
you
got
a
lot
of
approvals
before
we
went
into
went
through
a
lot
of
iterations
on
it,
so
I
wonder
if
maybe
we
should
be
re-requesting
them.
C
A
All
right
next
thing
on
the
agenda
is:
do.
Does
anybody
want
to
scribe
today?
Probably,
should
ask
that.
B
B
I
put
that
there
I'm
I'm
a
little
distracted
today,
so
I'm
not
able
to,
I
think,
fully
participate.
I
was
wondering
if
somebody
else
would
like
describe
if
we
think.
A
Awesome
then
next
up
is,
I
think
we
have
a
new
maintainer.
Somebody
want
to
make
somebody's
going
to
make
the
announcement
yeah.
I
could
take
some
of
that
all
right,
so
it
is
with
great
honor
that
I
announce
sam
has
been
elected
to
be
a
maintainer
of
the
learning
sub
team.
A
A
He
spearheaded
and
kind
of
wrote
a
few
guides
in
catacota,
which
is
an
online
interactive
guide,
and
then
you
know,
he's
been
around
our
community
supporting
end
users
in
slack
and
also
in
q
at
cubecon,
so
that
was
really
helpful.
So
yeah
really
appreciate
the
work
there
and
welcome
to
the
team.
B
A
Alright,
so
I
believe
joe
will
reach
out
to
you
and
get
you
all
set
up.
D
A
All
right,
that's
awesome
news,
I'll
move
us
to
the
next
item,
which
is
buildpack
author,
subteam
rfc.
D
Cool,
like
emily,
said,
even
though
her
she's
the
author
of
it,
I
will
present
it.
D
Yeah,
so
this
has
been,
I
think,
discussed
a
few
times
in
the
working
group.
I
want
to
say
for
like
the
last
few
weeks,
and
so
this
is
really
just
making
it
an
actual
rc
and
official
sorry
for
my
delinquency
on
carrying
this
through,
but
we
wanted
to
have.
D
This
proposes
basically
a
actual
sub
team
that
is
focused
on
the
bill
pack,
author
audience,
whereas
I
think
today,
with
the
sub
teams,
we
have
it's
kind
of
mixed
between
the
various
sub
teams
for
kind
of
championing
and
being
responsible
for
that
build
pack.
D
Author
experience,
there's
you
know
the
bill
pack
api
and
that's
kind
of
handled
between
the
core
team
and
also
within
lifecycle,
as
well
as
well
as
kind
of
the
platform
side
and
we've
seen
stuff
with
joe's
rfc
with
like
the
build
pack
create
stuff
and
so
and
then
also
implementation
owns
like
libsamby.
D
So
it's
it's
kind
of
like
all
over
the
place
and
we
want
to
have
a
single
home
for
kind
of
taking
and
championing
this
core
audience,
and
so,
with
this
sub
team,
it
will
take
ownership
of
the
lib
cnb
repository
from
the
implementation
team,
as
well
as
thinking
about
potentially
other
language
bindings
that
are
kind
of
out
there
and
may
bring
some
of
that
stuff
in
or
not
it's
kind
of
up
to
the
sub
team
there
and
so
responsibilities
for
language.
D
This
kind
of
lays
out
like
responsibilities
for
actual
what
it
means
to
maintain
an
official
language
binding
for
the
project.
There's
been
some
kind
of
modification
stuff
for
around,
basically
collaborating
with
other
teams
kind
of
for
championing
the
things
that
pertain
to
bill
pack,
authors
and
also
with
the
bill
pack
api.
This
sub
team
will
kind
of
have
a
closer
eye
to
changes
for
the
bill
pack.
D
Api,
specifically,
as
that
affects
bill
pack,
others
and
stuff
that
is
kind
of
scoped
in
the
future,
would
be
things
like.
The
project
templates
that
kind
of
came
out.
The
bill
packs
create
rfc
as
one
of
the
future
works,
potentially
even
test.
Harnesses
for
making
easier
for
bill
pack,
authors
to
write
and
test
spill
packs
and
then
stuff
around
things
like
inline
or
pack
file,
to
make
it
even
easier
for
escape
patches
for
people
needing
to
ride
bill,
packs
and
so
yeah.
That's
this
rfc
either.
D
One
of
the
alternatives
that
was
suggested
when
I
was
talking
with
joe
was
maybe
combining
this
with
the
distribution
team.
If
we're
concerned
about
having
too
many
small
teams,
that
is
a
team
of
two
people-
and
there
are,
there-
is
some
overlap
between
kind
of
the
build
pack
author
publishing
experience.
D
But
I
I
do
think
it's
somewhat
of
a
weak
overlap,
but
yeah.
B
B
For
example
same,
I
think,
there's
a
similar
overlap
with
there's
like
an
there's,
a
github
action
that
installs
pac,
for
example,
and
so
like
has
the
same
kind
of
thing
where
yeah,
maybe
the
pack
things
should
own
it
or
it
should
be
the
distribution
team,
but
it
I
am
kind
of
a
fan
of
actually
moving
a
lot
of
that
bit
of
it
out
of
the
distribution
team.
D
Authors,
so
you
do
think
this
team
should
own
those
github
actions
versus
distribution.
B
B
The
one
thing
that
holds
me
up
is
that
leaves
the
distribution
team
with
nothing
now
part
of
the
problem
is
whether
or
not
you
think
the
registry
is
going
to
become
a
bigger
thing
in
the
future
like
require
more
work.
If
you
think
the
answer
to
that
is
yes
right,
like
that,
it's
going,
we
need
to
add
new
features
to
it.
We
need
to
work
more
on
the
ui
for
it.
D
Yeah,
that's
okay,
too,
like
we
can
have
smaller
sub
teams
like
I
never
expected
distribution
to
be
as
big
as
like
implementation
or
platform
right,
which
are
kind
of
the
two
big
core
sub
teams,
and
also,
I
think
you
may
have
missed
this
ben.
I
don't
know
if
you
joined
late,
but
there
was
a
discussion
of
about
expanding
the
registry
to
also
contain
like
builders
yeah.
So
we
can
link
like
build
packs
to
builders
and
it
can
kind
of
plug
into
you
know,
suggest,
builders
and
pack.
B
B
D
C
D
D
But
it
sounds
like
you're
in
favor
of
having
this
as
a
separate
team
from
distribution.
Then.
B
A
I
don't
know
how
how
strongly
opinionated
we
are
about
this,
but
we
don't
necessarily
want
build
packs
to
be
in
the
cloud-native,
build
packs
project
which
confuses
a
lot
of
people
externally
that
are
cloud
into
bill
packs
and
talk
about
build
packs.
But
if
you
go
to
build
packs,
I
oh
there
are
no
build
packs.
You
have
to
go
to
you
know
different
projects
that
provide
build
pack,
implementations
or
a
registry
of
curated
build
packs.
A
Do
we
worry
that
having
a
build
pack,
a
sub
team
called
build
pack,
author,
sub
team
and
continuing
to
not
have
build
packs
in
the
project?
Does
that
make
any
or
like
I
don't
have
a
problem
with
it?
I
think
it
makes
sense.
I
just
wanted
to
call
out
that
that's
kind
of
there's
an
angle
here,
maybe
it's
worth
some
consideration.
C
A
D
Yeah
I
mean
to
emily's
point
that
is
exclusively
her.
Original
rfc
actually
had
just
built
back
and
I
added
author,
and
I
think
sam
also
had
authors
there,
because
I
think
it
is
very
ambiguous.
If
you
have
a
team
called
build
packs
like
what
their
scope
is.
It's
been
brought
up
a
handful
of
times,
just
like
it's
hard
to
address.
When
you
talk
about
build
packs,
you
mean
the
project.
Do
you
mean
a
bill
pack?
Do
you
mean
the
spec
like?
What?
What
are
you
actually
talking
about.
A
B
D
C
C
Lifecycle
because
I
feel
like
it
gets
a
bit
weird
when
you
say:
oh,
it's
responsible
for
the
implementation
of
the
spec
like
each
build
pack
is
an
implementation
of
the
build
pack.
Spec
right
platform
is
an
implementation
of
the
platform
spec,
I'm
not
sure
it's
conveys
as
much
meaning
to
folks
who
aren't.
I
think
it
might
be
confusing
to
people
coming
into
the
project
who
want
to
know
how
to
talk
to
the
life
cycle
team.
D
I
think
that
makes
sense
with
the
creation
of
that
of
this
of
this
team.
I
can
include
that
in
this
rc,
if
you
just
want
to
knock
out
two
birds
with
one
stone.
A
C
C
A
D
What
else
does
implementation
on
life
cycle
and
libsynb
is
that
it.
A
A
I
think
the
charter
of
the
life
cycle,
sub
team
shouldn't
be
narrowly
defined
as
maintenance
of
the
life
cycle
repo,
but
maintenance
of
the
you
know
presenting
the
life
cycle
interface,
including
the
current
implementation
of
the
life
cycle
repo,
I
know,
that's
very
seems
very
nitpicky,
but
it's
like
the
I
like
platform,
sub
team
being
anything
that
falls
under
this
category
of
this
side
of
the
api.
If
that
makes
sense,
if
the
implementation
sub
team,
you
know,
I
don't
think
it
should
just
be
about
maintaining
one
repo.
D
C
A
A
D
A
B
A
I
I
guess,
because
there
are
some
like
minor
questions
involving
the
the
rename
of
the
implementation
subteam.
I
would
maybe
recommend
that
it
be
a
separate
rfc,
even
if
it's
just
as
simple
as
saying
renaming,
the
team
itself.
C
D
B
A
year
ago,
I
would
have
demanded
leadership
of
this
particular
sub
team.
It
is
near
and
dear
to
my
heart
and
something
I
observed
that,
like
we
broadly
miss
a
lot,
there
aren't
a
lot.
There
are
a
lot
of
voices
around
platform
here
and
very
few
as
actual
build
pack,
authors
and
so
that'd
be
great
at
last.
I
do
not
have
the
time
to
do
it,
and
so
I
will
just
chew
off
your
irritants.
While
you
do
the
good
work.
B
Maybe
maybe
contributor
to
to
the
bat
team.
D
D
I
think
that
will
just
be
a
figure
out
how
to
work
well
with
other
the
other
sub
teams,
but
we're
probably
not
going
to
own
anything
like
in
pack
per
se,
but
probably
would
shepherd
stuff
through
if
it
pertained
or
championed
kind
of
those
issues.
I
think
there
is
a
big
part
of
this
sub
team
that
is
also
advocating
for
the
interest
of
those
authors,
even
if
it
doesn't
mean
actually
writing
the
lifestyle,
implementation
of
something,
for
instance,.
D
Cool,
that's
it
happy
to
move
on.
B
I
think
the
last
one
on
the
agenda
is
that
rfc
around
this
ambiguity,
layer
metadata.
Let
me
share
my.
B
B
I'll
say
I'm
sharing
that
I
tried
to
immute
myself
earlier,
but
then
it
colonel
panicked.
I
had
to
reboot
the
my
comment
at
the
bottom
was
meant
to
kind
of
be
a
draft.
We
discussed
at
the
implementation
meeting
this
last
week
that
we
were
going
to
try
to
put
up
a
couple
versions
of
what
could
be
the
the.
A
D
B
I
guess
it
hasn't
happened
yet,
so
I
went
ahead
through
mine
up
there
late
last
week,
you're
talking
about
this
one
right,
yeah
yeah,
I
I
mean
what
were
the
open
questions
since
last
time.
I
think
one
of
the
questions
was
whether
we
want
the
current
proposed.
Let
me
open
up
the
readable.
A
B
B
A
C
One
of
the
things
I
like
that
jesse
did
here
was
introduce
places
to
sort
of
put
some
of
our
files
that
we
just
leave
littered
around
so
sort
of
files
that
the
platform
might
be
writing
on
the
fly
rather
than
using
baked
into
the
container.
So
it
needs
to
be
on
a
volume
like
order,
tommle
and
files
that
the
lifecycle
uses
to
pass
data
from
one
phase
to
another.
C
C
B
I
updated
the
comment
if
you
want
to
refresh,
but
the
I
might
never
mind.
It's
totally
missed.
C
A
C
A
C
A
B
A
A
Does
anybody
feel
weird
about
seeing
so
c
and
d
used
to
be,
like
you
know,
kind
of
metadataish,
not
not
active
user
files,
kind
of
coming
from
platform
a
little
bit
now,
it's
like
doesn't
feel
like
that
anymore.
It
feels
like.
Oh,
this
is
the
whole.
It's
everything
build
pack
related
right.
I
like
how
short
it
is
like
it
doesn't,
extend
the
layer
pads
enormously
more.
A
C
A
I
think,
if
that
one
more
directory
is
just
c
and
b
at
the
beginning,
because
it's
not
then
again,
this
is
very
much
getting
into.
We
said
we're
going
to
talk
about,
but
because
it's
not
and
one
of
the
proposals
like
output
right
indicates
that
it
doesn't
make
sense
in
the
context
of
the
final
build
image
you
know,
having
it
build,
packs
doesn't
make
sense,
because
well
there
were
some
versions
of
it
that
I
don't
think
semantically
made
sense
for
what
you've
got
in
the
end.
C
B
C
Change
it
all
the
other
things
are
not
on
a
volume,
so
they
could
be
top
level.
There's
no
need
to
group
them
all,
but
I
feel
like
there's
some
desire
not
to
pollute
the
top
level,
but
you
could
have
built
packs
and
life
cycle
at
the
top
level.
If
you
wanted
to.
I
think
this,
the
one
thing
that's
a
bit
weird
about
that
is
this.
C
B
A
C
A
A
Okay,
so
then
move
build,
packs
and
lifecycle
into
builder
and
then
put
the
rest
of
the
stuff
at
builder
and
they're.
Only
two
top
level
things
slash
c
and
b
and
slash
builder
and
then
builder
becomes
part
of
the
builder
extension
spec.
But
no,
then
I
guess
you
end
up
with
builder
on
the
run
image.
That's
the
problem.
B
B
B
C
A
A
You
don't
have
to
name
it
right
now
the
run
image
and
that's
where
the
runtime
thing
is
copied
over
from
the
builder
or,
however,
you
built
your
image
if
it
didn't
involve
the
builder
end
up
and
then
there's
a
slash
c
and
b
in
the
build
time
based
image,
saying
builder,
whatever
you
want
to
call
it.
That
is
this
volume
that
has
all
these
directories
in
it.
Where
you
can
sub
now
into
app
as
a
sub
volume
of
that,
and
then
has
the
directory
structure
suggested
by
dsd.
Does
that
seem.