►
From YouTube: Working Group: June 27th 2023
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
Let's
see
any
new
faces,
I
don't
see
any
new
faces,
so
I
think
we
can
hop
right
into
the
rscs
first
up
we
have
proposed
YJ
binary
is
removed
from
stack.
I
think
that
this
is
actually
ready
to
merge
and
I
think
that
that
can
be
handled
by
Stack
maintainers
entirely
am
I
correct
in
that
cool,
I.
Think
you're
right
in
that
case,
then
I
think
that
we
can
move
on
next
up.
A
We
have
decoupled
dependencies,
Beyond
I
think
you
and
I
are
going
to
talk
about
this
for
a
little
bit,
so
I
might
skip
over
that
and
go
to
multi-arch
really
quickly,
yeah,
so
that
we
don't
eat
up
all
the
time.
Multi-Arch
Jericho.
Are
there
any
questions
or
feedback?
You
have.
B
No
somebody
I
can't
remember
who
it
was
was
asking
me
to
kind
of
create
more
of
a
proof
of
concept
where
I
actually
Implement
some
of
this
stuff
I
have
not
had
time
to
do.
This
I'm
also
wondering
if
I
do
that
it's
kind
of
already
doing
the
work
so
I'm
happy
to
do
that,
and
that's
basically
like
a
proof
of
concept
you
can
use-
and
you
know
if
you
like
it,
merge
it,
but
I
was
waiting
to
get
some
input
on.
Is
that
what
I
should
be
doing?
B
A
So
so,
full
transparency
I
reached
out
to
both
Rob
and
Dan
makuza.
Today,
I've
just
been
busy
and
I
will
be
honest.
I
forgot
to
reach
out
to
them
earlier
and
Rob
I,
don't
know,
you've
been
out
for
a
little
while
so
I
haven't
had
a
chance
to
go
back
and
re-review
any
of
this
and
Dan
mentioned
that
he
would.
A
Let's
quick,
take
another
look
at
this,
but
I
yeah
I,
don't
know
that
I
I,
don't
know
necessarily
what
needs
to
happen
out
of
this.
I
think
that
Dan
mentioned
he
wanted
to
potentially
look
into
making
parts
of
it
more
actionable.
A
But
I
don't
want
to
speak
for
him
because
he's
not
here,
so
it
might
be
worth
you
reaching
out
to
him
and
seeing
if
there's
anything
that
he's
looking
for
I
think
that
it
was
Anthony
who
was
talking
about
potentially
looking
for
more
of
a
proof
of
concept,
I
can
reach
out
to
him
or
I
mean
you
can
feel
free
to
reach
out
to
him
and
ask
if
not
having
that
proof
of
concept
is
a
deal.
A
Breaker
I
I
can
see
your
your
your
hesitance
to
kind
of
just
implement
the
thing
and
then
have
someone
go?
Oh
actually
we
don't.
We
don't
want
this,
and
then
you
know
you've
basically
implemented
it
in
for
nothing
so
yeah.
A
I
guess
I
would
just
be
curious
exactly
what
he
was
looking
for
to
get
him
over
the
edge
on
this,
but
yeah
I
think
that
hopefully
just
some
more
reviews
will
come
out
of
this
soon
and
either
we'll
merge
or
we'll
find
out
what
the
actionable
piece
is,
or
this
okay
cool,
but
yeah
I
can
message
you
after
this
and
it's
Anthony
I,
don't
remember
his
last
name
right
now.
A
Unfortunately,
so
I
can't
tell
you
how
to
reach
out
to
him
once
like,
but
I
I
will
I
will
find
it
out
real,
quick.
B
That's
fine,
yeah,
no
I
mean
I.
Think
I
can
look
back
at
the
previous
notes.
No
worries,
yeah
and
I
also
have
not
been
able
to
attend
all
the
meetings.
So
I
think
it's
been
kind
of.
You
know
like
trying
to
get
everybody
together
in
in
a
room
or
whatever,
to
make
a
decision
and
decide
what
to
do
so.
Yeah
I
do
appreciate
that
I,
don't
I
don't
want
to
put
in
I
want
to
contribute,
but
if
you're
not
going
to
use
it,
then
I
don't
want
to
contribute
for.
A
Sure,
if
you
would
like
to
actually
have
a
more
comprehensive
discussion
with
like
a
larger
group
of
people,
or
at
least
the
stakeholders
that
have
made
themselves
known
in
this
discussion,
we
could
potentially
talk
about
putting
together
an
ad
hoc
meeting
of
you
know
like
yourself,
Rob,
Anthony
and
Dan,
and
just
like
doing
that
at
a
time
that
Dan
would
be
able
to
attend
and
see.
If
you
all
can
have
a
discussion
about
that,
I
can
I
can
mediate.
Setting
that
up.
If
that
would
be
beneficial
to
you,.
A
Right
yeah,
in
that
case,
I'll,
probably
just
put
something
in
like
like
a
message
in
core
Dev
or
something
like
that.
After
this
just
pinging
everyone
individually,
let
me
write
that
down
otherwise
I'll
forget
about
it.
B
A
B
A
In
that
case,
then,
we
can
go
back
to
decouple
dependencies.
I
was
able
to
finally
get
a
little
bit
of
time,
and
my
data
read
through
your
feedback
that
you
had
John.
If
I
could
I
guess
sum
it
up
to
you
and
then
the
larger
audience,
and
then
you
can
give
critiques
on
that
sum
up.
I
think
the
general
idea
of
what
your
big
pushback
for
this
is
is
it
feels
a
little
too
specific
to
be
like
sort
of
a
low
effort
or
low
contact
interface
for
people
to
enter.
A
You
know
like
to
implement
kind
of
any
way
that
they
see
fit.
Your
concern
is
your
concern
seems
to
me
that
we
kind
of
lay
out
a
little
bit
too
much
implementation
detail
and
a
little
bit
too
much
like
this.
Library
needs
to
do
X,
Y
or
Z.
When
that's
not
necessary
for
defining
the
interface
of
these
decoupled
dependencies
logic,
we
could
instead
Define
it
and
then
develop
either
styling
or
come
back
with
further
rfcs
to
sort
of
codify
or
specify
it
or
whatever.
A
C
Yeah
I
I
guess
it's
like
it's.
It
looks
a
bit
too
specific
for
too
many
unclarities
that
are
actually
still
there
right.
So
for
me
it
sounds
like
what
we
can
decide
as
a
community
is.
Do
we
want
to
go
for
a
way
where
pecado
built
packs
and
the
dependencies
they
shift
are
somehow
disentangled
and
deliver
it
separately.
C
Already
get
some
more
responses
in
so
yeah
I
think
that's
the
the
basic
point
to
get
like
to
kind
of
give
more
freedom
to
to
whatever
the
implementation
will
look
like
and
more
decide
on
the
broader
scope
of.
Do
we
want
that?
Do
we
see
that
there's
value
in
separating
dependencies
out
of
the
individual,
build
pack
Terminals
and
then,
like
all
these,
like
the
reasoning
for
why
we
would
do
that
sounds
sounds
really
appealing
right
that
it's
not
like.
C
So
that's
all
sounds
very,
very
solid
and
then
I
I
just
feel
like
it's
like.
Probably
it's
because
this
has
been
boiling
in
Dan's
head
already
for
a
year,
I,
guess
and
that's
why
it
went
to
be
very
specific.
Also
in
in
these
details,
like
it
is
a
reverse
domain
name,
file
system,
folder
structure
and
what
what
not
right
these
things
that
I
think
we
don't
need
to
formulate
them.
That
specific
of
the
RFC.
D
C
A
I
think
I
think
I
think
I
I
agree
with
some
of
your.
Your
larger
sentiments
in
here
I
think
like
stuff,
like
defining
like
oh
yeah,
we'll
have
a
bill
pack
tunnel
structure
that
allows
us
to
restrict
the
version.
Lines
probably
doesn't
need
to
be
defined
in
this
RFC.
It's
probably
something
that
will
intimate,
will
Implement
and
then
we
can
I.
We
can
either
write
that
out
as
like
best
practice
or
as
like
another
separate
specification,
like
we
just
sort
of
evolve.
A
What
the
build
pack
timer
looks
like,
but
I
don't
know
that
it
needs
to
be
part
of
this.
I
am
a
a
little
hesitant,
removing
like
like
removing
something
like
the
reverse
domain
name
structure
and
like
I
mean
I'd,
be
willing
to
quibble.
You
know
we
could
we
could
bike
shed
like
everything
in
this
particular
section,
and
if
we
want
to
do
that,
we
can
I'm
a
little
more
reluctant
to
sort
of
like
Get
rid
of
the
idea
of
like
we
have
a
reverse
domain
name
structure.
A
It
has
this
type
of
file
structure,
and
it
appears
at
this
place
by
default,
but
can
be
manipulated
by
a
an
environment
variable
because
in
my
head
those
are
the
smallest
touch
points
that
we
need
to
actually
Define
an
interface
to
begin
implementation
and
I.
Think
that
if
we
wanted
to
do
something
else
like
like
I,
think
that
there's
lots
of
implementation
underneath
that
that
we
can
continue
like
how
we
actually
deliver
the
metadata
at
what
Cadence?
How
do
we
package
it
with
the
rest
of
the
language?
Family
I?
A
Think
that's
all
stuff
that
would
be
valid
and
worth
talking
about,
but
I
think
that
what
concerns
me
about
getting
rid
of
some
of
the
more
foundational
chunks
like
like
the
basically
the
interface
as
it
stands,
is
that
we
then
don't
have
any
interface
to
begin
to
build
on
that.
C
One
specifically
I
responded:
I
I
guess,
like
the
properties
that
are
currently
in
the
build
pack
terminal,
I've
just
taken
for
granted.
Of
course,
that's
the
interface
to
start
with,
like
how
are
dependencies
describe
so
we
are
just
we're
just
like
the
RFC
is
about
relocating
that
information
right.
C
So
it's
more
about
what
I
wouldn't
Define
is
where
to
exactly
put
it.
Let's
just
just
bring
up
one
use
case
right
if
we
would
consider
the
use
case
where
there
are
some
users
that
have
a
problem
with
a
particular
set
of
version
bumps
and
by
that
they
actually
want
to
control
the
metadata
to
not
do
that
version
bump
right.
Now,
it's
going
to
be
the
easiest.
C
If
such
a
user
could
provide
one
file,
that
has
three
unrelated
dependencies
like
a
tomcat
and
a
Java
and
some
something
else
just
in
one
file,
instead
of
forcing
them
to
start
mounting,
multiple
volumes
in
the
pack
build
Command
right
just
because
the
structure
demands
that
these
files
come
from
entirely
different
files
or
for
oldest
right.
That's
the
concern
I
had
there.
There
could
be
a
use
case
that,
where
this
really
gets
detrimental,
if
you
enforce
such
a
structure,
that
was
one
of
the
thoughts.
A
Okay,
so
so
I
you're
you're,
the
the
quibble
that
you
have
more
is
with
this
reverse
domain
structure
setting
up
but
like
like
something
like
having
a
a
default
platform
to
mount
it
at
and
then
also
having
a
way
to
modify
where
you
would
search.
That's
that's
also.
That's
fine
I.
C
I
commented
that
on
the
whole
section,
because
the
example
is
actually
a
single
thumbnail
file,
I
mean
you
can't
see
it
easily,
but
it's
defined
as
a
single
file.
That's
why
I
mocked
the
whole
block,
but
like
the
content
of
what
a
version
of
what
a
dependency
version
looks
like
I,
guess
that's
just
given
by
what
we
currently
have.
C
C
Similarly,
if
you
want
to
look
into
something
about
like
similar
to
offline,
build
packs
right
where
you
actually
ship
metadata
and
assets,
I
think
it's,
it
might
end
up
to
be
detrimental
if
we
completely
separate
those
into
two
different
mounted
volumes,
one
for
metadata
one
for
assets,
instead
of
allowing
me
to
just
package
up
the
metadata
for
a
tomcat
plus
the
tomcat
and
just
Mount,
that
in
a
peg
build
command
I.
A
I,
don't
necessarily
disagree
with
that
idea,
either
I
I
guess
without
something,
so
I
think
that
we
I
think
that
it's
perfectly
Salient
to
have
or
like
I
I,
think
it's
okay
to
have
an
issue
with
the
reverse
domain:
name:
file,
structure,
output,
I!
Think,
that's!
A
If
you,
if
you
want
to
have
a
qualm
with
that,
you
can
have
a
qualm
with
that
I'm
concerned
about
sort
of
putting
it
aside
for
the
initial
implementation,
because
it
means
that
we
either
have
to
support
an
incredibly
wide
number
of
ways
of
obtaining
the
metadata
right.
So
like,
let's
say
that
we
we
ignore
this
and
then,
as
a
group,
we
decide
that
we
actually
do
want
to
use
this
particular.
A
We
want
to
use
this
or
we
would
like
to
go
to
it
because
we
feel
x,
y
and
z,
but
we
haven't
specified
it
initially
and
we
have
people
that
build
that.
Without
that
specification,
we
then
have
to
set
up
some
sort
of
deprecation
period
for
that
or
enforcing
a
new
specification.
That
would
allow
us
to
do
that
or
support
multiple
ways
of
doing
this
right
so
like
like
I
guess.
A
A
way
to
do
it
like
ID
is
a
optional
field
and
you
search
for
a
top
level
metadata
package,
and
if
it
has
IDs
you
reference
off
that,
but
if
it
doesn't,
then
you
search
the
ID
field
that
you
would
never
like
it
gets.
It
gets
kind
of
complicated
the
more
paths
we
have
to
support
after
the
initial
implementation.
C
It's
like
I
I
guess.
One
thing
I
could
imagine
as
as
an
alternative
is,
if
you
allow
the
structure
in
the
terminal
file.
C
Getting
out
of
this
could
be
easy
right
by
saying
you
can
also
leave
out
some
of
the
structuring
and
leave
the
structuring
to
the
folder
structure
and
by
that
actually
have
a
compatible
path,
but
yeah,
it's
like
you
need
to
start
somewhere.
That's
true,
that's
what
I
meant
with.
Maybe
the
start
of
the
exploration
is
actually
exactly
what's
written.
D
C
The
the
problem
I
see
is
by
already
kind
of
fixating
that
in
the
rfcs,
that's
what
we
are
going
to
look
for.
So
it's
going
to
be
harder
to
actually
discover.
Oh,
let's,
let's
do
it
differently
in
an
exploration
but
yeah.
It's
like
I
I,
don't
have
necessarily
very
specific
things
in
mind
because
we
did
not
start
exploring
anything
on
that.
So
it's
not
that
I
have
some
kind
of
POC
ready
right.
That
shows
this.
C
A
C
C
How
would
that
look
like
if
we
wanted
to
have
offline,
build
packs
with
this
mechanism?
Then
really
just
try
that
out
and
that's
why
I
think
not
too
many
constraints
are
needed
because
it
wouldn't
be
two
different
groups
working
against
the
like
an
agreed
upon
interface,
but
rather
one
group
and
taking
the
end-to-end
scenario
right,
taking
a
build
pack
that
does
install
dependencies
wrapping
that
in
a
builder
that
provides
the
dependencies
and
just
have
a
look.
C
How
that
looks
like
so
to
say
right
and
then
you
don't
need
the
specific
interface,
because
you
don't
really
encode
against
something
that
somebody
else
is
also
working.
Sure.
That's,
maybe
for
a
mode
of
exploration
that
I
would
probably
trigger
here,
but
that
might
not
be
everyone's
feeling
either.
So.
A
So
sorry,
I'm,
just
I'm,
just
trying
to
think
this
through
I
think
that
my
concern
comes
with
the
idea
of
like
putting
something
out.
That
is
like
a
supported
interface,
because
you
know,
if
you
don't
have
a
potential
set
of
implementations
in
in
mind
in
the
the
API,
isn't
quite
controlled
enough.
You
can
end
up
with
a
bunch
of
Divergent
things
that
cause
issues.
A
C
Thing
I
I've,
seen
with
the
with
the
folder
structure,
was
and
I
might
be
wrong,
but
with
with
with
com
example,
a
and
com
I,
don't
know
what
sap
that
a
and
something
else,
I'm,
not
even
sure
if
we
will
be
able
to
mount
multiple
things
into
that.
A
A
And
I
think
that
that's
a
fair
thing
that
I
was
thinking
about
as
well
like
that
I
knew
I
mean
I.
I
saw
yours,
so
I
didn't
necessarily
feel
your
feedback,
so
I
was
like
maybe
going
back
and
adding
some
things
that
I've
been
thinking
about,
can
wait
a
little
bit
but
like
yeah,
changing
the
the
environment
variable
to
actually
be
a
path
environment
variable,
as
opposed
to
like
like
or
like
a
like
a
list
path,
so
that
you
would
have
like
a
lookup
path
like
you
would
normally
be
like.
A
B
Put
a
thought
here
so
if
you
were
to
use
like
the
same
interface
and
data
structure
for
this
reverse
engineered,
sorry
reverse
domain
setup
and
then,
if
you
had
a
flat
Thomas
file
and
they
both
read
in
and
fed
the
same
kind
of
data
structure,
wouldn't
that,
let
you
say:
okay
like
I'm,
either
using
the
reverse
engineer,
path
or
I'm,
using
this
flat
tunnel
file,
either
way
you're
going
to
be
getting
to
the
same
date.
You
know.
A
For
sure,
I,
I
and
I,
don't
necessarily
know
that
that's
unreasonable,
but
you
know
if,
if
it
comes
down
to
the
idea
that
everyone
actually
just
wants
to
use
a
flat
file
or
a
series
of
flat
files
as
I,
probably
guess
it
would
be,
you'd
have
to
find
some
way
to
merge
those.
Then
you
know
like
that
would
be.
That
would
be
like
why
bother
with
having
the
other
format.
B
I
guess
what
I'm
saying
is:
if,
if
the
reverse
engineer,
folder
structure
creates
the
flat
file
on
flying,
if
you
will
like
it
reads
all
those
files
in
and
then
it
populates
one
struct
and
it
puts
you
know
a
list
of
all
the
things
it
finds
in
there.
Then
you
could.
Then
let
people
choose
you
know
like
users
choose
I,
prefer
the
reverse
and
reverse
domain
setup.
Where
I
prefer
this
flat
file
setup,
and
then
you
can
see
you
know,
like
usage
wise.
B
What
is
preferred,
because
you
know
you
might
find
people
actually
went
better
than
the
other
I'm
just
trying
to
think
out
loud.
You
know,
I
think
they're
valid
points
on
both
sides
and
it's
hard
to
really
know
how
painful
it's
going
to
be
either
way
until
you
start
doing
it.
But
if
you
basically
allow
both
to
happen
at
the
same
time
using
the
same
struct,
it
shouldn't
be
a
problem
I'm
just.
C
Thinking
yeah
good
good
point:
if
the
global
structure
right
there's
one
structure
and
that
just
also
needs
some
kind
of
right.
The
dependency
has
some
kind
of
name
spacing
in
there,
so
it
needs
that
because
definitely
on
the
provider
side
I
would
probably
prefer
some
kind
of
full
destruction
instead
of
having
a
terminal
file
that
has
10
thousand
lines
or
whatever
so
yeah.
C
To
actually
say
it,
but
basically
both
just
lead
to
the
same
Global
structure.
It's
just
a
different
representation
of
it.
A
But
but
I
think
that
that
goes
to
what
you
were
saying
in
terms
of
potentially
abandoning
this
as
part
of
that
part
of
the
structure
idea
entirely
and
just
saying,
hey,
this
metadata
file
now
just
doesn't
exist
in
the
same
place
that
it
now
exists
here.
Instead
in
this
folder
or
whatever,
and
it
can
be
mounted
or,
however,
you
want
to
say
it
right
and
whatever
it
might
be.
A
A
Okay,
I
think
that's
I,
think
that
that's
an
interesting
idea
to
drill
down
on.
B
I
might
just
had
a
thought
about
the
multi-arch
RFC,
and
this
one
and
I
I,
don't
know
what
you
guys
are
thinking,
but
I
almost
feel
like
multi-rfc
should
just
be
approved
before
this
one,
because
this
one
seems
like
it's
going
to
require
more
changes
and
it
would
probably
be
easier
to
implement
multi-arch
RFC
in
the
existing
time
or
file
get
used
to
it.
And
then
you
decide
how
do
you?
B
You
know
how
you
want
to
split
it
out
with
this
I
feel
like
if
you're
trying
to
do
both
at
the
same
time,
I
mean
I.
Don't
know
maybe
I'm
wrong
here,
but
it
seems
like
it'd
just
be
easier
to
do
one
than
the
other.
A
I,
don't
know
that
there
are
actually
100
content
contingent
on
each
other.
I
think
that
there
is
obviously
like
this
overlap
of
adding
these
new,
like
distro
and
Arch
and
Linux
fields,
but
or
not
Linux.
Excuse
me,
oh
Fields,
but
I
think
that
this
would
like
this.
These
would
just
like
mirror
each
other
so
like.
If
this
one
came
out
first
and
then
the
multi-arch
one
came
out
first,
we
would
just
like
we
could.
A
Maybe
we
could
maybe
even
be
like
this
is
like
almost
a
problem
where
us
not
having
a
spec
kind
of,
even
though
I
don't
know
that
I
would
ever
want
to
create
a
spectrum.
This
would
it's
kind
of
a
pain
like
we
don't
have
a
definition
for
what
the
standard
for
a
build
pack
metadata
dependency
metadata
looks
like
or
so
like.
A
This
is
how
this
this
wood
look
and
it
kind
of
takes
into
account
what
like
Arch
versus,
not
our
like,
like
multi-arch,
would
look
like,
or
at
least
being
able
to
distinguish
between
them.
Yeah
but
I.
Don't
know
if
that's
sufficient,
so
I
understand
what
you're,
saying
and
I
think
that
it
would
just
require
either
a
back
like
a
like,
like
a
back
port
or
something
else
for
this
I.
B
Guess
what
I'm
saying
is
this
I
think
in
terms
of
what
is
important
for
a
user?
It's
much
more
important
for
me
to
get
multi-arch
support
than
it
is
for
you
to
get
your
dependencies
fixed
and
make
it
easier
for
you
to
build
your
buildbacks,
so
I'm,
just
trying
to
say,
like
priority,
wise
I
really
want
a
multi-arch
I.
Don't
this
this
I
understand
we
need
to
do
the
multi-arch
is
more
important,
I
feel
like.
B
So,
if
you
were
to
prioritize
unless
it
just
comes
along
quickly
and
easily
I'm,
just
trying
to
put
that
out
there
like
I'm,
happy
to
work
towards
a
multi-arch
stuff.
But
you
know
if
it
gets
sucked
into
a
bigger
project
and
then
that's
going
to
take
a
lot
of
planning
to
go
and
change
I'm.
Just
trying
to
kind
of
like
think
about
that
and
put
that
out
there.
C
I
would
say
we
should
try
not
to
build
a
dependency
in
either
direction
for
those,
but
I
tend
to
agree.
This
might
be
a
larger
effort
than
the
than
the
multi-artges,
although
I
haven't
ducked
into
the
details.
So
maybe
that's
also
quite
some.
Some
things
to
consider
and
and
work
on
so
I
tend
to
agree,
but
I
think
there's
no
real
hard
dependency
on
it.
I
I.
D
B
A
Just
does
picking
up
as
data
I'm
I
think
I
I
think
that
I
now
have
a
better
understanding
of
where
what
what
the
the
concerns
you
have
are
I,
don't
know
that
I
have
a
good
solution
or
a
good
particular
rewrite
I.
So
I
think
that
I
will
have
to
think
about
this
and
probably
talk
to
some
people
about
it.
Just
to
try
and
figure
out
like
what's
the
what's
the
best
way
for
us
to
to
do
this,
but
yeah
I.
A
A
Is
there
is
there
anything
else
that
people
would
like
to
talk
to
about
talk
about
on
this.
A
All
right,
I
think
that
that
means
we've
made
it
all
the
way
through
our
rfcs.
So
we
can
get
into
the
rest
of
our
agenda.
I
don't
have
any
CMP
updates.
A
A
Yeah
I,
don't
have
any.
The
only
discussion,
slash
Open
Mic
topic
is
I
will
be
out
on
vacation
next
week
during
the
time
that
this
working
group
meeting
happens,
which
I
believe
is
the
fifth
I
would
love
if
someone
would
be
willing
to
run
this
meeting.
Otherwise,
you
will
be
stranded
and
alone.
A
But
other
than
that,
I
think
that
that's
all
that
we
have
on
the
agenda
for
right
now.
B
Cool
I
was
going
to
say,
does,
does
that
have
to
be
run
by
somebody?
You
know
at
VMware
like
whoever
joins,
can
just
run
and
call
it
a
day.
A
The
second
you
log
into
this
meeting
it
starts
recording
and
when
everyone
leaves
it
stops.
Okay,.
B
Yeah
I
have
to
check
my
calendar
if
I'm
going
to
be
around,
but
if
I'm
here
I'm
happy
to
run
it.