►
From YouTube: 2020-10-28 Backlog Bonanza
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
In
the
self
macro
metavar-
and
one
thing
I
would
say
I
don't
know
if
I
haven't
followed
up,
but
when
we
said
here
that
we
should
talk
about
hygiene,
integration
being
out
of
scope
and
how
appealing
it
might
be
without
that,
and
what
I
will
note
is
that
that
had
already
been
raised
in
the
thread,
I
think
by
boats
or
someone
else,
and
the
answer
was
a
lot
less
as
we
sort
of
know.
I
still
think
it's
true,
so
it's
just
a
question
of
does
the
feature
like.
B
A
C
B
A
B
D
Yeah
yeah
yeah.
I
think
that
we
I'm
not
sure
that
we
I
mean
it's
still
definitely
out
of
scope
to
do
the
other
hygiene
integration.
I
would
love
to
see
somebody
willing
to
champion
a
group
that
wants
to
put
macros
2.0
over
the
finish
line,
but
yeah.
Just
improving
the
availability
of
ways
to
reference
items
in
the
current
module
would
make
it
easier
to
have
macros
that
are
not
all
at
the
top
level
of
your
crate.
So
that
seems
useful
to
introduce
and
small.
A
I
feel
like
this
is
related
to
the
I
don't
recall
whether
it
was
an
actual
proposal
or
just
a
little
topic.
I
think
the
latter
but
petroshankov
raised
the
idea
of
making
macro
rules
kind
of
regular
items
in
the
next
edition.
I
think
so
you
could
say
pub
mac
like
instead
of
macro
export,
you
could
just
say
hub
macro
rules.
Yes,
please
that
would
kind
of
fit
with
this
feature,
it
seems
to
me
like
just.
A
D
A
Yeah
there
I
have
to
check
I'm
pretty
sure
they
don't,
but
I'm
not
sure
whether
I
don't
remember
whether
petra
shankar
felt
like
it
would
be
relatively
easy
to
make
them
behave
just
like
regular
items
in
the
next
edition
or
what
they
might
be
a
backwards.
A
B
A
E
E
A
Right,
well,
I
think
we'll
skip
over
safe
or
transmute,
because
it's
not
really
backlogged
kind
of
out
of
backlog.
At
this
point.
D
Yeah
that
and
not
just
tracking
issues,
but
I
personally
think
the
next
item
for
backlog
bonanza
should
be
basically
can
we
go
through
a
list
of
everything
that
is
currently
nightly
only
and
make
sure
that
anything
that
doesn't
have
a
tracking
issue
does
and
that
we
actually
get
everything
onto
the
board
of
like?
Is
this
perma
unstable?
Is
this
on
a
path
to
stable
it'd,
be
nice
to
actually
have
an
entry
for
macros
2.0
and
have
an
entry
for
niche
optimization
and
every
random
language
feature?
A
Yeah,
that's
kind
of
where
that's
that's
sort
of
what
I
meant
by
tracking
issues,
but
that's
a
good
concrete
starting
point
of
how
to
address
them.
A
Let's
I
guess,
let's
get
through
these
rfcs,
even
though
they're
not
you
know
exactly
bat
logs
one
so
target
configuration.
A
This
is
pretty
new.
I
guess
about
a
month
old
looks
like
it
adds.
A
new
cfg
target
seems
potentially
useful.
D
Oh,
the
cargo
cfg
target
bit
is
something
that
I
think
the
cargo
team
can
address.
The
is
this
labeled
t-cargo
as.
D
It
should
probably
that
part
should
be
labeled
t-cargo
yeah,
but
as
for
the
new
target
I
mean
we
have
a.
This
would
be
effectively
the
introduction
of
a
new
tier
three
target
right.
D
A
D
Have
the
individual
ones
I'm
just
more
suggesting
if
we
already
have
this
syntax
we're
relatively
close,
and
the
shorthand
would
potentially
be
helpful,
it's
kind
of
easier
to
see
at
a
glance.
This
is
what
I'm
matching
versus
okay,
which
one
is
os
and
which
one
is
vendor
again.
B
D
A
A
B
F
A
D
Is
this
the
one
about
trying
to
address
freebsd
or
is
that
a
different
one.
D
D
I
think
the
reference
level
explanation
at
the
bottom
here
new
eab
ihf
right
now
we
provide
target
inf
and
we
don't
provide
the
eabihf
bit
or
rather
not
in
a
very
clean
way.
A
Would
this
be
changing
what
like,
if
we
provide
target
end
already
the
way
this
is
written,
it
sounds
like
it
or
do
we
not
provide?
Do
we
just
provide
gnu
already
or
do
we
provide
that's.
D
D
Yeah,
I
would
be
inclined
to
support
this
one,
and
the
only
open
question
I
would
ask
is:
is
this
changing
the
value
of
target
in
for
any
existing
target
like
do
those
targets?
Do
canoe
e-a-b-I-h-f,
or
do
they
do
if
this
would
not
be
changing
target
in
then
it's
backward,
compatible
and
yeah
by
all
means,
let's
make
this
available
and
if
it
would
be
backward
incompatible,
then
we
need
to
be
more
careful
here
either
way.
I
think
we
should
let
this
move
forward.
A
One
thing
I
will
note
like
boats,
you
pointed
out
how
challenging
they
are
to
parson.
I
totally
agree,
but
this
actually
doesn't
require
parsing
right.
It
just
requires
a
team.
B
B
A
But
are
generally
positive
this.
This
is
how
I
feel
so
people
can
disagree,
but
on
offering
this
config
presuming
it's
standard
and
backwards
compatible.
A
Effect:
okay:
now
we
can
go
to
man
to
make
core
institute's
panic.
Identity
brings
up
another
question
of
just
general
admission,
monitoring
and
planning.
So
what
this.
A
A
Okay,
and
so
this,
this
rfc
proposes
a
kind
of
plan
I
I
think
is
based
on
the
addition
introduces
a
function.
I
have
to
look.
I
guess
I
think
it
introduces
a
function
for.
A
Right
so
panic
any
to
send
arbitrary,
payloads
and
then
everything
else
just
work
that
requires
a
certain
amount
of
migration.
A
Yes,
I
think
there
shouldn't
be
any
major
challenge
right
now.
It
sounds
like
clippy
already
has
a
lint.
That
is
close.
I
don't
know
the
details
personally,
I'm
in
favor
of
this
because
I
feel
like
this
is
what
I
would
expect.
G
Yeah,
I
think
you
already
introduced
the
thing
very
well,
but
there's
a
lot
of
different
tiny
problems,
but
the
biggest
problem
is
fixing
is
indeed
the
implicit
arguments
that
you
mentioned,
but
while
fixing
that
it
also
fixes
a
number
of
other
problems,
but
the
results
are
basically
just
making
the
panic
macro
trivial
again,
it's
just
that
the
current
version
is
yeah.
Has
this
weird
special
case
that
will
unfortunately
break
things
if
we
would
just
fix
them
right
away,
so
it's
mostly
just
warnings
and
adding
a
function.
G
So
I
guess
decisions
here
are
more
like.
Is
it
fine
to
move
to
a
function
and
do
we
really
need
to
avoid
all
the
breakages,
but
considering
the
amount
of
things
that
break?
Well,
I
tried
to
do
a
crater
run
or
some
other
things.
I
think
we
really
cannot
break
things
in
the
current
edition.
A
G
So
almost
everything
in
this
rfc
is
already
implemented,
like
almost
every
step
has
a
link
to
the
request
that
implements
it.
A
G
But
I
meant,
like
you
said
you
did
a
crater
run
with.
I
wanted
to
do
a
crater
run,
but
even
the
try
already
failed
because
there
were
things
depending
on
it.
So
while
doing
the
tri-build
before
the
crater
run
and
the
club
already
filled
because
it
uses
not
a
string
literal
for
some
panics
in
hazard,
so
it
really
seems
like
we
cannot.
A
A
G
For
panic
right
now
is
a
macro
loss
macro,
so
that
wouldn't
work,
but
it
would
have
to
be
a
built-in
macro,
just
like
a
cert,
and
then
it
can
just
check
the
the
spawn
of
the
word.
Panic
just
like
assert
is
already
a
built-in
macro.
Panic
will
also
have
to
be
that
and
that's
for
core
panic
and
cd
panic
would
just
be
a
an
alias
for
that.
B
Wasn't
this
also
the
issue
that
was
blocking
like
inline
format,
strings
where
they
have
the
variable?
Yes
in
line
instead
of.
D
Think,
that's
not
the
only
motivation.
It's
definitely
what
led
us
to
discover
this,
but
once
we
discovered
it,
it
turns
out
that
this
is
an
issue
for
like
some
of
the
inconsistencies
here
between
core.
Instead
were
problems
for
folks
who
worked
on
crates
that
sometimes
use
no
stood,
and
sometimes
don't.
G
Yes
see,
I
mentioned
nine
different
problems,
and
only
one
of
them
is
the
the
implicit
arguments
thing
yeah.
I
guess
it
is
the
biggest
motivation
number
eight.
C
But
yeah
I
want
to
make
sure
I
understand
something
here:
I'm
trying
to
understand
the
solution
in
terms
of
there's
there's
one.
The
corner
case
like
there's
a
corner
case
that
I
can't
imagine
anyone
actually
does,
but
I
want
to
con
at
least
raise
it,
which
is
when
someone
is
currently
using
panic
with
a
literal
string
that
has
a
template
macro
like
it
has
a
template
form
in
it.
G
Is
that
would
be
that
if
you
look
at
the
third
step
in
the
proposed
solution,
that
adds
a
lint
for
it?
Can
you
click
on
the
screenshot
there
yeah
and
the
third
sentence
in
the
third
paragraph,
there's
a
screenshot
link.
C
G
G
No,
that
would
just
break
too
many
things.
C
C
G
What
I
didn't
realize:
okay,
there's
one
thing
this
would
break
in
the
current
edition,
and
that
is
the
macros
like
to
do
an
implemented
assert.
They
currently
call
panic
without
any
path,
so
just
panic
by
itself,
because
they
don't
know
if
they
need
to
call
stud
panic
or
core
panic,
and
that
means
you
can.
If
you
define
your
own
panic
macro,
it
will
call
that
one
instead,
because
there's
no
hygiene
that
shouldn't
have
happened,
but
that
can
now
be
fixed.
G
There
is
already
an
open
forecast
for
them,
because
at
least
for
those
situations,
steadfanning
and
core
panic
now
behave
the
same,
but
it
does
mean
that
if
anyone
relies
on
the
fact
that
they
can
intercept
it
with
their
own
macro,
it
that
wouldn't
work
anymore,
but
it
was
never
promised
and
it
wasn't
supposed
to
work
that
way.
A
G
Too,
but
it's
the
one
thing
that
that
really
changes
behavior.
Otherwise,
everything
is
just
for
the
next
edition.
A
Do
you,
given
all
how
much
this
is
already
implemented
like?
Are
you
happy
to
pursue
the
implementation
of
this
proposal.
G
Yeah
definitely
I
have
most
of
it
ready
one
of
two.
These
things
were
done
by
someone
else,
but
the
lynn
right
in
here
I
have
implant.
The
second
version
is
not
yet
sent
as
a
pull
request,
but
I
have
a
working
version
of
that.
I
think
so
it's
all
just
waiting
for
a
decision
like
do
we
actually
want
this.
Do
we
want
the
lin
that
actually
does
say
hey?
This
is
going
to
happen
in
the
next
edition.
G
A
Is
there
one
other
question
I
guess
for
the
room
is:
is
this.
A
G
D
D
I
think
that
the
situation
isn't
quite
as
bad
as
you're,
describing
because
for
two
reasons,
I
think
there
was
a
very
compelling
argument
in
the
thread
that
all
of
the
with
names
are
confusingly
similar
to
things
that
take
a
closure,
because
with
is
a
common
like
syntax
that
we
use
to
mean
this
takes
a
closure,
and
all
of
the
throw
related
syntaxes
would
be
entirely
too
confusingly,
similar
to
things
that
we've
talked
about
using
as
like
a
companion
with
try.
D
So
the
idea
of
making
throw
using
exception,
syntax,
like
throw,
might
make
people
think.
Oh,
this
is
rust's
exception,
syntax.
I
want
to
use
this
for
exceptions.
No,
this
is
a
very
obscure
panic
feature
that
most
people
don't
use.
That
seems
like
it
would
be
an
attractive
nuisance
that
will
trap
people
into
thinking.
Oh,
I
should
be
using
this,
so
both
of
those
families
of
things
seem
like
they'd
be
hazardous,
which
just
leaves
you
with
a
couple
of
possibilities.
D
G
That's
nothing!
That's
right.
The
error
handling
group
was
talking
about
the
possibility
of
specializing
this
function
or
something
inside
this
function.
For
specifically
for
things
that
implement
error
such
that
you
can
still
just
panic
on
error,
object
itself
and
still
get
the
the
error
chain
out
of
it.
So
if
that
is
something
that's
gonna
happen,
then
maybe
that's
something
to
take
into
account
for
the
for
the
name,
but
I
don't
know
if
that's
if
that's
feasible
or
if
that's
gonna
happen.
B
A
B
A
Who
wants
to
follow
up
and
what
follow-up
sounds
like
we're,
tagged,
t,
libs
and
proposed
merge,
or
do
we
want
to
remove
ourselves?
I
guess
that's
the
other
option.
D
Between
the
addition,
change
and
the
fact
that
panic,
unwinding
semantics
are
kind
of
part
of
the
language.
A
D
Would
it
make
sense,
rather
than
having
like
one
mega
rfc,
that
is
both
libs
and
lang,
and
we
all
need
to
check
our
boxes
to
do
a
rfc
bot
for
just
lang
and
then
libs
can
deal
with
the
separate
question
of
what
do
we
call
the
function
and
similar.
G
Confusing
most
of
the
ellipse
naming
things
happen
after
the
the
unstable
versions
already
merged.
Only
on
the
stabilization
vr.
A
All
right,
I'm
going
to
take
the
point
of
making
this
comment
unless
anyone
else
wants
to
just
to
move
us
along.
A
D
Yeah,
we
definitely
deferred
some
of
them,
especially
towards
the
beginning,
towards
the
end
we
tend
to
just
like
okay
who's
going
to
write
the
comment.
Let's
write
the
comment
but
towards
the
beginning,
we're
like
here's
our
conclusion
and
then
nobody
wrote
the
comment.
A
Yeah,
I
think,
partly
because
we
didn't
know
quite
what
we
were
doing.
Maybe
we
can
discuss
a
little
bit
where
to
go
from
here,
so
we
had
talked
about.
Let's
see,
I
want
to
write
this
next
steps.
Here
we
had
talked
about
tracking
issues
and
josh.
You
had
a
specific
proposal.
I'm
trying
to
bring
back
to
memory.
D
I
was
proposing
concretely
that
every
nightly
only
feature
should
have
a
corresponding
tracking
issue
and
ought
to
be
on
a
board
somewhere
in
a
category
for
like
permanently
unstable,
and
there
should
be
a
good
reason
for
it
on
some
path
to
stable
need
somebody
to
pick
it
up,
maybe
make
part
of
this
our
wish
list
for
like
hey.
Would
a
project
group
like
to
come
help
stabilize
this?
What
will
it
take
to
stabilize
us?
How
do
we
get
this
over
the
finish
line?
A
Yeah,
that's
kind
of
what
I
had
in
mind.
I
would
like
to
be
able
to
say
I'm
not
quite
sure
what
the
buckets
are,
but
I
definitely
like
to
be
able
to
answer
when
people
say
either
what
is
needed
to
move
this
along
and
and
sort
of
will
this
move
which,
in
some
cases
what
is
needed
to
move,
might
be
sorry?
It's
not
moving
right
now,
because.
D
But
maybe
nobody's
decided
that,
and
we
should
actually
finally
disposition
it,
maybe
give
it
a
name
that
starts
with
rusty
underscore
if
it's
going
to
be
one
of
those
like
only
stood
uses
this,
but
also
there's
a
decent
chunk
of
things
that
are.
You
know
only
uses
this
where
we
should
consider.
Should
it
be
that
way,
should
there
be
a
way
to
move
this
towards
stable
each
one
of
those
needs
a
little
consideration.
A
D
D
D
D
D
A
A
I
don't
think
we
should
starting
on
this
right
now.
Are
there
any
other
proposals
for
what
else
we
could
use
like
to
do
with
this
backlog?
Besides
trucking
tracking
issues.
A
That
seems
more
like
I
guess
the
question
is.
Maybe
we
should
just
do
that
right
now
and
assign
people
basically.
F
So
sure
did
have
another
sort
of
next
step,
potentially
other
than
tracking
the
issues
which
is
sort
of
backloggy.
F
Is
that
there's
sort
of
a
lot
of
really
what
feels
like
a
lot
of
issues
on
wrestling
rust,
which
are
not
really
tracking
and
they're,
like
sort
of
feature,
requests
and
sort
of
there's
this
weird
trait
system
thing
that
someone
wanted
to
do
and
it's
unclear
whether
it's
a
bug
or
you
know
it's
actually
intended
behavior
and
to
some
extent
like
it
needs
almost
a
lane
team
decision
of
like
yes,
this
is
intended
or
no,
you
know
what
you're
doing
here
is
actually
sort
of
intentionally.
F
Not
working
are
those
tagged
with
like
appropriate
metadata
that
we'd
be
able
to
actually
identify
them
relatively
easily?
Most
of
them
are
tealing,
and
some
of
them
are
see
feature
requested,
or
so
I
think
like.
If
there
was
a
goal
of
working
through
them,
I
think
that
we
could
get
most
of
them
tagged
that
is
sort
of
the
low
order
there
more
so
just
like,
actually
dedicating
lane
team
time
to
working
through
them.
If
that's
something
like
team
wants
to
do,.
A
F
A
Yeah,
the
other
thing
that's
on
my
mind,
is
how
we're
gonna
or
but
I
don't
think
it's
a
backlog
issue
of
tracking
the
tracking
the
additions
and
so
on.
Maybe
the
answer
to
that
is.
We
should
have
a
bit
of
a
planning
meeting
but
yeah
all
right,
okay
and
I'm
gonna.
Look.
Let's
go
look
back
a
little
bit
and
see
what
we've
got
here.
A
So
for
this
target
extension
rfc
we
had
proposed
there
should
be.
Maybe
I
should
just
go
off.
I
don't
know
if
this
is
a
good
use
of
group
time,
because
some
of
this
may
have
been
done.
So
I'm
not.
A
I
don't
know
what
folks
think
about
that,
but
looks
like
this
wasn't
done,
though
we
were
going
to
propose
that
this
should
start
with
implementation.
A
Why
don't
we?
Let
me
do
this:
let's,
let's
end
this
call,
but
folks
who
want
to
do
some
of
the
work.
I
will
make
a
little
list
and
write
people's
names
and
we
can
check
them
off.