►
From YouTube: Working Group: 2021-02-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
All
right
we're
at
five
after
the
I
guess
remember
to
sign
in
and
do
we
have
any
new
faces
sambov,
I
don't
know
if
we've.
B
A
The
thursday
meetings
are
usually
or
I
think,
everybody's
kind
of
centered
around
showing
up
on
wednesday.
We
have
20
or
30
people,
and
then
everybody
feels
like
that's
enough
for
the
week.
So
we're
probably
going
to
figure
out
that's
the
best.
B
A
Got
it
that
makes
sense.
Hopefully
we
can,
I
think,
there's
an
idea
to
maybe
split
this
one
up
into
some
smaller
things,
and
hopefully
we
can
kind
of
move
those
more
distributed.
So
it's
easier
to
for
people
in
different
time
zones
to
attend,
but
I'll
see
all
right.
The
next
thing
we
have
is
it's
just
what
I
was
talking
about
thursday
meeting
attendance.
A
Do
we
feel
like
it
might
make
sense
to
start
you
know
breaking
this
into
some
subject:
interest
groups
or
something
it's
because
it
seems
like
we
get
a
whole
lot
of
people.
You
know
five
companies,
30
people
or
whatever
on
wednesdays,
but
you
know
the
the
second
hour
a
week.
C
So
what's
the
proposal
here
for
that
you're
suggesting
I
know
I
mentioned
in
the
past-
that
we
were
thinking
about
doing
the
different
sub
teams
as
actual
like
working
groups.
I
I
know
ben
was
going
to
create
an
rfc
because
I
think
part
of
the
conversation
is
around.
C
C
But
ultimately
I
I
wonder
if
it's
worth,
if
what
you're
suggesting
is
to
move
to
using
the
working
group
or
sorry,
the
sub
team
stuff
to
kind
of
take
on
some
of
the
thursday
stuff,
and
does
that
mean
that
thursday
just
goes
away.
A
We
could
do
that.
I
wasn't
sure
if
we
felt
like
the
existing,
you
know
sub
team.
Sync
meetings
were
sufficient
to
replace
you
know
the
other
hour
yet
or
if
we
needed
more
different
formats.
Something
like
that.
A
A
C
E
D
I
I
I'm
worried
about
trying
to
schedule
stuff
if
we
just
give
up
the
slot,
because
I
know
it's
been
a
pain
to
get
stuff
on.
I
know
like
steven's
calendar
historically,
for
instance,.
A
I
I
wonder:
if
do
we
have
good
attendance
at
the
other
sub
team
meetings
or
could
could
we
use
this
slot
as
assuming
that
we
have
some
some
calendar
space
on
people's
calendars
and
you
know
move
the
poorly
attended
ones
around?
I
don't
know.
E
I
wonder
if
this
should
be
like
more
like
an
office
hours,
we're
like
it
defaults
to
just
being
on
the
calendar
and
people
can
meet
if
there's
something
to
meet
about,
and
it's
set
up
in
either
slack
or
previous
attendance,
I
mean
you
could
run
into
conflicts
but
unlikely.
C
So
I
guess
from
you
know,
when
we
describe
office
hours,
what
do
we
mean
like?
How
would
we
summarize
what
office
hours
means
to
us?
Is
it
people
coming
in
with
questions
or
something.
A
Different
say,
more
question:
oriented
instead
of
presenting
oriented
right,
like
probably
wouldn't
be
a
time
when
people
present
rfcs,
but
it
might
be
a
time
when
somebody
comes
to
get
feedback
on
an
rfc.
It
could
get
a
lot
more
specific
than
the
wednesday
ones
right.
It
could
be
a
place
where
we
take
those.
You
know
really
deep,
divey
conversations
it's
like
or
those
could
be
more
acceptable
on
thursdays
than
wednesdays.
Something
like
that.
C
A
E
Is
there
any,
I
guess
need
to
have
somebody
or
some
group
of
people
volunteer
to
at
least
show
up,
because
otherwise
you
might
have
someone,
let's
say
wanting
to
engage
with
the
community,
and
nobody
comes
right
like
at
least
you
have
one
person
who
says:
okay,
I
I
am
involved
with
cnbs
and
I
can
be
the
person
to
hear
your
question
and
respond
to
it.
A
It
seems
like
it'd,
be
a
good
idea.
I
think
if
we
change
the
documentation
in
the
community
repo
to
indicate
that
it's
an
office,
hours,
time
and
kind
of
you
know,
attendance
is
very
optional.
That
would
also
go
at
least
somewhat
towards
making
sure
that
people
in
the
community
show
up
and
expecting
a
working
group
meeting.
Don't
you
know,
aren't
surprised
by
a
kind
of
lower
attendance
thing,
so
I
definitely
agree
that
the
goal
is
important.
E
I
wonder
if
we
can
make
can
zoom
have
like
a
landing
page
when
people
show
up
or
anything
with
any
of
that
info
or
not.
I
don't
know
how
zoom
works,
but
if
it
had
like
a
you
know,
opinion
slack.
If
you
know,
if
no
one's
here
in
a
few
minutes
like
you
know
see
if
anyone
did.
If
you
want
questions,
see
who
shows
up.
C
C
Let's
say
I
show
up,
but
it's
like
a
a
question:
that's
like
way,
either
in
the
weeds
of
something
that
I'm
not
a
you
know,
aware
of
or
something
like
that
I'd
be
concerned
that
I'm
not
the
right
person
for
that,
and
so
I
think
that's
why
I
really
like
the
idea
of
having
the
questions
like
pre-mentioned
or
noted
so
that
that
way
we
have
the
right
people
there
to
support
them.
C
A
By
the
linux
foundation,
anti-trust
statement
thing
we're
supposed
to
have
an
agenda
coming
into
any
meeting
anyways,
I
think.
Even
if
it's
like
an
office
hours
type
meeting,
that's
that's
better
practice
and
so
like.
I
think
we
should
still
encourage
people
to
put
stuff
on
the
agenda
ahead
of
time
if
they
plan
to
talk
about
it.
Even
if
it's
they
just
plan
to
talk
about
it
informally
in
the
office
hours
kind
of
format
instead.
C
All
right,
what
are
the
next
steps?
I
guess
if
we
wanted
to
try
this.
A
Wait
for
wednesday
and
then
propose
with
a
larger
group.
We
make
that
thursday
meetings
office
hour
meetings
next
week
and
make
sure
everybody's
okay
with
it.
C
All
right
sounds
good,
I
guess
do
we
want
to
add
it
to
the
agenda
for
wednesday.
C
Yeah
one
of
the
things
that
other
part
I've
noticed
other
projects
doing
is
that
they'll
send
out
a
reminder
on
the
slack
channel
and
since
we
already
have
slack
channels
for
all
the
appropriate
subteams
like
that,
could
be
a
really
good
place
to
set
a
reminder
that
a
certain
sync
meeting
is
happening.
C
Natalie
you're
the
would
you
mind
setting
those
up
for
our
slack
stuff
cool.
Thank
you.
D
D
Apps
are
built
in
a
different
directory
and
we
were
trying
to
change
it
to
be
the
same
directory,
because
that
helps
align
it
with
kind
of
the
cmb
spec.
And
so,
as
we
make
changes,
he
had
a
question
around
under
the
cmb
platform
spec,
whether
home
and
cmb
after
should
be
the
same.
This
came
up,
I
think
in
the
cmd
shim
build
pack.
D
We
also
have
for
adapting
the
v2
build
packs
to
run
in
a
v3
environment,
and
so
some
of
the
concerns
around
that
are,
I
guess,
around,
like
secrets
and
privacy
around
home
and
whatnot
and
depending
on
the
platform,
whether
the
fact
that
we
don't
specify
what
a
home
should
be
set
to,
but
it's
set
by
the
stack
right
today.
D
So
that
that
could
have
wildly
different,
I
guess
things
depending
on.
If
a
bill
pack
decides
to
use
that
environment
variable.
A
I
thought
the
specs
said
explicitly
that
they
cannot
be
that
cnb
after
at
home,
have
to
be
different,
like
home,
can't
be
included
in
cnb
after
I
thought
there
was
something
in
the
spec
that
said
that,
because
of
the
like,
you
know
like
if,
if
you're,
if
you
have
a
docker
damage
mounted
into
some
place,
you
could
copy
your
docker
credentials
into
it.
Or
you
know
your
language
module
cache.
D
D
A
I
think
I
thought
maybe
it
was
maybe
in
the
build
pack.
Spec
though
it
says
the
following
environment
variables
must
not
be
overridden
by
the
life
cycle
and
are
provided
by
the
platform
home.
Yes,
but
maybe
it.
E
D
Yeah
I
mean
the
fact
that
it
could
be
different
on
different
platforms
as
well
could
mean
build
packs
behave
differently
if
they're
actually
expecting
it
coming
from
v2.
I
guess
where
people
were
probably
using
home
because
obviously
cmb
after
did
not
exist
for
v2
right.
D
I
guess
this
was
linked
to
another
issue
or
an
issue
from
the
cmv
shim
build
pack
where
digital
ocean
to
open
a
thing,
because
they've
been
trying
to
use
some
of
our.
I
guess
v2
built
packs
inside
of
cmb
for
stuff
and
ran
into
this
issue
as
well,
for
I
think
php.
D
I
can
post
that
in
here,
but
here's
the
pr
on
that
and
they
were
trying
to
set
it
to
be
the
same
for
compatibility
which
then
referenced.
I
think
this
particular
thing
that
opened
on
the
s
bill
pack,
spec
project.
A
E
B
E
A
D
Cool,
do
you
want
to
comment
on
that
issue?
Stephen.
A
D
Yeah
and
then
do
we
need
to,
I
guess,
figure
out
how
to
update
that
in
the.
A
D
Part-
it's
just
like,
I
don't
even
know
in
the
spec
clarification
where
it
should
be,
so
maybe
the
rc
is
just
cleaner
of
the
extent
that
you
don't
have
to
figure
out
where
the
spec
it
belongs.
Initially.
A
Yeah,
I
think
it
would
have
to
go
into
the
platform
spec
until
we
refactor
but
but
either
way,
whatever
whatever
you
think.
D
A
A
D
Cool,
that's
all
I
had
on
that.
I
just
wanted
to,
I
guess,
get
more
eyes
and
clarification
on
it.
Cool.
A
B
Yeah,
this
was
something
that
I
put
in
so
like
currently
for
prototypes.
We
have
a
couple
of
build
packs
implemented
in
bash,
but
I
would
like
to
have
something
that's
better
tested
and
it
seemed
easier
to
do
that
and
go.
But
the
next
question
I
had
was
like
which
of
these
libraries
is
recommended,
slash
supported
by
the
buildbacks
organization.
So
I
know
lib
cnb
is
the
official
non-opinionated
finding,
but
that
lacks
quite
a
few
convenience
tooling
around
interacting
with
the
with
with
the
api
itself.
B
So
I
found
these
two
other
things
in
the
aquito
buildbacks
organization.
I'm
not
sure
what
the
relation
of
that
organization
is
with
cloud
native
buildbacks
but
like
if
it
is
related
which
of
these
two
are
recommended.
A
Got
it
so
just
for
some
background
on
the
different
projects
cloud
unit.
Build
packs
is
in
the
cncf,
and
it's
just
intended
to
define.
What's
the
build
pack
api
and
provide
tools
for
platforms
to
you
know
be
able
to
implement
running,
build
packs,
then
there
are
different
sets
of
build
packs
that
meet
you
know,
they're,
maybe
tailored
towards
specific
companies
or
projects,
customer
and
user
requirements.
So,
like
heroku,
has
a
set
of
build
packs.
A
Google
has
a
set
of
build
packs.
Pocato
is
it
it's
also
it's
actually
in
the
linux
foundation
like
the
cncf
is,
but
it's
under
the
cloud
foundry
foundation,
and
it's
mostly
vmware
people
who
work
on
that
that
project,
and
so
it's
just
like,
for
instance,
potatoes,
like
really
modular
and
maybe
a
little
more
operator-centric
in
some
ways
and
the
heroka
build
packs
are
very
you
know,
kind
of
build
on
top
of
what
heroku
has
done
in
the
past.
I
shouldn't
talk
about
them.
Terence
can
give
a
better
description.
A
You
know
so
they're
they're
just
different.
You
know
implementations
of
of
the
build
logic.
You
know
for
different
language
runtimes
and
things
like
that.
So
lib
pack
and
packet
are
both
ones
in
the
potato
project
and
the
official
advice.
I
should
probably
give
you
there
is
join
the
potato
working
group
meeting
and
ask
them
about
what
the
difference
is.
But
I
can
I
can
give
you
a
overview.
It
packet
does
kind
of
combines
libscnb
in
libpack.
It's
like
more
of
at
least
last
time.
A
I
checked
it
was
more
of
one
one
library
that
did
both
of
those
things
and
it
was
used
by
the
largely
the
non-java
ones
and
then
limp
pack
and
lim
cnb
are
used
more
by
the
java
potato,
build
packs.
I
think
just
different
developers
built
different
libraries.
You
know
to
kind
of
work
against
the
api,
so
yeah
there's
a
whole
different
slack
for
pocato.
You
could
join
if
you're
interested
in
those
libraries
slack.pacado.io
to
sign
up
I'll,
send
it
in
the
zoom
and
those
folks.
A
A
D
A
Oh
yeah,
I
I'm
still
working
on
that.
Let's
start
off,
I
bought
pac
file,
dot
io.
I
know
I
might
change
the
name
because
it
sounds
too
much
like
a
get
pack
file.
It's
still
just
a
project
of
my
my
personal
github,
the
it's
been
a
little
while,
since
I've
had
a
chance
to
update
it
works,
it's
fully
functional.
It's
missing
a
ton
of
tests,
but
besides
that
like
try
it
out,
and
let
me
know
what
you
think.
I
have
some
example-
build
pack
templates
and
different
languages.
A
A
D
Yeah,
I
guess
I
was
just
curious
about
that.
It's
story
with
related
to
people
who
are
building
build,
packs
like
it
seems
like
you
could
just
write
a
pack
file
if
it
isn't
necessarily
like
a
thing
where
you
want
all
the
stuff
and
go,
but
then
you
can
also
then
migrate
even
to
use
it
as
a
go
web
right.
So
yeah
there
is
a
interesting
path
there.
I
just
don't
know
how
much
you're
pushing
that
stephen.
A
No
one's
using
it
for
anything
yet,
but
but
yes
like
if
you're
writing,
if
you're
writing
a
build
pack
and
go
pac
file
is
much
more
of
an
abstraction
compared
to
what
like
lib
pack
and
packet
provide
like
unifies
the
build
plan
entries
and
the
layers
together
and
then
lets
you
run
everything
in
parallel.
If
you
want
to
it,
does
some
fancy
things?
There
are
examples
here,
if
anybody's
interested
kind
of
see
what
it
would
look
like
like
what
does
an
npn
build
pack
and
go
look
like
if
you're
curious.
A
D
A
A
D
Yeah
it'd
be
nice
to
have,
I
guess,
talking
about
road
map
idea
stuff,
like
it's
just
a
page
for
the
just
the
question
that
sam
asks
of
just
the
stuff
and
also
stuff
that
is
provided
by
the
community
like
the
paquetto
things
or
pac-file,
etc.
A
I
agree
that
makes
sense.
I
think
I
need
to
want
to
add
more
tests
to
pac
file
before
I
start
advertising
it.
It's
pretty.
You
know
just
through
a
bunch
of
stuff.
B
I'm
also
curious
in
in
terms
of
the
future,
so
there's
a
pull
request:
slash
rfc
for
back
buildback
create
which
currently
like
it
seems
to
start
off
with
bash.
But
when
I
see
the
other
options
that
were
being
considered
were
go
or
python,
if
it
does
go
with
go,
would
that
just
be
built
on
lip
c
and
b,
I'm
just
asking
in
in
terms
of
like
future,
so
I
don't
want
to
implement
something
and
then
move
on
to
a
different
library,
or
is
that
not
a
like?
D
Oh,
the
great
build
pack
has
nothing
to
do
with
our
commitment
to
lip
scene
being
we
just
there's
been
a
research
study
that
going
on
right
now
that
just
feedback
that
having
to
no
go
is
as
a
requirement
to
get
started,
is
potentially
a
tall
order.
If
you
don't
know
it
already,
and
so
we
just
wanted
to
kind
of
minimize
the
bear
to
entry,
but
a
ton
of
stuff
is
being
written
and
go
obviously
for
the
project
and
that's
not
changing
anytime
soon
and
same
with
lip
cmd.
D
Is
it's
not
we're,
not
sunsetting
that
or
nothing's
happening
with
that
as
far
as
maintenance
and
and
things
with
that
project,
as
part
of
the
future
work
of
that
rfc,
I
believe
there
was
parts
that
is
how
we
can
extend
it
to
support
other
languages
as
well.
So,
just
like
having
templates
that
you
can't
have
a
thing
where,
if
you
are,
if
you.
C
D
E
Yeah
I
mean
that
sounds
right.
Well,
the
there's
actually
a
pr
implementing
that
rfc
right
now
and
what
it
generates
is
extremely
minimal,
and
that
was
the
goal
for
the
initial
thing
in
the
future.
We
do
want
to
support
many
languages,
including
python,
go
and
bash,
and
I
think
the
approach
that
we
discussed
was
to
have
like
template
repositories
that
you
would
sort
of
start
from
and
some
of
those
might
use
ellipsian
b.
Some
of
them
might
not.
Some
of
them
like.
E
I
think
the
pacquiao
folks
actually
have
multiple
ways
that
they
write
their
go
build
packs.
So
there
would
be
a
lot
of
options
in
that
case,
but
what's
there
right
now
is
sort
of
like
the
zero
option.
It's
just
empty
files,
a
little
bit
more
than
empty
files.
A
Most
of
the
complexity
in
the
build
pack
api
should
be
handled
by
the
life
cycle.
Right
like
the
clean
api.
We're
trying
to
provide
is
at
the
file
system
level
for
any
language
to
be
able
to
write.
You
know
build
pack
layers
that
can
turn
into
an
image.
So
I
I
wouldn't
you
know
it
seems
like
you're
very
worried
about
like
oh.
A
If
we
pick
glimpse
cnb,
you
know,
or
if
we
pick
packet
are,
we
gonna
have
to
switch
to
something
else
later,
but
the
I
think
those
are
pretty
lightweight
bindings
that
they're
not
they're.
Not
they
don't
implement
a
lot
of
functionality
on
top
of
what
the
life
cycle
is
doing.
Anyways.
I
think
the
the
goal
is
for
that.
A
You
know
the
life
cycle
provided
by
the
cloud
and
volpex
project
to
really
provide
that
nice
api
for
developers,
and
then
you
know
language
bindings
are
nice,
but
they
shouldn't
do
a
lot
of
complex
stuff
on
top
of
it.
If
that
makes
sense,
ignoring
ignoring
my
pac
file
thing,
that's
that's
something
else.
D
I'd
love
to
hear
about,
I
guess
the
use
case
and
stuff
for
bill
pax
and
bloomberg.
It
doesn't
have
to
be
this
meeting.
But
at
some
point
I
know
we've
talked
about
that
a
little
bit
but
yeah
just
be
interesting
to
see
kind
of
where
it
kind
of
fits
in
and
what
advantages
you
see
of
using
bill,
packs
and
kind
of
errors
and
concern
for
adoption.
B
Yeah
yeah
I
I
can
set
something
up,
maybe
I'll
reach
out
to
you
on
slack.