►
From YouTube: Apache TVM Community Meeting, January 21, 2021
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
Yeah,
so
everyone
welcome
to
the
apache
tvm
community
meeting,
since
this
is
a
community
meeting,
we're
going
to
be
recording
it
so
that
we
can
share
it
with
share
it
to
youtube
so
that
people
who
may
not
be
able
to
attend
for
a
number
of
reasons,
we'll
still
be
able
to
to
be
able
to
see
the
meeting
and
kind
of
see
what
we
were
see.
What
we've
been
talking
about
working
on,
we
are
going
to
kick
the
meeting
off.
Let
me
share
my
screen
here.
A
A
Okay,
well
it
doesn't,
it
doesn't
look
like
we
have
anybody,
anybody
jumping
up
to
say
hello,
but
if
you
are
new
to
the
community,
we
want
to
say
welcome
and
thanks
for
joining
us,
we
have
a
few
announcements
for
the
meeting.
A
A
Now
they
are
they're
up
on
youtube
and
a
playlist,
but
you
can
also
link
to
them
directly
through
tbmconf.org
and
even
the
lightning
talks
we
had
about
three
hours
worth
of
lightning
talks
spread
across
two
days,
and
if
you
go
to
the
tvm
comp
homepage,
you
can
link
directly
to
the
talks
within
the
larger
youtube
video
so
that
you
can
go
and
catch
up
on
any
of
the
topics
that
you
may
have
missed.
A
It
was
a
there
were
a
lot
of
really
fantastic
sessions,
we're
already
starting
to
plan
for
2021
and
so
so
keep
your
eyes
open
as
we
begin
to
finalized
dates
and
announce
formats.
But
again
I
want
to
thank
everybody.
A
Zach
hosted
all
the
meetings
last
last
year,
starting
from
the
summer
all
the
way,
through
the
all
the
way,
through
the
the
fall
and
up
through
tvm
conf
zach
has
taken
on
more
duties
at
the
university
of
washington
as
a
as
a
professor
there,
so
he's
taking
a
small
step
back,
but
he's
still
part
of
the
tvm
community
and
hopefully
we'll
see
him
back
soon
at
the
meetings,
because,
if
anything,
there's
no
way
that
I
can
replicate
all
of
the
jokes
that
zach's
friend
jared
makes
and
also
I
want
to
extend
congratulations
to
a
number
of
promotions
within
the
tvm
community.
A
So
tvm
is
a
is
part
of
the
apache
software
foundation.
It
was,
it
was
just
graduated
as
a
full
project
and
and
and
membership
within
you
know,
within
different
roles
of
the
of
the
project,
are
based
upon
users,
contributions
and
how
active
they
are
within
the
community,
and
so
congratulations
to
our
new
reviewer
leandra
nunez
new
committer
shenfan,
a
new
pmc
member
lean
wang,
a
new
reviewer,
tristan
connellage
and
a
new
committer
josh
frohm.
A
Okay,
so
so
the
next
and
main
topic
for
the
for
the
for
the
rest
of
the
meeting
is
taking
a
look
at
the
apache
tvm
rfc
process
and
perhaps
formalizing
it
a
bit
more
and
also
adding
a
process
where
rfcs
are
after
being
discussed
within
the
discussion.
Forums
are
posted
to
our
are
then
sent
up
for
review
and
and
are
archiving
within
the
project,
the
github.
A
A
A
New
users
can
also
look
for,
can
can
look
for
help,
look
for
assistance
in
running
the
project
and
the
way
rfcs
are
handled
right
now
is
an
rfc
is
posted
to
the
discussion
forum.
It
is
it's:
it's
there's
a
there's,
a
there's,
a
detailed
conversation
about
it,
and
then
there
is
a
lazy
approval
by
consensus.
A
A
But
one
of
the
one
of
the
problems
with
the
discuss
forum
is
that,
as
new
topics
are
added
to
the
forum,
older
topics
are
pushed
down
the
list,
and
so
it
becomes
very
easy
to
possibly
lose
work
items
within
that
history
of
the
discuss
forum
now
they're
still
there,
but
it
requires
searching
to
go
and
find
it,
and
it
lacks
a
more
formal
organization
that
that
the
process,
the
formal
process
behind
an
rfc
would
would
would
kind
of
would
kind
of
ask
for
and
so
and
so
the
question
is:
should
we
take
after
that?
A
A
A
So
so
did
I
did
I
capture
from
the
from
the
t
from
the
from
everyone
on
tv.
Did
I
capture
that?
Did
I
capture
the
state
of
the
of
the
situation
succinctly
incorrectly.
E
Yeah,
I
think
I
generally
agree
with
that.
You
know
there
are
a
lot
of
rfcs,
it's
easy
for
them
to
get
lost
if
you're
looking
for
something
you
have
to
already
know
that
it
exists
to
be
able
to
find
it.
E
So
I
think,
having
a
place
to
organize
some
sort
of
organization
of
them
would
be
helpful.
C
I
think
we
tend
to
see
a
wide
variety
of
rfcs
too,
and
I
think
the
ones
that
benefit
most
from
the
from
if
we
were
to
move
to
github
the
ones
that
would
benefit
the
most
are
the
ones
that
involve
large
changes
to
the
code
base
or
big
features
being
added.
That
way,
we
can
check
the
project
check.
The
progress
see
who's
working
on
them.
D
Yeah
and
one
more
point-
I
guess
I'm
I'd
like
to
point
out-
is
that
on
github
we
already
have
a
small
set
of
issues,
and
some
of
these
issues
are,
I
guess,
are
keeping
track
of
major
feature,
requests
that
are
important
and
that
we
don't
want
to
lose
track
of
so
getting
a
sense
of
what
it
is
that
we
may
want
to
convert
to
a
github
issue,
because
it's
nice,
I
mean
what
the
team
image
community
does.
Well,
we
have
to
acknowledge
is
that
it?
D
It
keeps
a
short
list
of
issues
that
makes
it
easy
to
sort
of
keep
track
of
major
things
that
are
missing
in
tvm
without
being
obscured
by,
and
you
know,
the
noise
of
bug,
reports
and
whatnot
so
yeah.
I
think
it'd
be
helpful
to
get
a
policy,
for,
I
would
say,
upgrading
an
rsc
to
github
issues
to
have
a
sort
of
more
permanent,
sticky
location
to
keep
track
of
major
reworks.
E
Yeah,
I
didn't
even
know
that,
like
major
features
would
be
in
in
issues
like
at
all,
and
I've
been
working
on
the
project
for
like
six
months,
so
you
know
it's
not
a
piece
of
information
that
is,
I
think,
super
public,
or
at
least
publicized.
E
A
Yeah,
I'm
not
sure
it's
even
part
of
the
the
developer
documentation
to
to
do
that.
It
might
be.
A
Yeah,
and,
and
and
and
for
those
of
you
who
also
so
one
of
the
one
of
one
of
the
ways
that
issues
are
handled
within
within
the
community
is
if
someone
shows
up
on
the
you
know,
files
an
issue
within
the
project.
A
A
That
have
a
you
know,
and
so
the
idea
is
that
by
you,
you
try
to
get
the
bug
report
into
the
discuss
forum
so
that
people
are
made
aware
of
it
and
then
they
can
go,
they
can
move
in
and
they
can
fix
it
quickly.
So
there
isn't
a
large
backlog
of
issues
that
that
within
the
within
the
community,
this
is
a
you
know.
A
It's
a
it's
a
common
pattern
with
a
lot
of
within
a
lot
of
open
source
projects
to
have
a
lot
of
to
have
a
lot
of
open
issues
and
the
list
of
of
open
issues,
just
kind
of
keeps
growing
and
growing.
You
know
so
so
the
idea
is
within
within
the
tvm
community.
If
there's
an
issue
there,
it
is
something
that's
actionable
and
it's
something
that
can
be
worked
on
or
is
being
worked
on
right
now,.
A
And
also,
if
someone
files
it,
you
know
it
also,
you
know,
creates
this
idea
too,
that
if
someone
files
a
bug
report
with
within
the
discuss
forum,
it's
a
place
where
you
can
look
for
critical
mass
on
that,
and
so,
if
it's
an
isolated
thing
that
may
be
related
to
someone's
setup
or
or
how
it's
configured
versus
a
real
problem,
we
we
should.
A
You
know
the
idea
is
that
we
would
see
more
reports
on
the
bug
within
the
discuss
forum
and
that
would
that
would
raise
the
noise
level
of
it
and
bring
it
to
the
point
where
it
should
be.
Oh
yeah,
here
we
go
someone
just
pasted
the
the
issue
policy.
A
A
So
unfortunately
it's
it's
too
bad
that
assuming
that
tianji
and
jared
would
both
be
here
to
contribute
to
this
discussion.
F
So
just
a
question
is
because
is
it
possible
to
have
the
rfcs
once
they
sort
of
are
approved
and
finalized
somewhere
like
an
archive
or
something
where
it's
a
bit?
I
don't
know
easier,
maybe
to
to
to
go
through
them
or
something
like
that.
It's
part
of
a
sort
of
documentation
or
history,
or
something
like
that.
I
don't
know.
A
Yeah,
so
so,
if
the
rfcs
are
are,
if
we,
if
we
start,
if
we
start
hosting
rfcs
in
github,
this
means
that
that
there's
a
structure
that
they're
they're
hosted
in
and
it
it
it
gives
us
an
opportunity
to
like
to
to
to
be
to
be
more
active
in
identifying
which
ones
are
active,
which
ones
are
in
flight
which
would
have
possibly
been
abandoned
and
and
to
essentially
do
pruning
on
those
and
and-
and
you
know,
and
it
also
gives
place
you
know
place
for
people
to
go
where
they
know
that
they
can
find
the
rfcs
so
like
typically
within
other
open
source
communities.
A
When
you
have
you
know
some
sort
of
you
know,
change
or
enhancement
process.
The
these.
These
documents
are
organized
by
release
and
then,
as
you
move
from
release
to
release
the.
A
That
that
the
the
proposals
are
closed
or
they
are,
you
know,
as
close
as
being
completed
or
closed
as
being
you
know,
not
being
worked
on
or
they're
carried
over
to
the
next
release.
Now
now
tvm
doesn't
tbm
hasn't
reached
it's
it's
1.0
release.
Yet
so
I
you
know
there,
you
know
we
maybe
want
to
you
know,
think
about.
Perhaps
a
timed
grooming
of
the
of
the
of
the
rfcs
to
you
know
to
help
to
make
sure
that
they're
not
accumulating
in
the
repository
and
to
check
on
their
status.
B
B
They
refined
it
for
many
many
years
and
I
think
it
would
be
very
cool
to
kind
of
at
least
borrow
some
practices
they
do
so,
rather
than
keeping
it
on
on
issues
that
are
completely
reliant
on
github,
and
if
we
ever
in
history,
we
move
away
from
github
that
is
completely
lost
and
instead
they
discuss
the
rfcs
using
pull
requests
and
they
consolidate
all
the
ideas.
You
you
write
kind
of
you
draft
the
thing
and
other
people
will
comment
and
and
drop
in
their
opinions
using
pull
requests.
B
So
when
you
end
that
pull
request,
you
get
a
consolidated
document
with
the
views
and
thoughts
of
everybody,
and
then
the
docs
are
archived
in
a
repository,
so
they
are
not
dependent
on
on
github.
You
still
have
used.
You
can
track
history,
you
can,
you
can
still
have
the
archive,
but
you
are
not
100
reliant
on
on
github
databases
and
stuff.
B
So
if
you,
if
you
have
a
look,
it
is,
it
is
actually
another
repository
and
it
leverages
a
very
good
feature
of
github
that
you
can
reference
issues
and
things
from
cross
reposit
repository.
B
But
at
the
same
time
I
think
it's
a
very
positive
aspect
of
it
that
it
is
not
completely
reliant
on
on
the
github
kind
of
database
or
the
issues
that
they
store.
So
that
repository
is
python.
Slash
peps!
If
you
want
to
look,
that's
all.
F
Also
because
the
the
issues
for
me,
the
issues
are
for
bugs
I
mean
I
it's
it's.
Of
course.
I
know
that
it's
a
bit
reductive
but
yeah,
mixing,
features
and
then
issues.
I
don't
know
it
seems
a
bit
it's
it's
like
the
the
feature
might
get
lost
in
the
in
the
sea
of
of
bugs
and
yeah
back,
support
and
stuff
like
that.
F
D
Yeah
and
and
on
top
of
to
just
to
continue
on
the
topic
of
bugs
giuseppe,
I
think
there's
certainly
value
in
having
the
ability
to
track
those
disqus
forum,
I
think,
has
pros
and
cons,
because
the
bugs
that
more
people
encounter
will
get
resurfaced
every
time.
Someone
comments
on
the
thread.
D
This
almost
you
know,
process
of
decay
bugs
that
are
most
relevant
or
affect
most
people
remain
up
on
the
on
the
front
page
of
the
discuss
forum
and
eventually
get
addressed,
and-
and
so
I
think
this
has
been
sort
of
an
organic
way
to
tackle
bugs,
but
at
the
same
time
it
means
that
the
ones
that
are
less
obscure
or
or
encounter
less
often
less
often
get
get
get
buried,
and
so
I
guess
I've
seen
how
bugs
are
are
reported
in
other
open
source
projects
and,
most
generally
there
they
will
be.
D
You
know
tracked
as
issues
especially
large.
You
know
open
source,
deep
learning
frameworks
or
other
deep
learning
related
projects,
but,
as
a
result,
you
end
up
having
an
issue.
D
You
know
backlog
of
potentially
thousands
of
issues,
and
I
think
the
question
here
is
after
a
while
many
of
those
issues
become
irrelevant
and
do
we
want
to
essentially
enforce
you
know
if
no
one
has
addressed
a
bug
after
a
certain
time.
We
just
close
it
so
that
we
don't
end
up
with
thousands
of
of
issues,
and
is
this
actually
better
than
our
current
discuss,
form
approach,
which
I
think
has
a
sort
of
natural
way
of
working
out.
But
it's
not
perfect.
So
yeah
looking
for
ideas
and
ways
to
improve.
A
Like
like,
like
I've,
always
I
I've
kind
of
you
know
as
a
as
someone
who's
a
relative
newcomer
to
the
tvm
community.
I've
always
wondered
like
why
why
why
bugs
are
pushed
so
quickly
to
the
discuss
forum,
and
I
think
it
makes
sense
that
that
that
you
want,
when
you
know
we
want
to
keep
you
know,
we
want
to
keep
this.
You
know
kind
of
kind
of
clean
and
not
not
have
a
large
back
issue.
A
I
mean
the
way
I
mean
I
mean
really
the
way
the
way
communities
try
to
manage
this,
especially
as
they
be,
as
they
become
larger
and
kind
of
the
the
blunt
tool
of
github
issues
in
causes.
Causes
problems
is
the
use
of
tags
to
the
use
of
tags,
to
sort
issues
in
the
different
buckets
that
you
can
identify.
Whether
something
is
an
issue,
you
know
a
bug,
a
tracking
issue.
A
You
know
implementation
issue
versus
you
know
also
having
bots
that
that
will
regularly
sweep
you
know
the
the
issues
and
anything
that's
older
than
30
days
or
older
than
60
days
or
older
than
90
days
will
be
automatically
closed.
You
know
you
typically
with
a
warning
to
be
used
to
the
person
who
submitted
it
that
that
it's
about
to
be
closed.
A
I
don't
know
if
the
tvm
community
is
big
enough
to
to
to
to
warrant
that
like
it.
It
feels
like
we
have
a
process
that
is
pretty
good
at
capturing
bugs,
I
don't
know,
does
does.
Does
anybody
disagree
with
that?
Like
have
you
found
that
there
are
bugs
that
you
report
to
the
discussed
forums
and
you
feel
like
they
disappear
and
that
they
aren't
addressed?
Has
anybody
encountered.
C
That
there's
occasionally
I've
seen
people
bring
up
issues
in
the
discuss
forum
that
aren't
answered
most
of
the
time.
I
think
we
do
a
good
job
of
answering
people's
questions,
but
I
have
seen
one
or
two
floating
around
that
haven't
been
answered
that
could
potentially
have
been
bugs.
C
The
the
thing
I
worry
about
with
bugs
on
the
discuss
forum
is
we
kind
of
lose
track
of
them,
and
that
can
be
both
good
in
some
ways,
but
also
bad.
If
there's
a
long-standing
bug
that
actually
is
important.
So
yeah.
G
Yeah,
like,
on
the
one
hand,
you
have
the
problem
of
having
a
bloated
issue
tracker
that
you
then
need
somebody
to
prune
or
bots
like
chris
was
saying.
On
the
other
hand,
if
you
could
go
the
other
way
where
you
have
somebody
who's
responsible
for
elevating
discuss,
forum
bugs
or
issues
up
to
the
issue,
tracker
and
github,
and
so
you
know
if
the
goal
is
to
that
might
not
be
a
bad
idea.
If
the
goal
is
to
you
know,
keep
a
really.
You
know
clean
and
lean
issue
tracker.
G
It
has
some
disadvantages,
though
I
think
one
of
the
things
internally.
I've
heard
some
discussions.
You
know
between
tianji
and
andy
royce,
on
this
topic
about
the
github
issues
tracker
being
like.
If
there's
a
bug,
that's
very
actionable,
then
it's
should
be
in
the
github
issues
where
you
have
fleshed
out
the
issue,
you
more
or
less
know
what
what
needs
to
be
done,
and
so
anybody
who
you
know
has
the
experience
in
in
tbm
core
infra
could
pick
it
up
and
execute
on
it.
G
Where
you
know
where
the
concern
is
is
if
things
that
are
not
necessarily
determined
to
be
a
bug
versus
like
a
usage
error
or
an
api
issue,
then
you
know
that's
where
the
discuss
forms
a
lot
better,
because
if
it
hasn't
been
flushed
out,
you
know
it's
not
necessarily
clear
from
the
beginning,
when
you
put
that
when
somebody
submits
a
message,
whether
or
not
it
is
a
true
bug-
or
it
is
that
latter
case
of
being
an
api
issue,
and
so
then,
if,
if
not
enough,
you
know
lots
of
people
in
the
community
are
looking
at
the
discuss
forum,
and
so
it's
the
exposure.
G
There
is
likely
to
be
quite
a
bit
higher
in
order
to
make
that
assertion
that,
oh,
you
use
the
api
wrong.
But
if
it's
in
a
github
issue,
probably
less
people
are
looking
at
it
and
so
then
the
bloat.
Can
you
know
that's
how
things
can
become
a
little
bit
more
bloated,
so
yeah,
I
don't
know
I.
I
guess
it
feels
like
we're
more
in
the
like.
G
Currently,
we're
in
the
like
way
of
working
is
more
like
the
elevating
like
we
should
we're
thinking
about
elevating
issues
from
the
discuss
forum
into
the
github
issues,
but
we
don't
have
like
a
a
real
clear
path
to
do
that
at
the
moment.
G
We
could
change
our
philosophy
on
that,
but
I
don't
I
don't
know
if
it
would
be
useful
to
have
someone
who
is
dedicated
to
or
a
group
of
people
who
are
sort
of
dedicated.
You
know,
because
I
hear
people
saying
frequently
like
hey
this
issue's
come
up
and
discussed
many
many
times
and
and
that
just
like
is
an
example
of
how
things
are
not
actually
making
it
to
actionable
items
and
then
github
issues,
tracker.
A
A
Do
you
think
that
there's
a
possibility
that
when
someone
raises
an
issue,
that's
a
possible
bug
can
be
can
be
tagged
as
a
bug,
and
then
we
can
add
additional
tags
as
to
if
it's
considered,
you
know,
like
confirmed,
closed
fixed,
because
for
anybody
who
who
like
like
for
all
of
these
processes
at
some
point,
you
need
to
go
through
and
make
make
a
decision.
There
has
to
be
like
a
triage
state
stage
of
you
know
being
able
to
go
in
and
like
say
you
know.
A
Oh,
this
is
like
you
know.
This
is
something
that
we're
going
to
work
on.
This
is
something
we're
not
going
to
work
on.
This
is
something
we're
not
going
to
pay
attention
to
because
because
we
can
have
like
like
like
like,
we
can
assign
members
of
the
community
like
as
as
developer,
advocate.
A
That's
something
that,
like
I
could
possibly
do
and
go
and,
like
you
know,
periodically
go
through
the
discuss
forum,
look
at
all
the
bugs
and
try
to
raise
anything
that
may
not
have
been
taken
care
of
or
try
to
classify
those,
but
you
know
but,
but
but
I
think
this
this,
like
you
know
this
raises
an
idea
of
like
do
we
like
do.
A
D
Yeah,
I
really
I
really
like
your
suggestion.
Chris,
I
think
a
little
bit
of
additional
metadata
to
our
discuss
forum
threads
would
go
a
long
way.
D
I
mean
just
take
an
example
where
there
is
a
bug
and
someone
may
be
working
on
a
fix,
but
might
have
not
said
it
loud
out
loud
and
you
might
have
two
different
teams
working
on
fixing
the
same
bug,
and
so
ultimately,
I
think
for
the
community.
It's
a
waste
of
time,
so
getting
a
sense
that
given
bug
is
being
worked
on.
I
think
already
helps-
and
I
mean
in
this
in
this
specific
scenario
and
then
yeah
also
getting
a
sense
that
bugs
are
resolved,
I
think
or
drops
for
instance.
D
If
it's
a
you
know,
oh
it
turns
out
this
person
didn't
know
how
to
use
the
api,
but
getting
a
sense
of
how
many
bugs
have
been
resolved
or
are
being
addressed
will
give
us.
You
know
an
easy
way
to
just
sort
through
the
discuss,
form
tickets
and
see.
Oh,
I
you
know.
Last
month
we
had
13
unresolved
bug
reports
that
had
no
follow-up.
D
B
C
I
was
just
gonna
say
I
I
don't
think
github
supports
fine
grain
permissions
for
issue
tagging.
Unfortunately,
so
I
think
you
have
to
be
a
committer,
obviously
right,
okay,
so
the
reason
I
say
that
is,
we
can't
let
people
tag
issues
even
if
they're,
like
not
a
committer
like
only
a
reviewer.
E
H
A
Yeah,
I
think
I
think
discuss
has
so
I
know
that
I
know
so
the
way
the
way
the
kubernetes
community
handles
this
is
they
have
an
owner's
file
which
will
state
your
level
of
permissions
and
that
can
be
applied
at
the
level
of
directory,
and
so
you
can
actually
have
subdirectories,
which
people
have.
A
You
know
certain
rights
to
that
that
they
don't
otherwise,
and
then
the
enforcement
of
that
is
done
by
bots
and
so
and
so
when,
when
somebody
makes
a
tag
for
a
particular
issue,
it's
actually
the
bot.
That
goes
and
applies
the
tag
based
on
the
permissions
that
have
been
granted
to
the
person
on
the
on
the
within
the
you
know
that
that
have
been
granted
to
them
in
the
repository.
So
it's
a
bit
byzantine,
but
it's
also
like
it's.
A
It's
it's
been
fairly
effective
and
that
and
those
bots
are
open
source.
And
so
you
know
that's
something
that
we
could
possibly
that
we
could
possibly
look
into.
A
Yeah,
I
think
that
I
think
that
maybe
maybe
the
next
steps
are
too
so
we
have
10
minutes
left
in
the
meeting
and-
and
I
think
it
may
be
a
good
idea
to
start
maybe
shifting
the
discussion
towards
what
is
the
action
we
want
to
take
on
on
this.
The
now,
I
think
I
think
the
next
step
is
to
is
to
actually
send
up
a
proposal
like
like
this
meeting,
isn't
isn't
binding.
A
Like
all
really
you
know,
the
like
official
discussion
should
happen
in
the
discuss
forums,
to
make
sure
that
the
entire
community
has
an
opportunity
to
to
collaborate
and
speak
on
this,
but,
like
I
guess,
what
do
we
like?
What?
What
is
a
good
thing
to
put
into
the
initial
proposal?
And
that's
that's
question
one
and
question
two
is
who
wants
to
take
responsibility
for
for
writing
that
I
can
take
responsibility
for
writing
that
document
up
unless,
unless
there's
somebody
who
who
really
feels
strongly
that
they
want
to
do
it.
A
And
I
guess
I'll
I
can
take
it,
I
can
take
it.
I
can
take
a
run
at
it
too,
and
just
and
just
suggest
that
you
know
supporting
the
idea
that
that
that
rfcs
become
are
are
are
moved,
that
we
that
we
create
documents
within
the
tvm
github
repository
for
for
rfcs,
and
that
we
also
could
create
tracking
issues
to
to
track
those.
A
You
know
the
work,
the
work
that's
being
done
and
then
and
that
the
the
history
of
the
discussion
and
the
debate
be,
you
know
you
know,
be
captured
in
the
in
the
document
that
that
goes
into
that
goes
into
github.
Those
are
those
were
all
things
that
I
that
I
heard
during
the
meeting.
B
A
D
And
I'd
be
curious
to
know
chris
only
if
we
have
time
but
I'd
be
curious
to
know
if
there
are
people
in
this
call
who
think
oh,
the
the
current
way
we
do.
Things
is
actually
a
fine
equilibrium
and
we,
you
know,
has
found
that
the
documentation
process
is
very
clear.
I'm
just
curious
if
anyone
is
of.
D
D
I'll
assume
that
means
no,
but
perhaps
we
don't
have
enough
people
on
the
call
to
who
are
you
know
to
capture
that
percentage
of
the
community,
but
I
think
it
has
its
pros
and
cons,
but
definitely
I
think
we
can
do.
G
Better,
at
the
very
least,
one
big
win
would
be
just
to
be
able
to
bring
in
the
rfcs
into
documentation
in
some
way,
so
that
they're
more
more
visible
to
people,
and
how
that's
done
is,
you
know,
is
what
we
want
to
debate.
But
you
know
there's,
like
I
think
tristan
had
this
great
pr
on
the
three
five
pr
g
and
he
linked
a
to
the
jackson,
implementation,
and
you
know
they
on
the
jacks
document
prng
documentation
page.
G
A
So
chris,
I
have
a
question
based
off
of
that
too,
do
we
want
to
go
back
and
do
a
historic
collection
of
the
rfcs,
or
is
this
something
that
we
want
to
put
a
stake
in
the
ground
and
say
this
is
the
way
it
is
going
forward?
But
if
you're
looking
for
old
things,
you
should
go.
Look
in
the
discuss
forum.
G
Yeah,
that's
also
a
really
great
question.
I
think
we
it
you
know
it's
open,
it's
a
yeah,
it's
an
open
question.
Some
something
may
be
like
deprecated
now
and
so
it'd
be
you
know.
G
You'd
have
to
have
someone
with
some
expertise
to
be
able
to
say
now
this
isn't
relevant
anymore,
and
this
is
so
definitely
the
stake
in
the
ground
as
a
first
step
and
then
you
know,
there's
certainly
features
like,
for
example,
the
auto
scheduler,
which
is
not
so
far
gone
and
also
you
know
some
other
more
recent
things
like
relay
that
move
from
an
mvm
to
relay.
It's
still
valuable
so
anyway,
lots
of
like
sort
of
distinct
things
that
we
would
have
to
figure
out
there,
but
first
moving
forward.
A
You
know
essentially
essentially
references
that
that
can
inform
other
things
that
go
on,
and
so,
and
so
I
like.
I,
I
like
the
point
that
there
are
some
rfcs
that
are
more
important
than
others.
There
are
smarties
that
are
that
are
more
equal
than
others,
and
we
should.
We
should
make
sure
that
that
that
that
the
the
information
that
is
captured
in
a
way
that
that's
brought
to
the
same
level
of
of
you
know
the
other
other
other
important
parts.
E
Another
point
is
that,
like
there
is
a
split
between
like
documentation,
that's
for
users
and
documentation,
that's
for
people
developing
the
code
base
and
right
now
I
feel
like
there
isn't
a
ton
of
documentation
for
developers
necessarily
and
so
like.
If
we
were
to
make
rfcs
more
easily
findable
as
part
of
the
docs.
F
A
I
think
that
this
is
a
great
start
and
I'm
happy
to
to
to
move
forward
on
crafting
a
new,
a
new
rfc
for
this.
Unless
there's
anybody
else
who
really
wants
to
take
this
on.
A
All
right
that
said,
I
will
I
will.
I
will
volunteer
for
that
effort
since
since
nobody's
jumping
up
and
down
so
we're
we're
we're
we're
getting
close
to
the
to
the
end
of
the
meeting
time.
We
we've
allocated
45
minutes
for
the
meeting
kind
of
the
last
the
last
portion
of
the
meet
so
we'll
set
we'll
set
this
topic
aside.
I
think
we
had
a
great
discussion,
and
I
want
to
thank
everybody
for
for
engaging
in
that.
A
Are
there
any
other
issues
that
people
wanted
to
bring
up
now
that
if
we
move
on
to
an
open
discussion
in
the
last
few
minutes,
is
there
anything
that
that
people
have
wanted
to
talk
about
this
now?
Now
is
the
time
to
do
that,
if
there's
any
anything
interesting
happening
or
any
issues
that
you've
been.
A
Facing
okay,
it
sounds
like
there
aren't.
Well,
I
want
to
thank
everybody
for
for
joining
us
for
the
first
apache
tvm
community
meeting
of
2021.
Oh,
it
looks
like
somebody.
We
have
something
in
the
in
the
chat
yeah.
So
thank
you
and
we'll
see
you
on
the
the
forums
and
then
discuss
and
at
the
meeting
next
week
I
mean
the
meeting
next
month.
So
the
next
meeting
will
be
the
third
thursday
of
february.