►
From YouTube: Working Group: 2021-02-24
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
See
a
lot
of
familiar
faces:
okay,
next,
standing
item,
release,
planning
and
update.
Should
we
start
with
the
life
cycle
natalie.
B
A
C
There
is
no
current
update
for
pac,
but
I
do
have
an
update
for
techton,
given
that
it
is
the
end
of
the
month.
We
will-
or
I
say
we
but
most
likely
myself
we'll
be
publishing
two
updated
tasks
to
the
techdown
catalog,
as
well
as
a
new
techton
pipeline.
C
B
A
B
A
I
think
that's
the
right
one.
Did
everyone
see
a
bunch
of
pr's,
great
okay,
starting
with
the
oldest
one
project,
descriptor
flexibility?
This
is
back
in
draft.
Do
you
have
any
updates
here,
terrence.
A
E
A
No
worries
all
right
application.
Mix-Ins
still
in
draft
looks
like
joe's,
not
here
right
now.
I
think
he's
coming
to
this
meeting
late,
so
we
can
probably
skip
over
that
one
create
stackify
repo.
A
It
looks
like
this
has
the
required
approvals.
Did
you
want
a
chance
to
review
this
stephen
before
we
move
it
into
final
comment
period.
D
Nope,
I'm
good
to
move
I've
already
looked
at
it.
I
just
haven't.
E
E
Final
pass
as
well,
but
I
can
do
that
right
now.
A
Stephen
to
re-review
group
editions
to
build
our
order.
E
E
To
say
why
don't
we
just
move
stack?
If
I
put
it
right
now,
I
just
have
to
wait.
Another
week
it's
been
gone
for
a
while.
A
B
A
A
So
maybe
platform
and
learning
maintainers
can
take
that
as
an
action
item.
So
we
can
get
this.
A
This
also
looks
like
it
has.
Does
this
have
enough
approvals?
Maybe
we
need
one
more
from
joe
or
steven.
A
A
B
B
A
I
think
from
a
process
standpoint
we
do,
let
me
say
explicitly
in
the
rfc
rfc
that
there
can
be
sub
team,
specific
rfcs,
that
go
in
this
repo,
but
the
approval
process
is
technically
different
in
that
it
requires
approval
from
the
sub
t
maintainers.
I
don't
think
we've
used
that
a
lot
in
the
past,
but
maybe
this
would
be
a
candidate.
A
A
Agenda
next
item
is
cb
roadmap
ideas,
github
discussion,
I'm
going
to
take
that
terence.
E
Yeah
so
I
put
that
on
here.
Hopefully,
I'm
not
still
cutting
out
we're
on
the
leadership
side,
we're
talking
about
roadmap
for
the
upcoming
year
and
we
have
been
for
a
little
while,
but
we
wanted
to
basie
open
up
for
ideas
from
the
broader
community,
so
linkedin.
The
agenda
is
linked
to
a
github
discussion
where
we're
hoping
to
have
that
async.
E
We
decided
against
and
you're
welcome
to
talk
about
stuff
in
slack
where
we
cited
against
from
having
slack
be
the
main
point
of
the
conversations
just
because
we
don't
have
history
and
we
didn't
want
to
kind
of
lose
that
information
be
able
to
collect
it
in
a
single
place,
so
we'll
be
having
that
open
for
the
next
week.
I'll
update
the
post
actually
to
have
that
date
on
there
too.
E
So
we
want
to
meet
again
as
leadership
team
sometime
at
the
end
of
next
week
to
basically
just
take
a
look
at
everything.
People
have
posted
and
we'll
also
be
posting
stuff
in
there
too,
and
basically
come
up
with
something
for
the
coming
year.
A
E
Maybe
just
wait
till
I
think
joe's
supposed
to
come
back
in
the
second
half,
so
maybe
we'll
just
bump
this
until
he
gets
back.
But
as
far
as
I
know,
he
wants
to
do
something
this
week,
but
I
haven't
heard
anything
else.
A
We
can
sort
of
guess
from
the
topics
of
the
items
here
where
it'd
be
nice,
if
everyone
updated
their
build
packs
with
descriptions
and
keywords,
I
know
we
haven't
done
that
on
the
pacquiao
side.
Yet
it
seems
like
there
are
some
issues
that
are
linked
here
blocking
the
release.
A
You
can
punt
this
to
the
end,
but
unfortunately
we
are
at
the
end
of
the
agenda
that
we
have
listed
for
today.
Is
there
anything
that
isn't
on
the
agenda
that
given
we
have
so
much
extra
time,
anyone
would
like
to
talk
about
right
now.
D
I
see
we
have
google
build
packs
and
heroku
build
packs
from
the
kiddo
packs
mentioned
on
there.
Does
red
hat
have
some
build
packs,
we're
worth.
F
It's
a
very
valid
question
at
this
point:
I'm
I'm
seeking
approval
as
to
how
much
I'm
allowed
to
say.
D
Just
if
there
are
other
sets
of
you
know,
open
source,
build
packs
that
could
be
published
through
the
registry
just
want
to
encourage
as
well
I'll.
F
Give
my
perspective
but
understand
I'm
speaking
as
a
person,
not
as
a
company
here
you
understand
the
the
way
that's
played,
but
basically
I'm
very
interested
in
build
packs.
I
I
believe,
there's
a
lot
of
purpose
to
them
and
I
think
they
will
solve
a
need
that
red
hat
has
for
how
to
distribute
supportable
applications
that
are
built
on
red
hat
runtimes.
F
My
skills
are
mainly
in
java
I'll
need
the
other
red
hat
runtimes
teams
to
be
on
board
to
add
their
skills
to
the
appropriate
packs
and
then
we'll
need
to
get
the
images
published
and
supported
and
maintained
and
continually
updated
whenever
we
update
our
base,
and
all
of
that
means
that
we've
got
to
get
commitments
in
place
before
we
can
jump
in
and
say
that
yes,
this
is
something
we
can
do
at
a
supportable
level.
But
you
know
from
a
technology
perspective.
This
is
perfect
and
what
I
want
so.
D
F
F
There
are
various
red
hat,
build
packs
in
existence
today,
I'm
not
gonna
list
them.
They
exist
if
you
search
on
github,
you'll,
find
them,
but
they're,
mostly
one-to-ones,
because
of
the
discussions
we
had
the
not
last
week
the
week
before,
because
we
can't
install
the
rpms.
We've
got
a
one-to-one
builder
to
build
pack
to
run
image
correlation
across
a
whole
number
of
those.
B
On
the
google
side,
I
can
say
we're
not
really
ready
to
put
our
build
packs
up
on
the
registry,
because
we
have
some
pretty
ill-defined
interfaces
between
our
build
packs.
We
never
thought
about
trying
to
make
them
stand
alone
or
have
others
integrate
into
them,
and
we
were
looking
to
refactor
it.
So
we
we
plan
to
make
this
available
at
some
point,
but
it's
not
going
to
be
in
the
very
short
term.
A
That
makes
sense,
I
feel,
like
we've
just
thrown
all
of
ours
up
there,
even
though
we
could
do
a
better
job
documenting
the
interfaces
between
the
components.
But
if
you
have
sort
of
like
a
multi-build
pack
that
compiles
the
components
together,
that
could
just
be
used
like
that
might
be
a
good
candidate
to
put
up.
If
you
don't
put
up
the
others,
but
no
pressure
just
suggesting
it.
F
I
think
there's
only
other
one
thing
and
it's
only
because
we
don't
have
anything
else
to
discuss
but
bring
it
up,
because,
obviously,
I've
worked
implementing
a
platform
and
I've
worked
implementing
builders
now
going
from
the
specs
as
written,
and
I
give
gave
a
huge
long
list
of
feedback
on
an
issue
somewhere
on
the
platform
spec
I
could
go.
Do
the
similar
thing
for
the
stack
spec,
but
I
I
kind
of
want
to
know
is:
is
there
a
purpose
to
doing
this
because
yeah
the
platform
spec
there's
no
sign
of
that
shifting?
F
As
a
result
of
that,
I
know
we
discussed
that
whether
or
not
it
was
better
for
me
to
give
it
as
a
just
as
a
feedback
or
whether
to
try
and
structure
it
as
a
potentially
an
rfc,
because
the
scale
of
change
would
be
big.
But
how
open
are
you
guys
to
the
idea
of
reworking
the
specs
to
draw
out
the
concept
of
a
stack,
spec
separate
from
sorry
to
draw
out
the
platform
spec
apart
from
the
life
cycle
spec
and
the
others,
because
today
they're
very
fused
together?
A
Something
I
thought
about
a
lot
because
I
have
similar
impressions
to
you
about
the
current
state
of
the
spec,
and
I
probably
already
would
have
put
up
an
rfc
for
this.
If
there
weren't
it's
been
a
busy
time
lately,
but
my
two
cents
is
like
stack.
Spec
should
be
a
separate
spec
and
I
know
we've
sort
of
socialised.
A
This
idea
before
and
it
seems
like
people
are
rather
warm
to
it.
So
it's
the
kind
of
thing
that
you
know
a
proposal
for
would
probably
take.
Some
work
would
be
taken
seriously.
It
could
be
worked
on
when
you
talk
about
separating
platform
from
life
cycle
spec.
A
I
think
about
it
a
little
bit
differently
in
that.
I
think
what
we
call
the
platform
spec
right
now
is
really
a
life
cycle
spec,
it's
not
a
platform
spec
at
all
and
it
sort
of,
but
it
specifies
the
platform
api,
which
is
the
api
lifecycle,
must
provide
to
the
platform
and
sort
of
like
how
that's
used.
A
There
are
a
couple
things
in
there
that
are
like
recommendations
for
the
platform
about
how
it
you
know
should
run
a
rebase
if
the
base
image
changes
or
stuff
like
that.
But
I
think
the
amount
of
things
that
are
actually
requirements
of
the
platform
are
pretty
small,
and
most
of
these
are
requirements
of
the
life
cycle
that
the
platform
can
choose
to
use
as
it
sees
fit.
D
The
platform
spec
kind
of
started
as
a
dumping
ground
for
everything
that
didn't
belong
in
the
buildback
spec,
because
we
wanted
to
keep
the.
What
is
the
thing
that
the
build
tech
author
needs
to
understand
to
make
it
work
in
one
place
and
the
all
the
other
stuff
you
might
care
about
that.
We
want
to
specify
in
another
place,
and
so
I
think
I
don't
think
anybody
would
push
back
on
more
improvement
there.
D
As
long
as
I
think
emily
made
a
good
point
about,
we
do
have
platform
and
build
pack
apis,
and
that
means
something
different
than
a
specification
and
making
sure
the
definitions
of
those
apis
are
kept
clean.
You
know
probably
makes
sense.
F
But
if
you
didn't
want
to
solve
creator,
then
the
platform's
got
a
lot
more
responsibilities
that
it
has
to
do,
because
it's
responsible
for
passing
the
same
stuff
and
I've
hit
some
issues
with
the
platform
where
trying
to
understand
which
directories
need
to
have
read,
write
and
create
capability
on
it
is
is
ill
specified
in
that
way.
Please
don't
take
this
as
a
dig,
I
realize
how
difficult
it
is
to
get
a
spec
to
a
point
where
it
would
be
magic
and
completely
clean
the
first
time
around,
but
no
that
isn't
the
goal
here.
F
This
is
a
goal
to
say
that
there's
still
stuff
there
that
I
think
that
would
benefit
from
being
cracked
off
of
that.
So
that,
and
the
main
main
reason
I
want
this-
is
that
when
I'm
looking
at
the
platform,
spec
anywhere
where
it
says
must
in
the
rfc
sense
of
the
word,
must
it
has
to
be
something
a
platform
can
implement,
as
in
a
platform,
implementation
can
implement
without
needing
to
go
to
a
custom
life
cycle
implementation
to
solve
that
problem
right,
otherwise,
you're
not
talking
about
a
platform
spec.
The
platform.
F
D
I
think
we
should
keep.
I
think
the
platform
spec
is
really
mostly
a
platform
half
of
the
life
cycle
spec,
but
that
that
that
spec
doesn't
specify
what
the
platform
should
do
when
it
interacts
with
build
packs
or
the
the
build
pack
interactions.
Part
remains
separate
should
still
be
a
goal.
I
think
I
don't
think
we
should
combine
the
document
together.
That
says
this
is
how
build
packs
work
in
the
document
that
says
this
is
how
platform
interfaces
into
the
life
cycle.
This
probably
needs
to
be
like
five
different
documents
right
at
least.
F
Now
so
it's
a
few,
I
don't
know
yeah
I
mean
I
just
like
to
think
of
it
as
you
need
a
spec
that
covers
the
part
you
need
to
write
and
it
shouldn't
try
and
control
things
that
are
beyond
the
thing
that
you're
trying
to
write.
Whether
the
thing
you're
trying
to
write
is
a
build
pack
or
whether
it's
a
platform
or
whether
it's
you
know
a
life
cycle
implementation
it
shouldn't
matter.
A
E
Appreciative
says
he's
on
his
way,
not
to
end
without
him
joining,
so
he
can
talk
about
registering.
E
I
don't
know
if
I
have
a
sound
team,
I
feel
like
I
should
delegate
to
jesse
on
the
stanford
team.
He
has
much
more
interesting
things
in
his
background
with
that
tub
kind
of.
B
A
E
E
C
Why
would
we
need
to
have
a
platform
api
directory.
A
A
We've
really
gotten
away
with
this,
mostly
because,
because
we
haven't
made
the
types
of
changes
to
those
files,
but
it's
not
something
that
we
couldn't
do.
According
to
the
spec.
A
In
general,
I
think
it's
because,
like
a
platform
might
be
orchestrating
this
builder
and
the
platform
could
have
may
not
support
the
api
that
you
put
in
that
file
right.
So,
first
of
all,
we
don't
allow
multiple
apis
to
be
used
at
the
same
time
to
have
to
be
the
same
api
in
every
file,
and
then
it
would
take
away
control
from
the
platform
about
what
api
to.
C
C
Yeah
this
one
definitely
requires
more
brain
power
for
me
to
wrap
my
head
around
it,
because
I
the
way
I'm
thinking
about
it
right,
it's
like
inputs
and
outputs
from
the
api.
The
platform
api
is
one
thing
right.
If
I
provide
a
file
as
an
input
to
the
lifecycle
and
tell
it,
this
is
the
api
that
I'm
currently
performing
in
or
as
right.
I
would
expect
that
the
output
of
anything
generated
would
also
adhere
to
that
specific
platform.
A
But
now
there's
overlap
between
the
apis.
If
you
say
that
a
builder
has
to
have
this
exact
file
in
it,
but
the
platform
also
defines
what
that
file
looks
like
the
like,
which
api
does
this
file
format
belong
to
and
how?
C
Yeah,
I'm
definitely
not
a
huge
fan
of
the
directory
structure,
just
because
I
feel
like
that's,
going
to
open
up
a
kind
of
worm
for
a
whole
bunch
of
other
directory
structure.
Focused,
you
know
strategies,
but
so
maybe
we
need
to
step
back
and
figure
out
exactly
like
if
there's
other
possible
solutions.
But
I
see
where
you're
coming
from.
A
C
But
I
was
somewhat
under
the
impression
that
the
current
builder
spec
proposal
rfc
and
this
pr
were
to
document
what
currently
exists
right
and
from
what
it
sounds
like
this
would
be
a
change
to
that.
So
wouldn't
that
be
like
a
builder
o2
or
implementation
detail.
A
C
So
I
guess
my
question
or
concern
becomes
what
happens
to
the
current
existing
builders,
and
you
know
it's
support
within
current
existing
platforms
right
if
they
don't
adhere
to
this
newly
created
spec
right.
Are
we
considering
it
builders?
You
know
builder
api,
double
o
right
that
that's
kind
of
I
guess
more
or
less.
My
concern.
A
E
C
C
E
C
G
Yeah,
I
just
wanted
to
give
an
update
on
the
launch,
which
is
extremely
close,
but
I
need
sort
of
a
call
for
help
too,
because
I'm
kind
of
underwater
it's
blocked
right
now
on
the
docs
repo,
which
has
some
like
gomod
thing
that
it
works
locally,
but
all
of
a
sudden
out
of
nowhere
with
no
code
changes,
started
breaking
on
github
ci.
G
It's
that
and
then
another
issue,
just
like
a
little
link
on
the
registry
itself
that
I'll
fix
that
those
are
the
two
blockers.
If
someone
could
help
me,
take
a
look
at
the
docs
repo,
it
would
be
great.
I
appreciate
it
the
the
other
things
that
are
nice
to
have
before
going
out,
I
reached
out
to
google
again
about
getting
their
build
packs
into
the
registry.
I
don't
know
if
there's
anybody
from
google
on
the
call,
but
yeah.
B
Earlier
yeah,
it's
just
saying
that
we
talked
about
it
and
we're
not
that
happy
about
our
interfaces
between
our
build
packs,
so
we're
not
really
ready
to
put
it
up
yet
yeah.
G
Let
us
know
if
there's
anything
we
can
do
to
help.
I
mean
we'd
love
to
have
them
in
the
registry
in
one
form
or
another,
even
if
it's
the
like
a
monolithic,
meta,
build
pack
that
just
includes
all
the
build
packs,
that's
sort
of
like
what
you
have
in
the
builder.
So
that's
something
you'd.
D
G
Happy
to
help
with
too
yeah
and
then
I
think,
heroku
and
pacquiao.
I
think
we're
waiting
on
not
we're
not
really
waiting,
but
as
long
as
we've
got
the
docs
thing
blocking
there's
some
metadata
updates
for
description
and
licenses
that
would
be
nice
to
have,
and
I
have
a
docs
link.
I
forget
what
this
docs
pr
is.
Oh
yeah,
this
is
just
a
minor
thing,
so
that's
that's
the
update.
If
you
can
lend
a
hand
on
the
getting
the
doc
repo
working
I'd
love
it.
C
Yeah
I'll
I'll
volunteer
to
pursue
it,
I'm
not
sure
if
I'll
be
the
one
doing
it
but
I'll
see
what
I
can
do
thanks.
G
But
then
otherwise
yeah,
I
think
as
soon
as
that's
done,
we'll
do
a
blog,
a
tweet
and
an
email
for
those
that
use.