►
From YouTube: Backlog Bonanza, Part 1
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).
B
Well,
honestly,
why
don't
we
just
take
notes
directly
into
a
zoolop
stream
and
then
for
the
most
part,
we
will
be
taking
notes
in
the
rfcs
themselves.
A
Okay,
that's
fine,
I'm
still
making
a
paper
document,
but
that's
a
good
idea
reason
is
I'll.
Put
out
the
link.
I
wanted
to
try
to
also
emerge
with
a
like.
A
Let
me
share
this.
I
wanted
to
emerge
with
a
sort
of
scat
I
figured
we
might
emerge
in
sketches
of
like
what
are
the
stages
we
see
things
at
and
what
are
some
of
the
notable
candidates
in
there
and
that,
like
other
dimension
of
organization,
could
go
into
the
duck
and
it's
not
something
that
isn't
amenable
for
random
streaming
of
comments.
That.
B
B
B
So
rfcs
seem
like
they're
the
more
critical
backlog
tracking
issues,
so
there's
a
different
kind
of
disposition.
I
would
say:
rfcs
are
more
about.
Do
we
still
care
about
this?
Do
we
want
to
support
working
on
it?
Should
it
be
a
project,
group,
etc?
Tracking
issues?
Half
of
them
are
going
to
be
things
that
have
been
implemented
and
we
need
to
talk
about.
Are
they
stable
yet
what's
their
status?
All
that
kind
of
thing.
I
imagine
that
we
could
get
through
10
tracking
issues,
or
you
know,
30
rfcs,.
A
I
find
tracking
issues
more
interesting
in
the
sense
that
they
show
off
more
parts
states
of
project.
However,
I
agree
with
you
that
rfcs
are
more
urgent
in
some
sense,
because
people
have
been
waiting
somehow,
let's
start
with
those,
it's
probably
always
good
to
start
at
the
beginning.
Anyway,
let
me
just
make
my
what
are
the
labels
anyways,
like
searches,
that's
the
tracking
issue,
and
I
think
I
thought
it
was
a
good
starting
place
to
include
this
random
label.
B
So
those
would
be
the
ones
that
are
not
yet
implemented.
We
should
also
look
at
the
ones
that
are
implemented.
I
think
this
is
both.
B
C
B
A
This
is
sort
of
other
tracking
issues.
I
guess
all
right,
so
rsc
is
oldest
first
oldest.
B
A
Yes,
so
target
extension.
Even
is
this:
it's
pretty
old.
A
A
B
But
maybe
I'm
wrong,
I
think
one
thing
I
would
wonder
is
is
a
problem
of
like:
are
they
actually
solving
the
problem?
Is
we
want
to
process
things
in
a
way
that
depends
on
the
underlying
version
of
the
os,
but
that's
right.
This
has
to
do
with
bsd
being
backwards
incompatible
from
time
to
time
right.
B
A
Yeah,
okay,
targeting
bsd,
which
makes
avi
changes
regularly.
So
I
think
I
guess
I
would
call
this
like
if
there
was
somebody
who
really
was
motivated,
I'm
not
like
opposed
to
it,
but
it's
not
something
right.
It
doesn't
really
fit
any
of
our
objectives
and
it's
not
something
we
would
encourage
you
per
se.
B
B
C
A
B
C
I
would
also
maybe
suggest
that
we
have
sort
of
some
sort
of
like
this
doesn't
really
need
to
be
an
rfc
like
we
would
maybe
start
with
not
an
rfc,
or
at
least
I
would
suggest
that
something
like
this
would
better
be
sort
of
an
unstable
feature.
That's
just
added
to
the
compiler,
because
it's
so
low
impact
and
then,
if
like
it,
it
seems
useful
and
we
gain
experimentation.
A
A
C
It
looks
like
it
adds,
dwarf
unwinding
information
and
like
back
traces
to
macros,
basically,
which
seems.
C
Well,
it
would,
it
would
add,
to
like
we
admit,
debug
info
for
macros
with
this
rfc.
So
today
we
sort
of
just
treat
them
as
want
to
say
we
only
like
the
final
expansion
is
treated
as
like
its
own
file
or
something
like
that.
A
So
okay,
you're,
saying
like
if
I
hit
back
trace,
I
would
see
the
macro
expansion
part
that
that's
why
I
mean
this
is
another
one
of
like.
I
think,
if
we
I
think
it,
it's
kind
of
never
gonna
fit
any
of
our
priorities
unless
one
of
them
is
explicitly
like
improved
rusty
butter
story,
but
it
also
feels
like
a
place
where
it
would
probably
be
more
of
a
let's
tinker
on
the
compiler
side
and
get
it
working,
and
I
don't
know.
C
B
A
I
just
disabled
my
video,
because
I
was
having
a
lot
of
issues
I
don't
know.
Hopefully
maybe
it'll
be
better,
I'm
not
sure
if
that
was
related
to
any
noise,
but
so
all
right.
So
this
seems
like
there's
some
status.
I
don't
know
quite
how
to
describe
it,
but
it's
like
implementation
first
or
something.
A
A
B
A
B
B
A
mechanism
for
the
body
of
unsay
functions
to
no
longer
be
unsafe
and
you
still
have
to
write,
unsafe
and
because
you're
implementing
it,
but
the
actual
body
of
the
function
will
not
assumed
to
be
unsafe.
A
Yeah
by
the
way,
you're
like
something
is
clipping
in
and
out
with
your
audio,
at
least
on
my
side
but
yeah
I
was
gonna
mention
that
interaction.
I
remember
somebody
talking
about
that
as
a
motivation
for
making
the
body
of
unsafe
functions
not
unsafe,
and
I
have
to
say
I
think
this
rfc
does
it
better
like
if
your
intent
is
to
show
you're
not
using
unsafe
code,
it's
even
clearer
if
you
don't
make
the
function,
declare
it
as
unsafe.
B
This
is
an
unsafe
fin
whose
body
happens
to
be
safe,
but
it's
still
an
unsafe
fun,
because
there
may
be
expectations
you
must
be
needing
to
meet
and
you
shouldn't
just
be
able
to
omit
the
word
unsafe,
but
still
implement
something
that
might
cause
you
be
elsewhere.
A
So
that
I
think
you're
talking
about
this
last
bullet,
which
is
to
say
right
now,
there's
some
kind
of
ambiguity
about
in
some
sense.
So
you
could
imagine
there
being
an
ambiguity
where
you
might
say
this
function
is
actually
unsafe
to
implement,
because
you
have
to
make
sure
that
you
meet
some
post
condition
right
and
this
rfc
kind
of
clarifies
that
no,
it
does
not
mean
that
it
can
only
mean
this
function
is
on
facebook.
A
A
So,
in
some
sense,
I
think
this
actually
fits
our
priorities,
but
in
the
loosest
sense,
like
we
have
this
unsafe
code
guidelines,
effort
which
I
think
is
a
kind
of
priority
of
like
nailing
down
our
semantics
and
figuring
stuff
out
that
we've
been
putting
off
too
long.
It's
a
vague
priority,
but
it's
a
priority
and
I
think
it
fits
into
that
bucket
whether
or
not
we
want
to
do
it.
We
can
discuss
separately,
but
I
would
fit
it
in
that
heading
unsafe
code,
guidelines.
B
A
A
I
think
that's.
The
way
I
would
have
preferred
it
to
be
is
that
we
have
some
people
who
are
working
around
unsafe
and
they
decided
like
one
of
the
priorities
they
want
to
make
is
stuff
like
unsafe
function
and
using
the
unsafe
keyword
in
the
unsafe
function
body
it
fits
in
with
that
it's
kind
of
a
let's
define
what
unsafe
means
in
rust,
and
one
of
that
might
one
of
those
bits
of
that.
A
B
Would
there
be
any
objection
if
I
were
to
nominate
this
for
a
brief
discussion
in
the
next
lang
meeting
just
to
say,
is
this
the
a
question
we
agree
with.
A
A
A
A
A
A
A
Nobody
really
understands
are
hygiene
all
that
well,
but
it's
not,
I
guess
I
would
say
like
I
wouldn't
want
to
go
forward
with
this,
certainly
not
without
petroshenko
and
really
probably
without
somebody
having
like
anybody
else.
Besides
patrician
go,
so
we
have
multiple
people
who
understand
that
hygiene,
and
especially
someone
who
can
like
bring
it
to
the
lane
team
meeting
and
communicate
it
well
to
us,
because,
in
other
words,
not
till
we
play
down
our
name
resolution
again.
B
Right,
I
do
have
one
interesting
observation
from
poking
at
the
compiler
implementation
of
inline
azim
here,
which
is
because
we
don't
have
eager
macro
expansion
macros
that
need
to
deal
with
things
like.
I
need
a
string
constant,
but
I
could
potentially
accept
a
concat
of
string.
Constants
have
to
manually,
say
I
want
to
evaluate
my
first
argument
and
then
see
if
my
first
argument
ended
up
being
a
string
literal
after
expansion.
B
A
B
A
B
A
Yeah,
that's
the
example
is
usually
like
they
used
arc.
For
this
reason,
arc
of
t
is
cloned,
no
matter
what
t
is
so
so
you
don't
need
to
be
cloned
and.
A
Arguably,
backwards,
there's
a
back,
raising
compatibility,
sort
of
addition,
related
question
in
my
view,
because
if
you
have
it's
a
pretty
much
of
a
long
shot,
but
you
can
imagine
that
you
have
a
struct
where
yeah
it
doesn't,
strictly
speaking,
it
doesn't
need
to
be
cloned,
but
for
some
reason
you
want
it
to
have
that
meaning.
I
think
it
is
more
likely
with,
like.
C
I
think
it's
more
of
a
problem
like
derive
clone
in
some
sense
is
the
easy
case,
because,
most
of
the
time
when
you're
writing
it
yourself,
your
the
compiler
will
catch
you.
If
you
forget
a
field,
if
you're
doing
something
like
partial
eek,
then
it's
really
easy
to
add
a
field
and
then
forget
to
add
it
to
partially.
If
you've
enjoyed
it
yourself.
A
A
No
support
for
really
catching
that
today
I
always
write
partially
in
a
you
know
specific
way
to
avoid
that,
but
that
most
people
probably
don't
do
that
because
they're
not
masochists,
but
also
like
it's
just
it's
annoying.
It's
just
boilerplate
annoying
like
clone,
is
even
clones
just
annoying
code
to
write
a
lot
of
the
time.
B
So
another
question
would
be:
is
this
something
that's
common
enough
that
it
should
be
in
the
standard
derive
of
clone
or
partial
eek?
Or
would
this
be
done
well
with
a
macro
of
some
kind
that
could
live
in
the
ecosystem?
C
And
I
think
the
argument
is
more
so
that,
like
today,
if
you,
for
example,
if
you
have
like
serie
a
and
then
partially
and
all
the
others,
then
pretty
much,
every
macro
that
is
on
great
cio
is
going
to
have
its
own
version
of
this.
Whereas
if
we
have
these
standardized,
then
everybody
can
just
go
off.
A
Okay,
I
don't
know
an
ergonomic
win.
I
think
I
think
it's
again,
one
of
those
like.
B
A
A
A
I
want
to
write
food.bar,
but
I
guess
a
specific
example.
Today
we
have
channel.send
of
a
value.
Send
is
a
inherent
method,
that's
top
priority.
It
might
be
nice
to
extract
a
trait
channel
methods.
A
That
has
send
so
that
other
things
can
implement
it,
but
now
now
it's
not
inherent
method
that
ambiguities
you
have
to
import
the
trait,
so
what
people
often
do
is
add
like
both
validates
to
the
other.
Sorry,
that's
annoying
and
boilerplatey.
A
This
just
came
up
and
talked
about
the
day.
I
don't
know
like
this
actually
comes
up
to
me,
a
fair
amount
in
some
way
or
another,
but
not
right
away,
not
for
a.
A
A
A
A
A
B
So
the
premise
of
this
is
that,
if
you
have
the
type
in
scope,
then
you
don't
necessarily
have
the
entire
trait
in
scope.
But
you
have
the
fact
that
this
particular
type
implements
the
trait
in
scope.
A
B
Thing
so
you
can
call
dot,
send
without
importing
channel
methods,
and
you
could
pass
the
channel
to
something
that
asks
for
an
impul
of
channel
methods
right
right,
even
though
you
don't
have
the
name
channel
methods
in
scope,
yes,
but
the
latter
is
always
possible
passing
to
a
method,
but
the
good
point,
just
the
dot
notation.
A
A
B
A
No,
it
doesn't
affect
name
resolution,
it
affects
the
compiler's
method,
dispatch
logic,
but
I
don't
think
it
would
be
especially
complicating
in
terms
of
the
implementation
be
a
bit
of
a
pain
but
not
too
bad.
B
A
Yeah,
my
main
hesitation
would
be
whether
we
wanted
whether
the
delegate
solution
is
actually.
B
A
I
want
to
circle
back
to
the
question
of
what
is
the
expected
outcome
of
this
for
40
minutes
in.
I
think
this
is
useful,
but
what
I
don't
want
to
have
happen
is
that
we
spend
hours
and
hours
going
over
this
and
then
we're
just
sort
of
done.
So
we
have
to
have
some
like
what
are
the
resolutions
that
each
we're
trying
to
slot
each
of
these
rfcs
into
and
I'm
not.
Maybe
we
can
discuss
what
those
are
a
bit
for
a
second.
B
A
B
Recommended
next
steps
do
seem
like
a
good
idea,
but
also
if
we
have
an
inclination
that
the
right
next
step
is
either
that
we
should
accept
something
or
that
we
should
reject
something.
Then
I
think
that
that's
what
fcp
is
for.
We
should
go
ahead
and
invoke
it
and
then
see
what
other
language
team
members
think.
B
A
B
A
I
have
this
fear
that
we're
going
to
suggest
people
that
they
file
a
bunch
of
mcps
and
then
close
the
mcps,
because
there's
like
no
people
to
do
liaison
with
them,
but
so
that's
probably
why
I
don't
necessarily
want
to
take
action
at
the
moment
because
some
of
the
ones
we
think
we
might
want
to.
I
might
like
to
go
to
you-
don't
have
that
many
potential
liaisons
at
this
time.
Maybe
we
can
pre
rediscuss
and
decide.
A
Would
we
think
that,
like
might
be
good,
but
there
are
you
can
file
an
mcp
but
you're
not
gonna,
get
anybody,
I
don't
know
or
we're
interested
we're
putting
it
on
this
delayed
column.
Something
like
that.
B
I
think
if
we
both
completely
agree
with
the
problem,
and
we
think
that
the
solution
seems
like
the
obvious
one
and
we
don't
think
that
there's
value
in
kicking
somebody
back
to
an
mcp
and
saying
consider
other
possibilities.
A
A
A
So
what
do
we
do
if
all
of
these
things
are
what
extent
do
we
want
to
try
to
refigure
out?
How
much
like,
should
we
just
assume
in
a
pool
of
liaisons
and
then
an
issue,
a
warning
that,
by
the
way
like
we're,
not
sure
which
of
these
things,
this
is
the
first
round
of
and
like
based
on
why
mcp's
come
and
what
happens
they
may
or
may
not
get
you
know
you
might
get
deferred
on
that
basis,.
B
B
I'm
also
hoping
that
I
I
would
like
us
to
be
in
a
state
where
we
have
a
backlog
of
in
our
tagged
as
we
have
a
couple
of
potential
liaisons,
and
they
don't
have
time.
Yet.
I
think,
having
our
visible
time
cues
out,
there
is
important.
B
B
Yeah,
I
think
we
should
have
the
concept
of
being
implemented,
implemented,
being
tested
being
stabilized,
etc.
A
And
it
probably
wants
we
may
even
want
two
project
boards
like
to
separate
out
the
like
proposals
and
stuff,
that's
very
early
stage
from
the
stuff
we're
actively
doing
and
maybe
shortlisted
things
so
that
it's
kind
of
like
if
you
want
to
follow
along
you
go
to
the
one
you
see
what's
happening
now
like
if
you
want
to
get
involved
and
hack
or
something
that's
kind
of
a
useful
place
for
that.
You
go
to
the
other,
and
you
see
like
the
very
early
stage
discussions
that
are
going
on.
B
Effectively,
something
would
graduate
from
one
board
to
the
other
when
it
is
accepted,
and
it's
no
longer
in
the
you
know
we're
thinking
about
it
phase
it's
in
the
somebody
needs
to
do
the
work
phase.
A
B
Yeah,
I
think
file
and
mcp
we'd
like
to
see
a
project
group
solve
it
and
we'd
like
them
to
consider
whether
you
know
how
it
should
be
implemented,
whether
it
should
use
target
triples
or
some
new.
You
know
other
thing
I
don't
want
to
get
into
the
weeds
on
details.
I'm
saying
this
is
what
we
want
the
project
group
to
evaluate.
A
B
A
I
feel
like
we've
written
them
down
a
few
times,
and
it's
always
I'm
always
like
losing
track
of
it,
but
I
think
they
are
or
where
was
that
hackmd
language,
team
ideas
and
parodies
is
that
it?
I
don't
know,
is
this
some
other
random?
I
have
so
many
with
the
same
names.
A
A
A
A
Sorry,
you
cut
out
there
a
little
niko.
What
was
that
I
said
I
wanted
to
be
able
to
say
for
each
thing
that
we
say
file
an
mcp.
What
priority
it
connects
to.
I
think
target
extension.
2048
does
not
really
fit
a
priority,
so
the
only
argument
in
favor
of
it
is
that
it's
relatively
small
and
if
someone
else
does
most
of
the
work,
we're
not.
A
A
I
guess
there's,
I
think,
there's
some
precedent
here
that
I
wouldn't
actually
mind
setting,
which
is
that,
basically,
that
the
compiler
team
has
some
room
to
make
small
attributes
and
other
things
in
the
language,
and
we
should
be
like
we
can
be
brought
into
the
process
but
to
approve
it
in
the
end
of
the
day
and
sort
of
and
so
forth,
but
like
it
doesn't
require
an
rxc.
A
A
Okay,
so
over
committing
and
under
committing
unsafe,
I
think
the
answer
is:
what
is
our
suggestion
here?
It's
probably
like
close
or
mcp.
A
A
But
because
it
feels
like
it,
I
guess
I
would
say
clothes
and
discuss
with
ralph
and
discuss
with
safe
code
guidelines
like
I
think
there
will
be
times
that
there's
an
existing
group.
That's
dealing
with
that
stuff,
and
somebody
proposes
something
more
like.
Why
don't
you
bring
it
up
in
that
group
and
see
what
they
think
about
it
now,
in
this
case,
I
think
gancia
kogai
language
is
in
a
weird.
B
Okay
should
when
you
say
closed,
should
this
be
an
rfc
bot
close.
A
A
I
think
it
should
require
at
most
one
other
box
check,
and
maybe
none
and
just
be
like
once
you
close
it
go
straight
into
scp,
but
still
we
should
do
it
and
we'll
just
worry
about
fixing
rfc
later,
okay.
A
B
So
I
had
a
suggestion
in
this
context,
which
was,
let's
poke
a
couple
of
people
who
are
experts
on
name
resolution
and
talk
to
them
about
whether
this
would
be
a
net
improvement
in
technical
debt
to
do
or
whether
this
would
add
to
technical
debt.
B
If
they
say
it's
a
net
improvement,
then
we
could
consider
accepting
it
if
they
say
it's
a
net
increase
in
technical
debt,
let's
at
the
very
least,
postpone.
A
A
A
Yo,
okay,
maybe
I
I
think
that's
fine.
I
feel
like
I
kind
of
already
knew
the
answer,
but
I'm
mostly
wondering
who
to
poke,
but
could
it
be.
A
A
You
know
we've
been
talking
about
documenting
our
priorities
and
both
of
these
two
fit
with
me
in
some
sense
of
like
it
would
be
nice
if
we
just
had
a
list
of
known
ergonomic
hurdles
and
we
could
sort
of
say
you
have
a
priority
to
solve
this
ergonomic
problem
or
bundle
of
problem
or
like
some
subset
of
this
bundle
of
problems
and
we're
interested
in
solutions
and
both
of
these
fit.
In
my
mind,
like
I
would
like
these
are
both
well-known
annoying
things.
A
It'd
be
nice
if
we
listed
them
somewhere
and
we
could
say
what
we
feel.
That
said,
I
think
my
suggestion
is
close,
but
even
though
I
want
it,
I
don't
know
my
reason
is
it's
a
tart.
It
fits
under
targeted
ergonomic
wins.
I'm
just
worried
that
it's
like
it's
not
closing
out
something
that
we've
been
working
on.
It's
like
adding
new
things
to
our.
A
A
A
A
A
B
B
So
mcp
nico
as
possible.
B
A
Like
does
it
really,
it
probably
wants
an
mcp,
but
in
some
sense
rfc
is
already
well
well.
I
guess
the
reason
that
it
won't
go
on
a
short
list:
yeah.
Okay,
it's
fine
inherent
trait
implementations.
B
C
So
one
of
the
concerns
with
this
that
I
didn't
see
at
a
quick
glance
in
the
rfc
is
that
it
probably
gets
into
questions
about
whether
this
trait
like
would
it
be
inherent
in
the
global
crate
or
or
is
that
like?
What
is
the
coherence
implication
of
inherent
methods.
C
Well,
so
normally,
if
you
have
like
an
extension
trait
the
reason
that
anybody
can
define
an
extension
trait,
as
I
understand
it-
is
that
defining
an
extension
trait
doesn't
actually
like
override
anybody's
sort
of
what
they
see
and
what
they
call.
But
if
you
anybody
can
add
sort
of
their
own
extension
trait
and
call
it
implement
it
for
whatever
type
and
call
that
an
inherent
impul.
Then
I
mean.
B
Right,
the
other
option
would
be
to
just
lint
against,
like
not
lint
but
error
against
doing
it
outside
of
the
module.
So.
A
A
Maybe
that's
me
trying
to
generalize
too
much,
I'm
open
to
that,
but
that
would
be
my
ideals
that
we
have
like
a
project
group
that
says
first,
we're
gonna
do
this
problem,
then
we're
gonna
solve
delegation,
and
then
you
know
we're
gonna
have
like
that,
but
maybe
I'm
trying
to
get
people
to
do
too
much
and
it's
better
to
go
step
by
step
anyway.
So
if
we
identified
a
liaison
that
wouldn't
be
opposed,
I
guess
I
also
think
it's
weird
to
just
merge
this
2017
rc
out
of
the
blue.
B
I
do
think
the
argument
that
you
that
mark
just
made
that
there
is
a
thing
that
needs
considering,
is
important
enough,
that
we
can't
just
fcp
merge
this.
I
do
think
it's
worth
going
ahead
and
saying:
okay,
we
basically
agree
that
we
want
this
feature
we're
disagreeing
on
like
the
exact
way
it
should
work,
and
so
we'd
like
to
see
this
move
forward.
B
A
A
Group
at
mcp
yeah,
which
I
think
is
going
to
imply,
closing
and
reopening
it
some
fresh
discussion
and
fresh
eyes.
You
know
I
think
there
are
rfcs
in
here
that
there's
one
specific
one,
that's
been
on
my
mind.
A
I'm
inclined
to
merge
this
rs
right.
It
does
generic
apis
for
manipulating
the
metadata
of
fat
pointers.
This
feels
like
yeah,
it's
visible,
but
you
know
I
don't
know
what
I
have
to
go
reread
it,
but
I
remember
the
last
time
I
read
it.
I
thought
it
was
fine.
I
don't
know
what
they
don't
think,
there's
a
whole
lot
of
community
input
that
you
know
they'll,
be
really
surprised
that
these
methods
should
be
gonna,
be
a
problem,
but
in
contrast,
I
do
think
a
big
feature
like
this.
B
B
More
stability,
the
idea
of
supporting
these
apis
makes
a
lot
of
sense.
The
idea
of
I'm,
assuming
that
these
abi
apis
still
need
to
wait
quite
some
time
and
bake
before
they
ever
consider
becoming
stable.
A
Probably,
but
they,
the
goal
of
the
rfc
was
to
design
a
very
minimal
set
of
apis
that
don't
preclude
any
of
the
things
people
want
to
do
in
the
future,
so
they
should
bake
and
just
because
all
apis
should
bake,
but
they
were
designed
for
quicker
stability
and
like
designed
not
to
be
intentionally
unambitious
in
terms
of
what
capabilities
they
expose.
If
that
makes
sense,.
B
B
Is
do
these
prevent
the
compiler
from
being
smarter
in
the
future
of
saying,
oh
well,
it
turns
out
that
I
know
exactly
what
type
this
is,
so
I'm
not
going
to
bother
storing
it
as
a
fat
pointer.
A
A
I
don't
think
the
compiler
can
just
just
can't
do
that
or
if
it
can,
it
can
only
do
that
for
like
local
variables,
and
in
that
case
it
wouldn't
be
precluded
because
it
can
sort
of
if
it
knows
the
type
it
can
kind
of
reconstruct
the
metadata
on
the
fly.
When
you
ask
for
it
yeah,
okay,
that
makes
sense
jordan.
The
heap
is
gonna.
B
I
would
be
in
favor
of
doing
this
regularly,
but
I
also
think
that
we
may,
I
would
personally
prefer
to
schedule
it
on
a
monday
or
wednesday
rather
than
on
a
friday.
A
B
Yeah
as
another
alternative,
I
would
also
be
happy
to
just
have
like
a
four-hour
session
on
a
monday
and
just
work
through
four
times
as
much
of
this
yeah
I'd
be
okay
with
that
too,
but
not
this
money
sure
I
would
be
quite
happy
to
do
that
a
week
from
monday.
A
All
right,
why
don't
we
discuss?
Let's
not
make
this
decision
in
this
call,
but
we
can
discuss
it
on
zulu.
I'm
trying
to
decide
maybe
a
week
off
is
a
good
idea,
because.