►
From YouTube: 2021-02-02 Lang Team Triage Meeting
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
Hello,
everyone
welcome
to
the
february
2nd
19th
meeting.
I
have
we're
josh
and
I
are
slowly
getting
better
at
doing
our
pre-triage,
but
we
we
still
spend
too
much
time
chatting,
so
we
didn't
get
all
the
way
through,
but
we
had
some
good
ideas.
Among
other
things,
we
have
created
a
lang
team
action
items,
hack
md
that
will
persist
across
meetings
for
us
to
track
action
items
both
for
clarity
and
because
then
we
can
see
if
they
are
done
along
those
notes.
A
I
think
a
lot
of
these
didn't
happen,
including
some
of
mine,
so
we
can
go
over
them
briefly
in
a
second,
but
I've
linked
it
from
here.
A
Okay,
so
tomorrow
there
we're
gonna,
do
something
new
for
the
design
meeting
tomorrow
the
plan
is
to
change
our
process
as
josh
is
taking
the
notes
here.
The
first
meeting
of
every
month
is
going
to
be
a
planning
meeting
for
the
remainder
of
the
month,
where
we'll
go
over
the
open
issues
and
assign
meetings.
So
please
join
us.
A
The
other
thing
we're
going
to
start
doing
is
using
half
of
that
meeting
to
review
active
projects
and
what
I
meant
to
do
in
the
beginning
of
this
week
that
I
forgot
to
do,
but
I'll
do
after
the
meeting
is
to
go
ping,
everybody
who
has
an
active
project
and
encourage
them
to
leave
updates
for
that
purpose.
A
Okay
cool
and
on
that
note,
let
me
write
down
a
quick
note,
didn't
remind
myself
actually
I'll,
just
put
that
in
the
action
items
list.
Uh-Huh.
Okay,
2021-0202
me
go
to
adjust
calendar
for
design,
meeting
and
ping
folks
who
lead
projects.
Okay,
let's
move
on
yeah.
I
think
I
think
what
we'll
probably
wind
up
doing
is
josh
and
I
have
a
whole
bunch
of
random
policy
proposals
that
we
want
to
put
forward
I'll
try
to
get
that
in
a
doc.
A
I
don't
know
if
we'll
end
up
discussing
them
tomorrow
or,
if
we'll
schedule
a
meeting
to
talk
about
them,
but
we'll
figure
it
out
all
right,
I'm
going
to
skip
over
the
project
board
when
has
any
urgent,
because
we're
going
to
review
it
tomorrow,
unless
anyone
has
any
urgent
comments
that
they
would
like
to
raise
now.
B
B
A
I
think
that
would
be
appropriate
yeah.
We
can
discuss
that
tomorrow.
Let's
talk
about
it
after,
but
that
doesn't
make
sense
one
other
thing
I
want
everyone
to
know.
Boats
has
stepped
step
back
from
the
laying
team
for
a
while.
A
C
You
mean
like
a
meeting
topic
at
some
time.
Is
there
a
plan
at
some
point
to
discuss
that
that
topic.
A
It's
definitely
on
my
mind,
I'd
be
happy
to
discuss
it.
That's
fine.
A
Agreed
yeah
yeah.
I
have
a
lot
of
thoughts,
although
I've
probably
expressed
them
to
all
of
you
from
time
to
time,
but
I
definitely
think
we
need
to
put
some
energy
into
recruitment.
A
So,
okay,
we
got
some
p
high
issues
deny
after
forbid
breaks,
build,
and
we've
discussed
these
before
for
bid
warnings.
There
is
actually
a
pending
pr
by
me
that
fixes
these
problems,
I'll
just
briefly
say
what
it
does.
It's
not
exactly
what
we
said
in
the
meeting
before,
because
I
realized
that
didn't
make
sense.
What
it
does
is,
if
you
have
a
forbid
on
a
lint
group,
and
then
you
allow
it
or
something
else,
it
issues
a
future
compatibility
warning
but
allows
the
allow
to
continue.
A
So.
The
reasoning
for
this
is
eventually
that
future
compatibility
warning
will
become
an
error,
and
so
you
would
get
the
error
you
expect,
but
respecting
the
allow
means
that
existing
derives
that
actually
trigger
the
the
lint
that
is
forbidden,
which
used
to
build
will
continue
to
build,
basically
because
otherwise
we
would
have
a
problem
where
you'd
be
getting
new
errors
that
you
weren't
getting
before.
So
that's
what
the
pr
does
and
I
think
we're
expecting
to
land
it
very
soon.
A
Any
notes
or
concerns
I'll
put
some
notes
on
that.
C
A
Yeah,
the
other
thing
I
will
say
about
this
lint
is
that
this
lint
is
exempted
from
warnings
from
being
a
member
of
the
warnings
group,
because
otherwise
forbid
warnings
would
then
trigger
the
lint,
which
would
then
be
an
error
which
would
not
not
work.
A
Also,
the
warnings
group
is
very
weird.
I've
discovered
and
as
far
as
I
can
tell,
it,
actually
means
lints
that
are
warnings
right
now,
as
opposed
to
links
that
are
warnings
by
default.
Yes,
interesting,
which,
like
it's
it's
handled
very
special
case
in
the
compiler,
but
one
side
effect
of
that
which
I
did
not
try
to
fix,
is
if
you
do
something
like.
A
Oh,
I
don't
remember
my
exact
example.
I
think,
if
you
like,
forbid
unused
and
then
like
allow
warnings
or
something
that
doesn't
cause
an
error,
because
at
that
point
unused
is
not
a
warning
anymore.
It's
now.
It's
now
a
deny,
so
the
allow
has
no
effect
something
like
that.
It's
weird
it's
weird
but
yeah
I
didn't.
I
didn't
touch.
That
sounds
like
something
that
may
not
have
been
designed
properly
yeah.
I
think
it
was
a
yeah
unintended
design,
choice,
yeah.
D
A
Right,
I
don't
believe
it
has
any
effect
on
unsafe
if
I'm
I'll
double
check
and
if
so
I'll
exempt
unsafe
from
that.
But
but
I
will.
A
A
Happen
right,
I
would
say
that
I
also
think
we
can
move
fairly
swiftly
to
make
this
a
hard
error,
and
we
need
to
get
better
at
closing
out
future
compatibility
warnings
and
having
like
a
fixed
schedule
to
follow
up
on
them.
It's
kind
of
a
compiler
team
problem.
C
B
B
C
A
I'll
just
put
a
note
to
your
effect,
though
josh.
If
we
convert
a
lint
into
a
group,
it
should
be
exempted
to
avoid
and
we
should
move
swiftly
to
make
this
a
hard
error,
as
there
wasn't
much
breakage.
Okay,
all
right,
let's
move
on
any
final
comments.
A
I
don't
think
there
are
any
action
items
here,
except
for
nico
finishing
that
pr
which
is
already
on
my
line-
and
in
fact
I
did
the
fix,
but
I
didn't
push
it
okay,
so
moving
quickly
or
patterns.
We've
talked
about
this
a
million
times
scott.
You
had
an
action
item
to
look
at
the
stabilization
report.
I.
A
It's
in
the
pr
which.
B
I
see
okay,
then
yeah
it's
in
the
pr.
Yes,
I
can
provide
a
link.
D
D
A
D
D
A
D
A
A
D
B
Why
don't
we
put
it
on
the
agenda
for
tomorrow's
meta
design,
meeting.
B
Sounds
good
good
we'll
do
it
in
our
post
meeting.
A
Yep,
okay,
thanks
scott
for
bringing
that
up
and
I
removed
that
corresponding
action
item
for
you.
So,
okay,
lynn,
for
unused
borrow
yep.
D
This
is
ralph's
grand
plan
of
making
cons,
less
painful.
This
is
the
first
step
on
changing
errors
in
coupons
to
just
be
errors
and
not
be
warnings,
because
his
grand
plan
is
to
simplify
the
compiler
substantially
by
not
having
to
have
everything
that
can
possibly
consume
a
const
need
to
deal
with
the
possibility
that
that
cost
fails.
D
So
this
step
is
just
saying
it's
a
future
incompatibility
lint
to
have
constants
that
cannot
be
evaluated.
Is
my
understanding
at.
A
Least:
okay,
why
don't
we
take
it's
not
that
much
thread?
Why
don't
we
take
two
minutes
to
read
over
the
thread.
B
Yeah
I
just
read
through
it,
and
it
looks
like
the
goal
is
just
if
you
overflow,
in
a
const
or
divide
by
zero
in
a
const
or
similar,
and
expect
that,
then
that
is
going
to
produce
a
warning.
Rather
than
not.
D
It's
always
been
a
warning.
Well,
it's
been
a
warning
since
they
started
emitting
a
warning
for
it.
Historically,
you
could
index
into
array
into
constant
rays
by
indexes
that
weren't
inbounds,
and
that
was
just
sort
of
fine
as
long
as
no
one
used
it,
which
was
the
little
odd.
A
A
Yeah
all
this
does
is
add
a
add,
a
link
to
the
reference
issue
to
an
already
existing
error.
So
it's
really
pretty
much
zero
impact.
I
was
going
to
say:
let's
fcw,
let's
do
a
fcp,
but
I
don't
see
the
point.
Can
we
just.
F
A
Later
all
right,
awesome
thanks
scott,
and
is
there
any
other
items
we
want
to
pull
out?
No,
that's
not
that's
not!
It.
A
Okay-
let's
just
go
back
to
the
top,
then
so
it
looks
like
we
have
there's
a
pending
action
item
on
this.
I'm
going
to
skip
over
it
I'll
do
that
action
name
this
week,
c-string
lifetime
warning
incorrectly
fires,
78691.
A
There's
a
lint
that
was
moved
over
from
clippy
about
c
strings.
It
has
a
false
warning
in
the
case
where
it
claims
something
is
ub
which
actually
isn't,
and
specifically,
I
think,
what's
going
on,
is
yeah
I'll
show
you
if
you,
if
you
look
at
this
example,.
B
B
D
This
is
one
of
the
things
that
I
found.
Sorry,
my
meta
thing
here
is
this
sounds
like
a
library
lint,
and
I
wish
we
could
say
that
it's
the
library's
team's
responsibility
to
decide
on
this.
D
B
Well,
there's
an
interesting
question
about
false
positives
here.
When
we
originally
discussed
this,
there
were
two
use
cases
we
talked
about.
One
was
let
some
stir
equal
c
string,
new
data
dot
as
pointer
and
then
use
that
some
stir,
and
that
is
a
true
positive
because
it
gets
made
invalid
at
the
end
of
the
statement.
B
A
Like
the
gecker
pro
gecko,
profiler
registered
thread
function,
for
example,
could
you
could
imagine
maybe
it
starts
a
thread
that
holds
on
to
that
pointer
right?
That
would
be
invalid,
but
that's
kind
of
just
true.
Whenever
you
use
raw
pointers
like
it's
a
bit.
D
A
D
B
A
B
Yes,
the
expected
rewrite
is
let
s
equal
c
string,
new
foo,
possibly
dot,
and
then
s
dot
as
pointer
in
the
call.
So.
A
My
assertion,
then,
is
that
that
would
not
like
if
gecko
profiler
register
thread
actually
started.
Another
thread
that
rewrite
wouldn't
solve
the
problem
right.
True-
and
I
don't
know
it's
not
obvious,
even
if
it
like
it
might
so,
yeah.
B
Which
means
that
we're
not
doing
any
good
with
this
lint,
and
it's
really
only
catching
the
case
where
you
assign
as
pointer
to
a
temporary
and
then
use
it,
which
will
never
work.
A
A
A
That's
my
opinion,
yeah.
I
think
we
should
otherwise
not
lint,
or
you
know.
B
Well,
something
you.
A
B
A
A
A
A
A
D
Yeah
so
basically
couple
constructors
and
struct
constructors
yep.
A
A
Let's
go
on
then
next
issue
turn
derive.
Oh,
this
is
in
fcp,
nothing
else
to
say:
unsafe
op
in
unsafe
function,
lint
I
will
so
people
can
open.
I'm
sorry,
I'm
trying
not
to
jump
our
focus
too
much,
but
the
this
is
the
lint
which
says
you
shouldn't
put
an,
or
rather
this
lint
wants
you
to
put
unsafe
blocks
inside
functions
that
are
declared
unsafe.
A
D
A
B
B
A
D
A
That
the
only
thing
that's
missed,
there's
no
there's.
No.
I
would
like
to
see
a
stabilization
report.
Can
you
request
one
of
those.
A
I
don't
think
there's
that
much.
That
needs
to
be
said,
but
I
think
for
example,
I
would
like
to
see
it.
It
could
be
really
short,
but
I.
B
D
A
That's
fine.
I
can
do
that.
A
Okey-Dokey
great,
never
type
is
the
only
type
that
is
unsafe
to
raw
draft.
I
don't
know
that
we
need
to
keep
this
nominated,
although
there.
C
Was
so
I
yeah
there's
this
and
the
one
that
follows.
I
think
that
are
related
tickets.
I
agree,
we
probably
don't
need
to
keep
it
nominated.
The
only
thing
I
did
want
to
bring
up
is
that
we
had
a
debate
some
number
of
meetings
ago
about
like
whether
this
was
analogous
to
initialization
checking
and,
like
you
know,
should
we
be?
Should
this
be
controls,
control
flow,
sensitive
or
not,
and
I
at
that
meeting
managed
to
convince
scott
that
it's
okay,
that
initialization
checking
be
control
flow
sensitive.
C
While
this
unsafe
checking
should
be
based
on
lexical
scopes
and
not
control
dependence
and
ralph
disagrees,
oh
so
ralph
thinks
they
should
be,
they
should
be
on
the
same
footing.
I
don't
know
what
to
do
with
that.
Where's.
The
comment
it's
on
the
it's
on:
eight:
zero,
zero,
five,
nine,
which
I
think
is
the
one
that
follows
this
yeah
it's
in
the
next
down
issue
down,
and
I
I
treat
this
as
a
couple
of
things.
C
A
Is
do
we
disagree?
I
don't.
C
A
But
this
is
not
100
about
control
flow.
That
is
true.
First
of
all,
it
okay.
I
agree
that
it
is
a
control,
flow-based
analysis.
So
all
right
so
so
observation
right
initialization
is
a
control
flow.
Based
is
inherently
a
control
flow
based
analysis,
which
implies
like
there's,
probably
some
cases.
You
know
where
I
don't
know.
A
You
could
have
met
the
starfu
is
dead
code,
it's
hard
to
say
whether
it's
analyzed
or
right,
whether
it's
initialized
or
not,
right
and
you
they're
sort
of
an
inherent
that
that's
what
you're
saying
right.
Felix.
C
Yeah
or
whether
we
care
that's
just
like
yes,
it's
hard
to
say
whether
we
care
that
socialites
are
not.
But
yes,
it's.
A
C
A
In
any
case,
we
sort
of
can't
that's
all
like
stable
now,
and
it
would
be
it'd,
be
a
big
deal
to
change
it.
I
think
that's
right,
so
the
exact
example
that
ralph
was
giving,
however,
doesn't
involve
any
dead
code
in
particular
and
has
to
do
with
specifically
to
do.
A
A
A
D
Make
it
work
in
matches
match,
match
discriminants
right.
C
C
A
I
don't
think
so.
There
was
ralph
raised
the
point
which
I
don't
think
was
really
sort
of
neither
here
nor
there,
which
was
that
in
fact
like
accept
the
certain
things
that
we're
doing
now
in
unsafe
code.
Checking
probably
ought
to
be
a
hard
error.
I'm
not
actually
not
sure
if
I
agree
with
that,
but
I
had
to
review
it
had
to
do
with
accessing
fields
of
from
pack
structures.
Yeah,
oh
yeah,
and
the
conclusion
was
this
sort
of
required
to
be
ub,
but
I
actually
think
that's
only
true.
A
If
they're
not
aligned
like
you
know
you,
I
don't
know.
If
you
have
a
struck
like
not
an
error
right,
I
don't
know
there
are
some
cases
where
it's
not
going
to
be
ub
so,
but
that
was
what
ralph
raised,
but
that's
kind
of
a
that's
true,
but
that
doesn't
affect
the
the
observation
that
it
would
be
better
to
implement
this
check
just
about
what
the
check
does
kind
of,
but.
A
A
A
C
A
A
So
right
we're
starting
to
ramp
up
addition,
planning,
which
I
wanted
to
to
just
bring
up
anyway,
for
those
of
you
who
aren't
following
if
you
want
to
be
following
there's
just
there's
a
zoolop
stream,
and
one
of
the
items
that
I
had
expected
to
do
was
to
take
the
various
lints
that
we
kind
of
never
got
around
to
really
putting
into
place
and
put
them
into
place.
In
particular,
we
had.
A
These
are
the
lints
we
had
the
expectation,
at
least
I
did
that
as
part
of
the
2018
edition.
These
would
start
to
become
hard
deprecated,
but
we
did.
We
didn't
do
that,
so
the
idea
was
to
move
to
that
in
2021,
and
I
wanted
to
give
people
a
chance
to
say
no,
we
shouldn't
do
that
for
any
one
of
these
lints.
A
E
A
B
You
weren't
yeah,
the
proposal
was,
we
should
have
a
separate
pr
for
turning
each
lint
to
deny
by
default,
so
that
we
can
very
quickly
fcp
each
one
of
those
and
that
way
anything
that
we
all
agree
on.
We
check
our
boxes
on
and
it's
done
and
anything
that
there's
an
issue
with.
We
can
discuss
there
and
it
doesn't
block
the
other
items.
This
is
based
off
of
lessons
learned
from
the
let's
uplift
50
cliff
clippy
links
to
the
language.
D
I'll
nominate
one
of
them
should
I
nominate
the
ones
that
he
started
filing.
Please.
A
A
I
say
nominate
them:
the
design
meeting
will
some
will
may
or
may
not
be
controversial.
There's
one
other
point
I
I
should
add.
I
believe
that,
if
we're
gonna
we
might,
we
might
want
to
discuss
this,
but
I
think
that
the
policy
I
would
expect
is
that
the
lints
are
worn
by
default
on
all
prior
editions
and
deny
in
the
new
one.
D
A
That's
what
I
would
do
yeah
we
can
discuss.
D
A
B
B
Things
like
bear
trait
objects
are
a
good
example
in
2015.
I'm
not
sure
we
should
be
warning
about
fair
trade
objects,
because
people
using
2015
still
at
this
point
don't
expect
that.
A
B
A
My
point
being
like
yeah,
I
I
want,
I
think
my
reasoning
is.
I
want
us.
I
want
people
a
to
move
to
new
additions,
but
b
I
want
them.
I
want
all
code,
no
matter
of
addition
to
look
as
similar
as
possible
so
like
I
feel,
okay
about
coercing
people
in
older
additions
to
move
to
to
newer
patterns
as
long
as
they
have
those
things
available.
If
that's
the
case,
where,
like
they
literally
can't
write
that
code,
that's
a
different
story.
B
A
B
Just
suggesting
the
other
advantage
of
this
would
be
suppose
you
actually
have
some
2015
code
and
you're
upgrading
it
to
rust
2027.
Then
you
may
not
want
to
get
all
the
warnings
at
once.
You
might
want
to
get
a
set
of
warnings,
then
switch
to
2018
then
get
a
new
set
of
warnings
then
switch
to
2021,
and
that
way
you
can
handle
it
incrementally.
A
You'd
have
silenced
them,
in
which
case
they're
silenced
and
you
can
uncomment
them
one
by
one
fair
point:
it
sounds
like
this
is
controversial,
so
I
I
think
we
should.
I
don't
actually
know
what
I
think
is
best,
but
I'm.
A
Yeah
so
it
sounds
like
we
want
to
have
more
discussion.
Should
we
warn
on
these
lints
in
prior
editions?
I
do
think
there's
a
certain
amount
of
some
disagreement
on
this
point.
It
would,
I
guess,
it'd
be
good
if
I
had
been
taking
notes
about
the
major
points
which
I
didn't
do,
why
don't
we
make
an
action
item
nico
to
write
up
pros
cons.
B
I
mean
frankly,
if
in
2024
people
still
have
code,
that's
marked
as
2015
there's,
probably
a
very
well.
Let
me
rephrase
that
there's
probably
a
reason
for
it.
I
started
to
say
a
very
good
reason,
but
in
that
case,
if
they
still
have
such
code,
they
may
not
be
intending
to
upgrade
it
at
all,
which
is
an
even
better
reason
why
they
may
not
want
those
warnings.
A
But
yeah,
I
still
stand
by
well,
it's
okay!
I
stand
by
understood
they
they
get
warnings,
they
don't
have
to
act
on
them,
but
yeah.
That's
all
right.
Let's
keep
moving,
relax,
adt,
unsizing
requirements.
What's
the
story
with
this.
A
A
D
A
Right
and
if
you
had
an
arc
of
foo
of
u832
or
something
we
want
to
permit
you
to
unsize
this,
like
so.
A
A
Right
so
there's,
basically
this
trait.
That
means
was
there's
one
trait
coercion,
sized
which
is,
can
a
pointer
be
coerced
to
an
to
another
pointer
like
from
a
thin
to
fat,
pointer
kind
of,
and
then
that
references,
the
unsized
trait,
which
is
can
a
pointer
to
this
thing,
be
coerced
kind
of
it's
probably
t
on
size?
U,
it's
got
to
be
so.
A
Right
and
the
current
rule
says
that
this
type
parameter
must
only
be
used
in
the
final
field,
and
the
reason
for
that
was,
if
you
had
something
like
this
and
you
and
you
change
like
food
to
from
you,
know
to
to
you
eight
you're,
affecting
both
fields
and
that's
kind
of
surprising,
and
that
wouldn't
really
work
right.
But
what
lcnr
is
pointing
out
is
that.
A
D
A
A
A
It
would
be
it's
not
super
hard,
it
could
be
done
unstable,
but
you'd
have
to
have
a
feature.
Gate
be
one
of
those
kind
of
changes.
That's
like
you
put
in
a
feature
gate
and
then
the
code
behaves
differently.
It's
not
like
you
get
the
feature.
Gate.
F
A
It
does
seem
like
I
don't
know,
I
guess
the
reason
I
can
see
not
to
do
that
is
no
one's
ever
going
to
turn
that
there's
not
going
to
be
any
like.
Realistically
how
much
testing
is
going
to
get
done?
I
don't
know,
maybe
some
I
wouldn't
object
to
saying:
let's
future
gate
it
and
you
know
just
on
principle,
but.
D
C
A
The
error
you
check
if
the
new
algorithm
would
have
allowed
it,
and
then
you
say:
try
this
feature:
gate.
C
A
A
C
A
A
B
B
So
this
validates
and
makes
sure
that
that
now
gives
an
error.
That
is
a
breaking
change,
because
some
crate
could
be
using
these
and
they
were
being
ignored.
B
So
this
went
through
a
crater
run
and
they
were
a
grand
total
of
three
crates
that
had
an
issue
where
they
used
used
on
a
struct
field
and
that
had
no
effect.
But
now
it's
an
error.
B
A
D
Async
guzuta
registry
api.
D
B
A
A
I
don't
understand:
okay
async
trait
zero,
so
it
affected
some
versions
of
async
trade
and
it
affected
olm.
Rs
1.0.
A
Is
that
how
I'm
supposed
to
read
this
report?
I
think
it
is,
but
I
guess
those
are
older
versions
of
async
trait.
B
We
should,
at
the
very
least,
poke
async
trait
and
say:
hey.
Could
you
stop
that.
A
F
I
don't
think
it
it
didn't
actually
break
async
right.
Both
failures.
Look
like
they're
seg
faults
because,
like
probably
ran
out
of
memory
or
something.
F
Yeah,
I
think,
you're
right.
I
think
the
breakage
is
acceptable.
Personally,
I
am
somewhat
of
the
opinion
that
we
shouldn't
do
this
in
general
and
should
instead
prefer
to,
for
example,
if
we
actually
want
to
break
people
to
do
so
on
an
edition
boundary
where
we
can
just
delete
the
thing
yeah
migration
lit,
but
I
think,
given
our
current
policy
is
basically
to
just
accept
these.
I
don't
see
any
reason
not
to
do
that
in
this
case.
That's
what
I
think
too.
A
I,
for.
A
We
should
do
that
for
sure.
Oh,
what
the
hell?
Oh
they're,
not
on
github
or
something
what's
wrong
with
this
person.
D
Yeah,
okay,
looking
at
this
some
more,
I
should
have
just
read
david
t,
w
ceo's
comment
that
there's
actually
only
four
things
that
this
affects.
A
A
I'm
writing
a
comment
which
I
probably
so
I
guess,
there's
all
right.
So
conclusion.
A
A
Great
so
action
item
josh
defile
issue
and
someone
to
leave
a
comment
summarizing
this.
A
Oh
awesome
put
that
in
there
mark
you
weren't
here
for
this,
but
we
have
a
new
action
item
document
which
you
can
see
right
here,
where
we're
recording
action
items;
okay,
so
that
we
don't
have
to
scrape
them
out.
A
A
A
Oh
final
reminder
design
meeting
tomorrow
to
go
over
the
plans.