►
From YouTube: 2021-02-03 Lang Team Planning 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,
welcome
to
the
february
2nd.
Oh,
what
day
is
it
february
3rd
planning
meeting?
Let's
see,
let
me
share
our
document.
I
think
I'm
sharing
the
right
window.
Oh
good!
That
was
a
little
tense,
so
I
wanted
to
start
by
just
kind
of
talking
about
the
plan
really
briefly,
because
I
think
I've
said
it
a
few
times,
but
just
to
make
sure
we're
all
on
the
same
page.
Oh
also,
let's
put
I'm
going
to
make
a
better
template
for
this,
but
for
now
I'm
improvising.
A
So
the
plan
is
that
every
month
we
will
have
a
planning
meeting,
we
will
begin
with
updates
from
the
active
projects
and
I'm
going
to
we're
gonna.
For
now
I
went
through
the
things
that
are
on
the
project
board.
I
have
some
thoughts
on
how
we
should
handle
our
active
projects,
but
I'll
leave
that
for
later
and
then
we're
gonna.
Look
at
this
the
meetings
over
the
rest
of
the
month
and
try
to
schedule
what
meetings.
B
A
This
month
and
then
that's
it
and
I
wrote
about
meeting
preparation.
This
was
just
a
note
about.
I
might
just
remove
this,
but
I
would
like
to
I
would
like
us
to
set
up
some
standards
for
when
we
have
design
meetings,
what
kind
of
prep
we
should
do
before
the
meeting,
and
you
know
what
the
expectations
are
from
people
who
file
the
issues.
How
much
do
they
have
to
have
done
that
kind
of
thing?
So,
let's
start
with
project
updates.
A
A
I
will
say
a
few
things:
there's
continued
work
on
what
I
would
call
polish
and
like,
for
example,
the
problems
of
we
currently
have
an
overly
conservative
approximation
for
what
lives
across
a
yield
that
kind
of
thing
and
esteban,
and
I
have
been
talking
about
how
to
improve
that
so
there
and
then
I'm
not.
A
The
current
plan
involves
a
number
of
steps
along
the
way,
which
is,
for
example,
stabilizing
a
subset
of
named
infiltrate,
meaning
typhoo
equals
impulpar
along
with
generic
associated
types
and
and
so
forth.
So
I'll.
I
think
it's
probably
worth
the
whole
design
meeting,
maybe
more
than
one
to
go
over
in
detail,
I'm
still
kind
of
putting
some
of
it
together,
but
I'm
pretty
excited
about
it,
because
I
think
this
this
will
kind
of
finish
off
a
bunch
of
features.
A
We've
been
waiting
on
for
a
long
time
and
I
think,
there's
a
good
path
that
plus
there's
still
like
stream,
trade
and
other
other
traits
work
and
I've
been
starting.
This
document,
which
I'm
slowly
working
on
the
async
vision
document
a
work
in
progress.
So
this
is
something
I'm
experimenting
with
the
idea
being
that
we
don't
often
have
documents
that
kind
of
describe
what
we
plan
to
do
over
the
course
of
over
a
bigger
span
than
like
an
rfc.
A
We
often
talk
about
it,
but
we
rarely
write
it
up
and
I'm
trying
to
look
at
how
to
do
that.
I'd
like
so.
This
is
meant
to
describe
sort
of
what
we're
shooting
for
with
async,
not
necessarily
we
will
get
this
year,
but
where
we
could
get
in
a
few
years
perhaps-
and
it
covers
more
than
just
lane
team
stuff
like
it-
includes
tooling
and
other
kind
of
issues.
A
B
I
guess
one
question
I
might
have.
I
think
you
mentioned
some
polish
work
it
sounded
like
most
of
it
was
in
the
compiler
sort
of
implementation
rather
than
laying
related.
Is
there
something
to
call
out
there?
That's
laying
related.
A
In
particular,
some
of
it
is
sort
of
lang
intersecting
in
the
sense
that
there
are
thorny
questions
around
well
like
take
that
over
approximation
issue.
They're,
actually
there's
a
bit
of
a
laying
issue
in
that
at
some
point.
If
we
had
a
spec,
it
should
define
what
things
get
captured
and
right
now
it's
kind
of
implementation
defined,
and
so
that's
been
a
bit
on
my
mind
because
some
of
the
implementation
choices
we
could
make
there
would
make
it
harder,
in
my
mind,
to
have
a
spec
and
some
make
it
easier.
A
I
will
say
I
don't
have
this
on
my
mind,
but,
like
part
of
the
vision
document
would
describe
things
like
like,
I
think
it
falls
out
from
some
of
what
I've
written
in
there
that
we
want
for
loops
syntax
for
streams
and
stuff
like
that,
which
is
part
of
why
I'm
writing
it.
There's
it
has
one
of
the
things
that
are
in
it
is
I'll
just
show
you
is.
A
These
design
tenants
kind
of
trying
to
structure
what
are
the
goals
that
we're
doing
with
async,
and
so
this
tenant,
for
example.
I
think
it
kind
of
falls
out
from
from
that
principle
that
you
should
have
a
way
to
to
iterate
over
streams
that
feels
like
a
for
loop
and
stuff
like
that.
Similarly,
this
one,
so
these
are
actually
pretty.
I
would
love
to
get
you
know
if
people
have
thoughts
and
feedback
on
on
them
like
or
want
to
have
a
longer
discussion
about
it.
A
To
do
it
and
talk
it
out,
because
I
think
my
hope
is
when
we
establish
things
like
this
it'll
help
us
settle
arguments
down
the
line,
because
it'll
be
we'll
be
able
to
refer
back
to
that
and
say
this
is
what
we're
doing,
because
this
is
the
vision
we
set
out
so
either.
We
change
that
or
we
take
this
this
road
there's
only
those
two
choices
so.
A
A
A
A
A
Const
generics,
so
there
I
have
a
little
bit
here.
I
mean
min's
con
generics.
Did
we
stabilize
this.
A
So
that's
awesome.
I
know
that
I
had
some
conversations
with
lcnr
recently
about
setting
up
a
more
regular
like
meeting
time
to
start
digging
into
con
generics,
implementation,
theory,
issues
and
so
forth,
and
try
to
go
for
the
next
steps.
We
haven't
managed
to
schedule
that
yet,
but
there's
still
activity
in
short,
but
it's
very
much
in
the
implementation
phase.
At
the
moment.
A
This
is
pretty
exciting,
though
there
was
well
anyway.
I
in
our
discussion.
I
discovered
a
few
things
that
mildly
worried
me,
but
about
stuff
that
we
accept
that.
Maybe
we
shouldn't,
but
I
don't
remember
exactly
what
it
was,
and
I
don't
yeah
I'm
not
that
worried.
It
was
like
corner
case
some
corner
case
things,
but
we're
gonna
have
a
little
bit
of
a
rocky
road,
settling
all
this
stuff
out.
A
I
think
not
I'm
trying
to
remember.
I
think
I
I
think
I
walked
out
of
the
meeting
with
the
conclusion
that
I'm
trying
to
pull
up
my
notes
now
that
it
was
fine
in
part
because
the
behavior
that
was
stabilizing
was
probably
the
behavior
we
wanted.
It
was
just
a
little
bit
harder
to
implement
than
the
other
one
in
a
more
general
way,
and
so
we
might
like
it
might
put
a
little
more
work
ahead
of
us,
but
it's
probably
what
we
should
be
doing
anyway.
That
was
my
conclusion.
A
A
A
A
A
D
C
I
have
been
the
current
state,
as
far
as
I
can
tell
is
that
there
was
a
whole
bunch
of
back
and
forth
some
time
ago
trying
to
sort
out.
How
do
we
build
a
more
minimal
approach?
C
There
was
a
specific
proposal
to
try
to
do
a
more
minimal
approach
which
did
get
caught
in
some
bike
shedding,
but
that
is
a
side
issue,
and
at
this
point
I
think
that
there
may
be
some
well
there's
two
separate
issues.
There
are
some
objections
to
the
minimal
approach
and
I
think
that
that
needed
some
feedback
from
the
lang
team.
C
I
provided
a
little
bit
of
guidance
in
that
area
for
what
we
did
and
didn't
think
that
the
minimal
implementation
needed
to
do
this
was
related
to
does
the
implementation
need
to
implement
language
level
privacy
or
can
that
be
built
on
top
of
that
by
the
higher
level
traits
that
we
provide
then
separately
from
that?
I
think
there's
just
a
high
level
review
needed
of
take.
What
the
current
state
of
the
proposal
is
and
review
it
and
make
it
clear:
okay,
yeah
this
is
looking
good.
We
could
use
some.
C
I
think
it
might
be
a
good
idea
for
us
to
follow
up
by
zulip
and
have
a
couple
of
conversations
to
confirm
that.
But
then,
assuming
that
yes,
a
design
meeting
seems
like
a
good
idea.
A
A
A
So
pop
macro
rules,
I
think
ryan
levick
see
the
liaison
or
the
shepherd
I
forget
to
go
back
or
both,
but
in
any
case
ryan
was
pushing
this
a
little
bit
with
an
rfc
I'm
supposed
to
make
a
proper
tracking
issue.
A
It
needs
some
minor
revision,
but
josh
mentioned
that
petra
shenkov
closed
his
pr,
which
may
indicate
a
lack
of
communication,
probably
indicates
we
haven't
communicated
very
well
with
patriciankov,
which
is
true,
I
think
that's
likely
yeah
and
because
the
intention
was
not
to
was
to
build
on
that
work
and
not
sort
of
deny
that
work.
But,
on
the
other
hand
anyway,
I'd
have
to
think
I'll
I'll
ping,
him
and
ryan.
I
guess
and
see
what's
going
on,
but
I
think
we're
still
feeling
generally
good
with
this.
C
It
is
not
at
this
point
we,
I
think
we
actually
need
to
do
some
further
review
of
that
rfc.
We
gave
preliminary
feedback
and
then
I
think
the
current
state
of
it
is
in
the
lang
teams.
Court.
A
B
Josh,
can
you
clarify?
Did
we
give
feedback
directly
to
ryan
or
or
what
was
the
story
there.
C
We
gave
feedback
to
ryan
via
zulip,
both
before
and
shortly
after
the
rfc
was
opened.
I
believe-
and
I
believe
that
all
of
that
has
been
incorporated
at
this
point,
so
I
think
that
the
ball
is
in
our
court,
but
we
should
confirm
that.
A
I
think
yeah,
I'm
gonna
take
an
action
item
to
review
the
rfc.
Let
me
open
up
our
action
item.
B
I
guess
a
quick
procedural
note
nico
on
the
action
items.
Are
we
deleting
those
when
they
get
done
or
what's
the
story.
A
D
A
A
A
A
C
The
liaison
was
locator,
but
the
issue
with
this
one
was
that
the
person
who
originally
proposed
to
implement
this
that
lokathor
was
trying
to
work
with
and
liaise
for,
more
or
less
disappeared.
A
C
A
So,
okay,
josh
2
ping,
declarative
macro
repetition,
accounts
the
rfc-2229,
so
we
adopted
a
new
de-sugaring
after
our
conversation
which
solves
a
lot
of
problems
but
sorry,
not
de-sugaring.
We
adopted
a
new
migration
so,
instead
of
doing
let
x
equals
x.
A
We're
now
doing
this,
and
the
advantage
is
that
this
this
doesn't
cause.
Let
x
equals
x
forced
a
move
of
x,
essentially
which
we
don't
always
want
and
also
had
problems
with
self,
because
you
couldn't
say
let
self
equal
self.
None
of
those
problems
apply
with
this
nudity
sugaring.
However,
it's
very
non-obvious
what
it's
doing,
and
so
we
probably
want
to
add
some
sort
of
macro
or
something
that's
like
just
capture
capture
x
like
this
and
that
preside.
A
Let's
say
this:
that
would
do
a
d
sugar
to
like
let
x
equals
x,
dot
clone
or
you
know,
there's
different
future
expansion
possibilities.
That
would
let
us
experiment,
and
maybe
eventually
it
becomes
real
syntax
or
maybe
it
never
does,
because
it's
not
that
important,
but
that's
something
that
wasn't
in
the
original
rfc
that
I
guess
we
should
make
up
a
pr
and
do
an
rfc
rfc
bot
merged
for
it.
But.
A
Okay,
no
other
major
updates,
we're
still
doing
implementation
work
there.
We
have
not
yet
gotten
to
the
tricky
tricky
trait
stuff
that
we
talked
about,
but
so
ffi
unwind.
We
had
a
recent
blog
post.
What
is
this
a
recent
blog
post
about
doing
long
jump
work
on
inside
rust?
B
I
have
a
question
actually
on
that.
If.
A
B
Want
to
potentially
recharter
or
like
edit,
the
charter
or
whatever,
because
I
think
the
charter
didn't
call
out
that
as
sort
of
in
scope.
It
said
it
was
future
area
and
potentially
there's
good
idea
of
you
know
bringing
up
a
quick
pr
to
the
charter,
saying
you
know:
here's
the
new
stuff.
A
I
guess
I
think
it
is,
but
it
depends
on
how
much
the
energy
is
there
from
other
people
to
push
it
along,
because
I
think
I
don't
have
a
lot
of
bandwidth
for
it,
and
so,
but
it
does
seem
like
an
important
kind
of
see,
parody
item
to
me.
A
A
Some
notes
on
what
it
probably
looks
like,
and
it
boils
down
to
kind
of
annotating
functions
that
either
might
might
long
jump
or
might
call
a
function
which
long
jumps,
which
I
guess
is
the
same
thing
so
that
you
can
just
so.
The
compiler
can
check
that
they
don't
have
destructors
and
scope
and
stuff
like
that.
C
Okay
is
the
intention
here
to
handle
all
of
these
things
in
kind
of
a
unified
way,
or
is
the
intention
to
say
well,
here's
how
we're
handling.
C
C
A
I
think
they're
different,
the
intent
was
to
handle
them
separately.
Okay,
because
they're
they
behave
very
differently.
C
It
depends
on
which
set
of
which
group
of
people
that
are
asking-
and
I
suspect,
some
of
the
people
asking
after
long
jump
may
potentially
be
just
assuming
that
unwan
all
on
wines
are
on
wines
and
what
they
actually
want
is
to
throw
exceptions
across
rust.
We
should
find
out,
but
long
jump
is
relatively
uncommon,
except
in
you
know
some
occasional
c
code.
That's
doing
unusual
error
handling
and
needing
to
do
that
across
rust
is
possible
and
could
be
done.
C
But
it's
pretty
rare
for
library
code
to
expect
to
be
able
to
call
something
that
interoperates
with
that.
A
A
A
Yeah
yeah,
I
don't
know,
that's
a
good
question.
I
think
I
I
somewhat
lean
towards
unless
somebody
else
wants
to
pick
up
this
ball.
Maybe
we
should
just
leave
it
for
the
moment,
but
not
to
think
about
it.
Talk
about
with
batman,
aod,
never
type
stabilization
is
kind
of
stalled
out,
because
I
haven't
gotten
back
to
looking
at
that
new
approach
and
done
anything
at
all.
Basically,
but
that's
where
it
is,
I
don't
know
about
instructions
that
attribute.
Does
anyone.
C
I
think
we
should
as
well
we've
gotten
a
number
of
successful
usage
reports.
At
this
point
we
haven't
gotten
any
substantive
feedback
that
suggests
there's
any
critical
issue
as
far
as
exposing
things
we
don't
want
to
expose
or
having
internal
compiler
errors
like
the
old
implementation
did
or
anything
like
that.
I
think
at
this
point
we
do
have
enough
information
that
we
could
reasonably
stabilize.
C
I
think
the
one
caveat
to
that
is
that
we
should
decide.
Do
we
want
to
stabilize
the
entire
asm
mechanism
such
that
any
architecture's
inline
assembly
is
insta-stable
when
added
or
do
we
want
to
stabilize
azim
on
an
arch
by
arch
basis
and
say:
okay,
these
architectures
have
gotten
substantial
testing.
We
should
enable
those
and
feature
gate.
Other
architectures.
C
I
think
both
of
those
are
potentially
reasonable
approaches,
I'm
not
sure
if
we've
had
enough
experience
reports
outside
of
x86
and
arm
to
do
stabilization,
but
we
should
talk
with
the
group
about
that.
C
Similar-
but
in
this
case
I
think
it's
that
there
are
architectures
that
have
been
added
in
terms
of
here
are.
The
safe
registers
to
use
here
are
the
things
that
need
to
be
saved
and
restored
around
azim
and
similar,
and
there
may
or
may
not
have
been
enough
testing
to
catch
if
there
have
been
any
obscure
bugs
there.
C
There
are
also
a
handful
of
uses
of
assembly
for
things
like
the
shader
compiler
stuff,
which
I
suspect
is
not
going
to
be
stable
anytime
soon.
A
E
This
is
probably
in
an
rsc
sorry,
but
what's
our
thing
different
back
ends
and
inline
assembly?
Is
it
just
magically
going
to
work
in
crane,
lift
no
problem
or.
C
Not
magically,
but
there
is
a
defined
way
that
crane
lift
can
handle
this
in
terms
of
compiling
this
to
a
separate
object
file
and
linking
it
in,
and
that
is
an
approach
that
the
crane
lift
folks
can
deal
with.
So
I
don't
think
that's
going
to
be
an
issue
long
term.
A
C
A
So
let's
talk
about
upcoming
meetings.
We
have
some
meeting
proposals
here.
We
have
how
many
weeks
do
we
have.
A
C
A
A
So,
there's
these,
let's
briefly
go
over
these.
I
guess
oh
come
on
mark
down
what
is
happening.
I
don't
understand
this
like
markdown
thing
in
which
sometimes
you
get
these
like
double
spaced
lists
like
who
even
never
wants
a
double
space
list.
A
That's
weird,
oh
I'll,
note
briefly
that
we
had
this
meeting,
but
there's
no
minutes
at
all,
which
is
probably
just
fine,
but
it'd
be
nice.
If
somebody
either
put
like
a
dummy
minutes
or
at
least
a
link
to
like
the
recording
and
the
if
we
had
one
or
the
zulub
thread
or
something
it
would
be
useful,
I'm
looking
at
you
scott
is
your
meeting.
E
A
It
doesn't
like,
I
said
just
some
token
thing
would
be
good,
so
we
have
improving
trust
in
the
rust
compiler,
which
is
basically
the
let's
talk
about
what
a
spec
might
look
like,
and
this
ferrocene
nay
sealed
rust
proposal.
I
thought
that
florian
mentioned
having
a
longer
document
or
something,
but
maybe
it's
not
in
this
meeting
issue.
There's
disgustingly.
A
A
A
E
I
filed
72.
It's
probably
not
a
full
design,
meeting
kind
of
a
thing,
but
we're
having
things
keep
coming
up
of
like
does
lang
really
deserve
to
is
laying
the
appropriate
people
to
make
decisions
on
links
about
usage
of
standard
library
apis,
for
example,
which
things
is
it
worth
us
having
to
fcp
them
versus
having
some
other
team?
Do
it
or
something
like
that.
A
So
I
guess
I'd
be
curious
if
people
would
in
the
compiler
team,
what
we
usually
do
is
have
people
kind
of
vote
on
stuff
they're
excited
about
if
people
want
to
just
like
throw
some
x's
or
something
into
the
pack
md.
A
C
So
I
can
see
that
there's
a
couple
of
x's
already
showing
up
on
the
denying
bear
trade
objects
in
2021
edition.
C
I'm
wondering
if
that
one
needs
a
full
design
meeting,
or
there
is
currently
a
discussion
going
on
on
the
we
actually
just
talked
about
this
yesterday
there
was
the
can,
should
we
promote
lentz
to
deny
that
were
edition
links,
and
that
was
one
of
them
and
there's
currently
a
pr
I'm
wondering
if
we
could
just
discuss
that
on
thread
on
the
pr
thread
and
potentially
do
this
via
either
fcp
and
check
boxes
or
concerns
or
similar.
C
E
C
That
actually
sounds
a
lot
more
reasonable
if
we
want
to
just
go
down
the
list
of
lints
in
a
full
design
meeting
and
take
maybe
10
minutes
on
each
one
and
more
more
likely
in
practice
two
minutes
on
the
ones.
Nobody
disagrees
on
and
45
minutes
on
the
ones
people
do,
but
I
think
that
would
be
a
better
use
of
time
than
just
a
meeting
on
one
specific
length
that
hopefully
we
don't
need
60
minutes
to
do.
B
Yeah,
I
think
I
might
also
want
to
discuss
the
more
broad
policy
rather
than
focusing
on
specific
ones
of
whether
we
like
I
know
nico.
I
think
yesterday,
we
discussed
in
lane
meeting
towards
the
end
that
there
is
sort
of
disagreement
on
whether
we
should
enable
warren
by
default
for
old
lints
in.
F
A
E
Yeah,
I
I
think
the
things
about
the
lints
that
would
we'd
end
up
having
more
of
a
conversation
about
are
things
like
the:
when
is
it
okay
to
allied
lifetimes
in
paths
and
the
there
have
been
a
bunch
of
back
and
forth
about
like
okay,
I
think
we
all
agree
that
lifetimes
and
outputs
that
are
tied
to
input
lifetime
should
be
visible.
E
A
So
I'm
those
sound
like
I'm
not
sure
if
they're
the
same
meeting
or
different
meetings,
they
sound
potentially
like
different
meetings
like
a
just
for
time
reasons,
but
I'm
thinking
scott.
That
sounds
potentially
very
useful.
I
feel
like
someone
would
have
to
do
the
legwork
to
prepare
and
summarize
what
are
the
concerns
with
each
lint
and
maybe
I'm
trying
to
think
if
there's
any
other,
both
summarizing
the
concerns
and
maybe
like
if
relevant,
creator
results
or
something.
If
we
wanted
to
get
a
sense
of
how
much
impact
it
has
yeah.
E
A
I
feel
like
that
kind
of
has
to
happen
if
we're
going
to
do
this
edition
yeah.
So
it
seems
like
a
useful
thing
to
do.
E
C
Something
that's
already
worn
yeah.
If
it's
something
that's
already
worn
and
we're
just
talking
about
moving
it
to
deny,
then
it
will
have
already
broken
anybody
doing
deny
warnings
and
anyone
who
isn't.
We
are
moving
from
a
warning
to
an
error,
but
with
cap
lengths
we're
not
going
to
we're
still
not
going
to
break
them.
C
For
that
right,
so
that's
what
I
was
going
to
say
is:
if
there's
anything
we
want
to
consider
going
to
a
hard
error
on
then
I
would
absolutely
like
a
crater
run.
If
it's
something
that's
already
a
warn
and
we're
talking
about
moving
it
to
a
deny,
then
we
may
or
may
not
need
a
crater
run
depending
on
what
the
nature
of
it
is
and
how
difficult
it
is
to
fix.
A
A
This
one
might
want
to
be
that
so
which
is
potentially
okay,
but
I
would
like
that's
helped,
or
maybe
the
way
to
think
of
it
is
there's
a
default
setting,
and
then
there
are
some
that
we
handle
as
a
special
case.
They
they
become
a
heart
error
for
some
reason,
that's
particular
to
them
or
whatever.
But
I
guess
that
would
mean
there
would
be
summarizing
the
current
state.
The
concerns
that
have
been
raised
and
proposed
action
in
2021
edition.
E
A
D
A
For
the
last
day
in
february,
this
is
my
proposal,
I'm
gonna
just
go
ahead
and
say
what
I
think
we
should
do.
I
think
we
should
consider
doing
well
all
right.
Let's
say
we
put
that
last
day
in
february
I
was
gonna
gonna
propose
we
do
nothing
on
the
10th
and
schedule
something
for
the
17th,
but
why
did
I
want
to
say
nothing
on
the
10th
only
because
I
want
us
to
take
well.
Maybe
what
I
want
to
do
is
use
that
as
a
working
meeting
to
do
some
policy
prep
work,
but.
D
A
I
would
take
an
action
item
to
prepare
a
document
and
some
policy
sort
of
stuff,
but
yeah
not
super
much.
One
question
I
have
is
that
something
we
want
to
do.
A
C
I
would
expect
that,
if
we're
going,
I
mean,
I
think
we
could
subdivide
it
in
advance
and
say
there
is
a
portion
of
the
meeting
in
which
we
are
discussing
the
general
process
by
which
we
want
to
grow
the
team
bringing
on
liaisons
giving
them
more
responsibility.
That
kind
of
thing,
and
that
should
absolutely
be
done
openly.
C
But
I
do
think
we
should
discuss
the
potential
people
that
we
think
would
make
either
good
liaisons
or
good
team
members
or
similar
and.
A
A
We
just
want
to
do
that
because
that'll
probably
take
a
while
and
because
I
think
the
general
process
is
still
I
don't.
Unless
anyone
has
any
new
ideas,
I
think
the
general
process
is
that
we're
gonna
try
to
get
people
involved
through
liaisoning
and
shepherding
ideas,
and
and
that's
that's-
the
pathway
to
membership
right,
as
we
discussed
in
the
past.
D
A
E
A
E
B
A
Yeah
I
asked
them
about
their
availability.
They
didn't
get
back
to
me.
I
will
check
with
florian
about
it.
I
also
want
to
also
talk
to
him
because
I
want
to
like
there's
so
much
in
that
topic.
I
want
to
control
the
agenda
or
like
make
sure
we
have
an
idea
of
what
we're
exactly
going
to
talk
about,
but
I
assume
I
guess
in
that
sense
we
have
a
few
minutes
here.
If
folks
have
thoughts
on
what
they
would
like
to
discuss
in
this
angle,
then
I
we
could
talk
about
it
now.
A
I
kind
of
feel
not
prepared
to
have
that
conversation
because
I
don't
have
like
the
list
of
all
the
things
we
could
talk
about
in
front
of
me
or
in
my
head,
so
I'm
regretting
having
said
it,
I
think
we
should
not
do
it
right
now,
but
I
I
would
like
to
make
that
list
with
florian,
okay
good.
Let's
not
do
it
now.
A
B
A
C
I
think
honestly,
the
topic
should
probably
be
just
the
sealed
rust
proposal
or
the
new
ferrocene
proposal.
E
A
bunch
of
it
seemed
to
talk
about
sort
of
stabilizing
versioned
mirror,
in
some
sense,
as
a
target
that.
A
Probably
both
absolutely
it's
length,
I
mean
if
we
make
a
spec
of
what
mir
means
and
when
we
have
a
spec,
we
have
a.
I
don't
know
objectively.
D
E
But
think
about,
like
the
as
I
read
the
proposal,
it
was
talking
about
defining
rust
in
a
translation
of
the
surface
syntax,
defining
the
translation
from
the
surface
syntax
to
the
mirror
and
then
defining
semantics
on
mirror
and
using
that
as
the
way
the
specification
for
us,
the
language
semantics
would
be.
D
A
I
definitely
think
there
is
a
side
of
it
like
a
tooling
and
so
forth
side
that
is
very
compiler.
What
we've
that
we
have
been
discussing.
D
A
Anyway,
we
could,
we
can
hash
it
out.
I'm
happy
to
loop
in
more
of
compiler
too.
D
It's
well
yeah.
Now
we
wanted
to
get
the
the
details
here.
I
I
just
I
guess
one
objective
is
the
idea
that
you
couldn't
have
a
different
group,
that's
dedicated
to
the
semantics
of
mir,
and
you
know
whatever
this.
This
mirror
is
and
yeah
they
want
to
lang
team
liaison,
because
you
want
to
make
sure
I
can
express
the
things
that
lag
needs
to
express,
but
the
idea
that
all
of
us
need
to
be
looped
in
on
the
design
of
that
system
doesn't
sound
right
to
me.
A
You
can
hatch
this
out
later
yeah.
I
want
to
think
about
it.
It's
plausible
what
you're
saying
I
do
agree
that
probably
all
of
us
don't
necessarily
have
to
be
there,
but
then
again
that
seems
true
for
a
lot
of
things.
Yeah,
that's
true
something
that
josh
and
I
have
been
kicking
around.
That
ideally,
would
probably
have
more
time,
but
I
wanted
to
at
least
float.
It
was
thinking
about
how
to
handle
concerns
and
objections
and
trying
to
make
more
of
a
policy
around.
A
I,
I
think,
there's
a
kind
of
informal
rule,
at
least
that
I
feel
which
is
sort
of.
If
I'm,
the
only
one
raising
an
objection
and
nobody
else
seems
to
agree
even
after
we've
really
hashed
it
out.
I
probably
should
drop
that
objection,
or
else
like
I
better,
be
damn
sure
that
I
think
it's
important,
and
so
we
were
thinking
about
how
we
can
kind
of
formalize.
A
Some
of
these
rules,
with
the
idea
of
basically
saying
when
you
make
a
concern
to
sus,
to
sustain
that
concern
over
an
extended
period
of
time
requires
a
second
from
somebody
else
in
the
team
who's
and
that
that
second
doesn't
mean
they
think
you're
right,
but
it
means
they
think
we
haven't
had
enough
conversation
about
it
yet
and
they're
not
sure
or
maybe
they
don't
fully
understand
the
point
or
don't
feel
confident.
A
They
understand
your
point,
something
like
that
and
basically,
if
there
is
no
second,
we
will
move
on
and
a
point
that
josh
raised,
which
I
thought
was
really
interesting.
Was
that,
like
this
seems
like
a
way
of
suppressing
concerns,
but
actually
it
is
also
in
its
own
way.
A
The
opposite,
because
it
kind
of
gives
you
the
freedom
to
say
you
can
raise
any
concern
you
want,
like
you,
don't
have
to
worry
about
the
fact
that
you're
raising
a
concern
that
other
people
might
be
annoyed
about
it
or
something,
because
there's
there's
sort
of
a
mechanism
for
that
of
saying.
Okay.
Well,
if
I'm
the
only
one,
fine
I'll,
let
it
go,
but
we're
curious
why
people
thought
about
this
as
a
as
a
plan?
A
E
Like
right
now,
that's
just
I
didn't
check
my
check
box
or
I
checked
it
and
sort
of
didn't,
say
anything
or.
A
Yeah
or
I
checked
it
and
I
wrote
a
comment,
but
it
seems
I
feel,
like
it's
not
obviously
appropriate
right
now
to
do
that.
It's
a
little
weird
yeah
and
if
it
was
like
there
was
a
mechanism.
A
A
E
I
was
gonna
say
it
would
also
be
interesting
to
see
that
like
if
we
got
seven
plus
zeros
on
an
rfc.
That's
also
like
would
be
good
to
notice
that
that
happened,
whereas
right
now,
a
plus
zero
is
a
indistinguishable.
Checkbox.
B
That's
a
really
good
point
go
mark.
I
was
going
to
note
that
I
think
the
one
concern
I
have
with
this
policy
is
that
I
think
making
clear
exactly
how
you
raise
the
concern
or
objection
is
good
right
now.
It's
if
you
don't
have
an
fcp
bot
going
and
it's
sort
of
unclear
like
do.
I
leave
a
comment.
Do
I
you
know
what
is
the
process
and
since
there's
a
timer
on
it,
it's
sort
of
important
that
there's
an
explicit
you
know
date
attached
or
whatever
to
it.
E
A
B
E
I
think
it
would
be
really
cool
to
have
those
edited
into
the
top
comment
or
something
we
sort
of
do
this
with
checkboxes
on
a
lot
of
tracking
issues.
But
if
we
had
a
like
hey,
there
is
a
this
needs
to
get
resolved.
That
is
more
obvious
to
anyone
showing
up
on
the
tracking
issue
of
like
no,
this
isn't
ready
for
stabilization,
because
blah
maybe
check
boxes
on
the
top
are
good
enough.
I
don't
know
if
it
needs
the
full
like
rfc
bot
tracking
of
it,
but
maybe.
A
In
some
ways,
I'm
less
worried
about
the
like
at
the
time
limit,
for
example
like
I
want
this
to
be
more
of
a
an
understanding
as
much
as
anything
that
that
we
have
on
what
how
we
up,
how
we
manage
consensus,
you
know,
and
it's
not
necessarily
that
it
has
to
be
like
rfc
bot,
says
nobody
raised
a
second
I'm
going
to
remove
this
concern.
The
timer
has
expired.
B
A
D
C
Right
in
particular,
I
think
that
there's
value
in
having
a
dissenting
opinion
like
here
is
for
the
record
the
concern
that
stands
and
that
make
that
concern
may
wish
to
be
revisited
when
something
is
on
its
path
to
stabilization
or
has
been
implemented
or
similar,
just
as
a
did
that
turn
out
to
be
an
issue
etc,
but
that
aside,
while
we
could
get
in
the
habit
of
does
anyone
second,
I
actually
think
it
would
be
less
healthy
for
us
to
immediately
call
four
seconds,
because
that
implies
that
you
must
immediately
rally
whatever
support
you're
going
to
get
and
there's
a
tendency
for
people
to
commit
to
whatever
position
they
start
out
with.
A
To
be
clear,
I
totally
agree.
I
didn't
mean
immediately
what
I
meant
was
more
like:
we've
had
a
long
discussion
and
that
the
net
conclusion
is
somebody
is
there's
still
like
a
holdout
and
we
can
have
the
mechanism
for
saying
okay
like
well,
it's
clear
that
you
know
whatever
nico
doesn't
like
this
idea,
but
this
anyone's
second
niko's
concern,
or
is
that
just
niko?
And
I
would
be
okay
with
that,
but
I
think
we
should
stop
here
because
we're
at
time
it
seems
obvious.
A
All
right
thanks
everyone.
This
was
a
good
good
exercise
and
we'll
set
up
the
calendar
invites
for
the
upcoming
meetings,
all
right
ciao.