►
From YouTube: Working Group: 2021-03-31
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
I
was
doing
it
automatically
for
so
long
that
I
keep
thinking
it's
already
going
all
right,
so
just
repeat
any
release,
planning
updates
or
anything
like
that.
Maybe
we
could
start
with
the
implementation,
sub
team.
B
Sure
so
we
shipped
a
life
cycle
011-0
yesterday
and
we
in
the
last
hour
had
two
reports
of
from
different
people
experience
experiencing
issues
with
the
release,
so
we
are
looking
at
it
as
we
speak
so
far.
It
seems
that
there
is
something
that
causes
the
life
cycle
to
hang.
C
There's
nothing
really
to
update
other
than
the
tecton
tasks
were
finally
released.
I
don't
that
was,
I
believe,
late
week
last
time,
so
I'm
not
sure
if
it
was
mentioned
here,
I'm
still
making
some
tweaks
to
the
tekton
pipeline
other
than
that.
Nothing
really
for
the
platform
that
I'm
aware
or
yeah
for
pac,
specifically.
A
First
thing
is
proposed:
creation
of
best
practices
and
guidelines
or
repository.
Does
I
think,
samuel
open
this
one.
A
A
Maybe
he's
away
right
now
looks
like
we're
just
looking
for
feedback
on
this
right
now.
It's
just
opened.
C
A
A
All
right
and
pack
cache
the
draft
next
one
is
allow
setting
default
command
arguments
that
can
be
overridden
by
user.
This
is
already
tagged.
Anything
does
this
need
anything
else.
Anybody
have
context
on
where
this.
This
is.
E
A
A
Also,
oh,
it's
just
been
updated
as
of
40
minutes
ago,
so
it
seems
like
looking
for
more
feedback,
I'll,
go
ahead
and
add
the
core
team
to
this.
One
also.
D
B
A
B
B
A
Ad
rfc
for
displaying
contributor
graph
do
you
have
anthony
here
nope
anybody
want
to
speak
to
this
at
all,
looks
like
there's
some
activity,
but
maybe
not
super
recent
activity.
14
days
ago,
yeah.
B
A
A
No
worries
sounds
good
project,
descriptor
domains,
rfc.
A
I
think
I
probably
skipped
that
one
somehow
that's
my
own
own
rfc.
I
just
has
an
update
here,
there's
feedback.
I
still
need
to
update
it.
I
know
it's
been
14
days.
I
will
absolutely
get
back
to
it.
A
So
don't
worry
terence
who's.
Not
here
did
I
skip
anything
else.
A
C
A
D
C
D
C
C
Sounded
like
ben
was
saying:
let's
go
to
fcp
and
then
have
that
period
for
core
team
to
object.
Essentially.
D
A
C
I'm
rushing
I'm
rushing.
I
I
do
want
to
add
the
the
rfc
I
have
in
draft
since
there
isn't
anything
else
go
forward.
Let
me
present
it
real
quick.
C
All
right,
so
what
we
have
here
is
a
platform
specific
thing,
but
I
think
it's
it
might
be
impactful
enough,
given
that
we're
we're
enabling
some
flexibility
that
wasn't
quite
there
before
that
it
may
be
worth
kind
of
discussing
as
a
whole.
Here
in
the
working
group,
but
essentially,
there's
been
a
couple
like
the
motivation.
C
Are
these
use
cases
right
where,
as
a
pac
user,
they
want
to
be
able
to
have
different
combinations
of-
or
I
guess
maybe
a
better
term
is
better
configuration
of
the
caching
mechanisms
and
where
the
caching
resides
during
a
pack
build,
and
so
these
use
cases
they're
kind
of
linked
here,
but,
for
instance,
one
they
want
to
build
using
the
dr
daemon
and
storing
the
build
cache
as
an
image
in
the
registry.
So
that's
just
something
that
we've
recently
enabled.
C
With
the
cache
images,
but
we
still
don't
like,
we
still
need
to
be
able
to
do
it,
publish
right
as
a
kind
of
issue
there.
C
There
are
other
things
like
bitbucket
pipelines
which
don't
allow
you
to
use
named
volumes
which
pack
uses
you
know
kind
of
behind
the
scenes
to
be
able
to
do
this,
and
the
last
one
is
to
be
able
to
specify
the
name
of
the
volumes
similar
to
cache
image,
where
you
could
specify
the
cache
image
you
want
to
use
for
the
operation.
You
want
to
be
able
to
specify
what
volumes
to
use
in
case
you
do
want
to.
You
know,
maybe
shoot
yourself
in
the
foot
and
use
the
same
caching
for
one
application
versus
another.
D
C
C
Yeah-
and
I
mean
even
related
right
like
if
you
wanted
to
change
the
name
of
the
app
or
the
image
right,
the
caching.
If
you
know
what
the
caching
is,
that
could
still
be
persisted
across
different
image
names,
which
right
now
isn't
possible.
C
That's
an
interesting
thought.
I
I
really
haven't
thought
about
that
and
I
think
in
particular,
because
the
the
use
cases
that
this
is
trying
to
resolve
are
more
around
very
specific
advance
usage
of
cache
and
thereby,
you
know,
maybe
limitations
of
the
environment
that
they're
being
used
in
and
not
so
much
for
the
everyday,
app
developer
right,
and
so
because
of
that,
you
know
part
of
the
reason
why
we're
okay
with
a
more
complex
syntax.
C
D
Yeah,
like
I
think,
that's
the
wrong
scope
right
like
inside
of
project
tunnel
tied
to
this
particular
application,
is
the
wrong
place
for
that,
because
applications
can
be
built
with
a
great
many
tools
on
my
laptop
is
only
one
of
those
where
I
want
this
particular
configuration
when
it
goes
into
bitbucket
and
I
need
a
different
flag
like
what
exactly
did
you
check
into
source
control
to
be
used
there?
So
I
don't
think
it's
the
right
right
scope
for
it.
A
D
Like
this
is
the
same
thing
with
anything
that
takes
a
flag
right,
do
you
write
an
alias
to
help
out
with
it
or
something
like
that?
If
we
were
going
to
do
this,
something
in
the
pack,
config
directory
feels
like
the
right
place
to
me
where
it's
associated
with,
I
don't
know
something
a
fully
qualified
path
or.
D
A
D
As
you
constantly
point
out
and
other
meetings,
we're
in
local
working
directory
does
not
correspond
one
to
one
to
an
image.
A
If
we
implement
this,
does
it
create
ux
problems,
I'm
just
bringing
it
up
as
feedback,
not
like
yeah,
not
blocking
on
it.
My
next
question
is:
does
this
you
know
we're
talking
a
lot
about
building
a
front
end?
Someone
even
has
a
kind
of
proof
of
concept
in
the
community
of
a
build
kit
front
end,
and
that
may
change.
Caching
may
change
caching
a
lot
if
we
can
upload
implement,
merge
app
upstream
and
build
kit,
which
is
something
that's
on
there
or
that
you
know
they
have
an
open
issue
about
that.
A
Someone
could
take
a
look
at.
I
don't
think
this
does
anything
like
I.
I
don't
think
this
makes
it
harder
to
move
in
that
direction,
but
just
want
to
call
out
that
that
may
change.
Caching
a
lot
if
that
makes
sense,
and
so
the
or
how
pack
cash
is
in
local
builds
at
least
so
it's
maybe
worth
thinking
about
what
caching
looks
like
over
there
before
we
commit
to.
You
know:
building
out
sort
of
more
complexity.
In
the
current
model,
but
not
not
a
blocking
thing,
also
just
something
that
occurs
to
me.
C
Yeah,
maybe
in
that
same
vein,
I
know
emily
and
I
have
spoken
about
the
fact
that
pack
could
technically
stay
away
from
using
the
daemon
flag
for
the
life
cycle
and
therefore
not
use
the
launch,
cache
and
so
technically
launch
cash
could
eventually
go
away,
and
I
think
part
of
the
the
inspiration
for
the
solution
is
the
idea
that
certain
flags
or
options
could
go
away
right.
So
it
makes
it
more
flexible
like
one
of
the
things
here
right,
if
type
or
sorry,
if
launch
goes
away,
then
the
only
type
is
build.
C
Right,
that's
what
I'm
saying
like.
If
we
go
away
from
the
daemon
and
like
we,
we
would
have
a
pack
hack
to
essentially
stand
up
a
registry
and
have
a
life
cycle
published
to
that
and
then
pack
move
it
to
the
damon.
A
A
E
C
Yeah,
the
only
bike
shedding,
I
think
we
had
was
in
the
syntax
itself-
was
like
the
separators
semicolons
versus
commas,
but
yeah
I'll.
Let
my
pushback
on
commas,
in
that
some
of
the
options
could
be
lists
where
we
might
want
to
have
commas
as
separators
there,
as
opposed
to
full
options.
A
C
Try
to
get
some
of
that
more
fleshed
out
and
approved
at
the
platform
side
of
things.
B
I
hate
this
interface.
Sorry,
I
actually
just
wanted
to
actually
ask
a
question
because
I
know
we've
got
some
items
on
the
life
cycle
around
arm
64.
and
this
one
from
there
who's
working
on
it
and
I'd
like
to
it's
becoming
important
for
for
us.
So
we'd
like
to
see
about
contributing
to
it.
A
Yeah
yeah,
that
makes
sense
the
I
think
mike
was
working
on
it.
Does
anybody
else
know
who
else
has
looked
into
this
discussed.
A
E
In
the
implementation
sub
team
meeting,
I
think
that
might
be
a
good
meeting
for
you
to
pop
into
if
you
can
click
on
tomorrow.
I
don't
know
it's
somewhere
on
the
links.
I
think
it's
in
that
dock
that
we're
in
actually
but
the
that
might
be
somewhere
where
you
pop
in
to
see
yeah,
I
think
you'll
be
right.
There.
Steven
michael
was
looking
at
it,
but
I'm
not
sure
it's
like
his
priority
or
anything
right
now.
E
So
I
think
it
might
be
good
to
pop
in
and
see
if
anyone's
actually
doing
the
work
because
we
talked
about
it,
but
I
think
it's
kind
of
on
everyone's
bucket
list,
but
it's
not
really
like
the
top
of
anyone's
mind
right
now,
so
I
think
it
would
be
valuable
to
get
in
there
if
you've
got
contributors,
then
that
would
be
great.
D
Jesse
steven,
what
do
you
understand
the
scope
of
his
work
to
be?
Is
it
just
life
cycle
is
arm
64
available.
D
A
He
he
was
experimenting
with
it,
with
no
like
kind
of
mandate
to
deliver
anything
if
that
makes
sense
a
while
back
right.
I
think
if
but
that
that's
not
to
say
that
you
know
it's,
it
couldn't
be
as
focused
now
or
you
know.
That's
that's
not
what's
up
next
form,
I
just
don't
have
the
visibility
right
now,
but
I
can.
I
can
find
out
there's
a
arm
channel
in
the
us
cloudy
to
build
pack
slack
also
brian.
You
might
want
to
join
and
there's
some
past
context
in
there
for
exploration.
A
A
I
don't
know
yet
so
yeah.
I
think
we
because
of
manifest
lists.
Sorry,
because
of
manifest
lists.
We
may
get
a
lot
of
this
for
free
right.
It's
not
like
with
stacks
where
we
need
to
create
a
special
contract
for
different
kinds
of
things.
Manifestless
should
just
buy
us.
Yes,
it'll
just
pull
the
right
image
from
the
right
thing.
A
lot
of
stuff
works
already,
I
think,
there's
even
a
proof
of
concept
to
me,
the
scope
is
like
pax:
cli
should
build
on
that.
A
Yeah,
they
definitely
need
to
build
two
separate
images
with
the
same
tag
and
different
architectures
for
this
to
work.
But
if
they
do
that
right
now
it
should
work,
but
but
we
we
probably
want
tooling
eventually
right
to
make
that
easier.
E
Has
made
this
a
pretty
yeah,
pretty
good
transition,
because
we
already
sort
of
do
a
lot
of
this,
but
I
think
there
are
some
gotchas
with
like
the
cash
images
and
stuff
like
that,
and
then
there's
also
sort
of
scoping.
As
far
as
like
how
we
want
to
approach
this
because
yeah,
we
could
just
compile
life
cycle
for
arm,
but
we
could
also
like
continue
to
run
fat,
x86
builders
and
publish
arm
images
like
we
have
the
flexibility
to
be
able
to
do
that
now
and
so
like.
E
We
really
got
to
figure
out
what
the
you
know,
but
that
requires
the
bill
packs,
knowing
that
upfront
and
being
able
to
achieve
that.
So,
like
you
know,
there's
a
lot
of
different
scopes
there.
I.
C
Think
yeah,
I
think
that
was
going
to
be
my
question
right
is
maybe
like
as
a
whole.
We
need
to
understand
all
the
different
possible
modes
of
operation
and
then
determine
exactly
which
one
is
the
most
important
for
the
the
majority
of
the
community
and
then
make
sure
that
that
actually
works,
because
I
know
again
like
we
could
get
packed
to
work
on
an
m1
machine.
But
that
doesn't
mean
that
it'll
actually
build
an
m1
container
at
all.
C
A
I
I
definitely
think
we
should
not
let
this
drop
if
that
makes
sense-
or
we
should
really
you
know-
keep
keep
track
of
it
and
make
sure
that
it
gets
prioritized,
because
it's
it's
not
going
to
be
good
for
our
user
base.
If
more
and
more
people
over
time
can
build
stuff
with
docker
files
and
arm
and
can't
build
stuff
with
build
packs
on
arm.
So
I'm
definitely
interested
in
figuring
out
how
I
can
help
kick
start.
That
effort.
A
B
The
newest
version
of
docker
on
m1
actually
is
much
more
robust,
so
we
produce
amd
64
images
when
you
run
with
pac
and
before
I
was
finding
it,
it
was
very
crashy,
but
now
it
actually
can
succeed.
B
A
B
Yeah,
so
they
use
rosetta
for
some
of
their
native
binaries
that
you
run,
but
within
the
run
time
they
use
qmu
under
the
hood.
So
these
linux
bin
formats
extensions
come
out.
They
want
to
qmu.