►
From YouTube: Apache TVM Community Meeting, March 9, 2022
A
We've
got
a
couple
of
items
for
discussion
here.
One
is
about
so
I
wanted
to
have
a
what
I
think
will
probably
be
a
brief
discussion
with
david
myself
and
whoever
else
is
interested
about.
Basically,
this
remove
code
owners,
rfc
that
is
kind
of
just
about
to
land
tomorrow.
I
don't
think
this
is
very
controversial.
A
A
Cool
okay!
Well,
if
it's
all
right,
I
think
I'd
like
to
start
with
the
coders
rfc
discussion.
I
don't
think
that's
gonna
take
particularly
long,
and
I
think
that
it
might
be.
You
know
it
would
be
interesting
to
talk
through
briefly
and
see
if
anyone
has
like
additional
ideas
here.
So
for
that
I
guess
david.
Are
you
interested
in
giving
just
like
a
quick
overview
of
the
rfc
that
you
threw
together?
This
is
basically
this
process
rfc.
A
So
we'll
we're
going
to
approve
that
tomorrow,
assuming
there
are
no
dissenting
votes
or
there
are
a
minority
of
dissenting
votes
and
and
so
the
way
that
the
code
reviews
are
kind
of
notified
out
to
folks
in
the
community
is
going
to
change
probably
later
this
week.
So
maybe
I
can
hand
it
over
to
david
if
he
wants
to
give
a
quick
overview
of
rfc
or,
if
you
like.
I
can
also
do
that
so
yeah.
I.
B
Can
do
it
yeah,
so
basically,
a
lot
of
people
pointed
out
that
the
model
of
like
code
ownership
we
use
is
like
currently
based
on
just
like
file
globs,
which
doesn't
work
too
great.
A
lot
of
people
just
consider
it
spam
when
they
get
review
requests
on
github,
which
automatically
come
out
just
based
on.
You
know
what
these
clubs
are
defined
in
the
code
owner's
file
in
the
repo,
and
so
this
results
a
lot
of
people
just
not
reviewing
prs.
B
A
C
A
You
know,
allow
people
to
subscribe
to
topics
and
and
grow
the
community
that
way.
So
I
you
know,
I
think
that
increasing
the
set
of
committers
and
reviewers
is
something
that
pmc
wants
to
do
as
well
and
so
separate
from
this
proposal.
But
I
think
that
overall,
I
guess
in
the
medium
term
the
answer
is
is
yes,.
A
A
A
So,
let's
see
like
if
I
pull
up
like
a
random
pr
of
mine
here
like
these,
are
the
review
requests
here
and
when
you
filter
prs
on
github.
You
know
it's
or
sorry
when
you
go
to
review
programs
on
github,
it's
sort
of
it
can
provide
views
basically
given
kind
of
either
if
you're
in
the
reviewers
list
or,
if
you're
an
assignees
list,
and
you
can
use
those
views
to
like
figure
out
what
you
need
to
take
a
look
at.
A
A
Okay,
so
that's
kind
of
what
I
had
to
say
there
any
other
thoughts
questions.
I
guess
the
one
question
I
think
I
wanted
to
kind
of
prompt
the
community
here
on
was
you
know
there
are
some
aspects
of
code
owners
that
will
that
this
replaces
and
there
there
are
some
others
that
this
will
will
it.
It
replaces
some
parts
of
the
code
owner's
mechanism,
but
isn't
quite
it
may
not
exactly
completely
be
like
a
complete
replacement.
Stand-In
there's
a
couple
of
things
couple
aspects
there.
A
One
thing
is
so
this
does
replace
the
ability
for
folks
to
get
assigned
as
as
reviewers
for
folks
who
are
not
yet
committers
in
in
tvm.
What
you'll
need
to
do
before
you
can
be
assigned
as
a
reviewer
is
to
participate
in
the
actual
pr
discussion
like
either
by
replying
or
or
doing
a
review
and-
and
once
that's
done,
then,
at
that
time,
you'll
be
added
to
the
review
requests
field.
A
Now,
that's
actually
a
limitation
of
kind
of
the
system
as
it
is
today,
but-
and
there
isn't
really
anything
we
can
do
about
that.
Unfortunately,
because
it's
a
sort
of
a
github
and
apache
permissions
limitation-
but
you
know
that's
kind
of
one
aspect-
is
that
it
doesn't.
It
doesn't
allow
us
to
completely
create
our
own
teams.
However,
you
know
we
think
this
is
probably
about
as
good
as
we
can
do
at
least
kind
of
for
our
first
cut
with
our
own
kind
of
automation.
A
Here,
let's
see,
another
thing
is
that
we
haven't.
Actually,
we
haven't
actually
established
kind
of
a
mechanism
to
actually
assign
pr
to
anyone.
So
if
someone
cc
is
like
five
people,
people
will
still
need
to
coordinate
amongst
themselves
to
figure
out.
You
know
kind
of
who's
on
point
for
the
pr
and
who
needs
to
actually
review
it.
So
we
could
potentially
consider
leveraging
like
the
assignee
field
there,
but
you
know
sort
of
unclear
if
we're
going
to
need
that,
so
I
haven't
haven't
pursued
that
just
yet.
A
A
So
the
permissions
problem
is
so
you're
only
allowed
to
assign
prs
and
and
mark
people
as
review
requested
if
they
are
in
the
same
organization
as
tvm
itself,
and
so
that
organization
is
apache,
and
so
you,
you
get
a
user
account
in
the
apache
org.
Once
you
become
a
committer,
so
that's
kind
of
the
nature
of
the
limitation
there
and
I
guess
just
to
clarify
there
when
I
said
they
only
allow
you
to
sign,
I
mean
they
by
they.
A
B
D
A
But
I
think
that,
within
the
confines
of
github,
for
example,
I
think
that
we
have
to
stick
with
the
apache
hosted
infrastructure
as
far
as
I
understand,
which
which
basically
means
sticking
in
the
with
the
apache
org.
But
if
someone
knows
different
feel
free
to
suggest
this
too.
I
I
that's
just
sort
of
the
limitation
of
my
knowledge
right
with
respect
to
this.
A
Right
yeah,
so
the
other
thing
is
that
we
do
have.
So
I
know
that
if
you
are
triager,
I
think
you
are
then
allowed
to
be
in
the
apache
org
and
we
do
have
a
limited
number
of
seats
that
we
can
use
kind
of
as
a
triage
role.
So
this
would
be
folks
that
would
be
able
to
tag
issues,
tag
prs
to
to
reviewers
sort
of
assign
prs
to
reviewers
and
and
managed
review
requests.
A
E
C
A
A
I
thought
all
right,
although
at
this
point
I
wasn't,
I
think,
a
committer
when
what
this
this
automation
really
does.
Is
it
at
the
time
that
you
then
reply
and
therefore
start
participating
on
the
thread,
then
automation
sort
of
make
sure
that
you're
in
the
review
requests
field
so
that
that
feels
kind
of
kept
up
to
date?
So
this
doesn't
change
anything
about
the
committer
process.
A
That
is
something
we're
working
on
separately
from
from
this
automation
here,
but
yeah
you
wouldn't
you
know
this
doesn't
mean
that
you're
magically
becoming
a
committer
or
anything
like
that.
As
far
as
I
mean
we'll
announce
that
change,
you
know
it
changes
to
that
process
separately
and
under
a
bigger
event
or
two
so.
F
F
It
doesn't
show
green
as
it
does
for
the
committers.
You
know.
So
I
don't
know
if
there
is
a
solution.
Maybe
there
is.
This
is
tied
to
the
limitation
of
not
being
able
to
create
groups
like
to
separate
committers
and
reviewers.
I
don't
know,
but
I
do
miss.
You
know
it
seems
that
as
a
reviewer
I
have
no,
you
know
any
impact
on
the
reveal
using
github.
That's.
A
My
feeling
at
least
right
yeah.
This
is
a
great
point
and
I
mean
this
is
probably
an
argument
for
us
to
to
figure
out
like
what
to
do
with
the
like
reviewer
committer
system.
We
have
now,
and
I
I
think
that
the
way
to
I
guess
I
think
that
from
like
kind
of
a
github
or
a
system
perspective
like
the
way
to
allow
you
to
make
those
changes
outside
of
making
a
committer
would
be
to
explore
using
the
triage
role.
And
so
you
know
we
can
do
that.
A
We
can
consider
like
maybe
allowing
some
or
you
know,
granting
triage
status
to
the
reviewers
in
the
community
if
we
have
enough
seats
to
do
that,
but
I
think
that
yeah
that
we
should
we
should
look
at
that
a
little
bit
like
I.
I
get
that
this
is
kind
of
related
to
the
to
the
proposal
here,
because
it's
you
know,
the
proposal
here
is
sort
of
trying
to
make
sure
folks
are
more
involved
in
the
pr
review
process
a
little
bit.
A
I
think
that,
just
given
the
tools
we
have
to
work
with,
I
think
we
might
need
to
consider
that
one
a
little
bit
separately,
because
I
think
that
the
the
right
way
to
let
you
like
close
issues
and
tag
stuff
is
to
make
you
a
a
triager,
for
example,
but
I
think
that
we
have
only
a
limited
number
of
seats
to
in
that
role.
That
apache
will
let
us
use.
A
So
we
have
to
just
make
sure
that
you
know
from
a
broader
organization
perspective,
there's
no
other
more
pressing
need
to
to
that
exists
for
those
seats
above
and
beyond
code
review.
So
that's
just
one
one
part
of
that
question
and
the
other
thing
like.
I
actually
thought
I
noticed
a
change
in
the
way
github
indexes,
like
reviews
and
and
approvals
on
on
pr's
as
well.
Even
for
committers.
A
A
G
F
B
Yeah
and
one
note
on
the
triager's
role
like
the
limit,
but
you
know
andrew
mentioned,
there's
a
limited
number
of
seats
as
I
understand
it,
that's
kind
of
like
artificial
from
apache
because
they
say
if
you
have
that
many
triagers,
they
are
participating
in
the
project.
And
if
people
are
participating
in
the
project,
then
they
should
just
be
committers.
B
A
B
Yeah,
you
know
this
is
just
like
what
we've
come
up
with
so
far.
We're
gonna
try
it
out
and
if
it
works,
that's
great
and
if
it
doesn't
work,
we're
gonna,
you
know
revisit
it
and
change
it.
So
we're
definitely
like
monitoring
the
situation,
and
you
know
this
is
there
to
help
the
community
so
there's
something
else
we
come
up
with
later.
You
know
we
can
just
change.
A
So
please
do
like
continue
to
you
know.
Some
of
these
issues
are
harder
to.
You
know,
see
and
sort
of
have
visibility
into
as
a
once.
You
have
committed
status
or,
or
you
know,
some
of
these
issues
seem
like
less
of
a
big
deal.
So
please
continue
to
like
complain
and
and
suggest
changes.
You
know
to
the
system
as
well,
because
it's
you
know
it's
good,
that
we
have
visibility
into
these.
Basically.
A
Yeah,
I
am
pretty
new
to
apache,
so
I
don't
know
the
all
of
the
answers
to
that,
but
I
agree
that
we
are
kind
of
essentially
working
around
some
like
very
defined
roles
here,
and
so
it
would
be
worth
I
I
agree,
that's
that's
a
conversation
worth
taking
up
as
well.
I
am
not
super
familiar
kind
of
with
what
apaches
like
decided
on
this
before
so
I
need
to
read
more
about
that
before.
I
could
really
have
a
good
discussion
about
it.
E
E
No,
I
think
it's
okay,
but
the
thing
is
we
use
some
scripts
in
our
case
now
that
use
relay.build,
and
I
think,
two
days
ago
I
updated
from
from
the
main
branch
and
everything
failed,
and
that
happens
from
time
to
time.
If
we
update
something,
although
we
are
basically
on
on
the
main
branch
internally,
we
just
work
on
the
tier
expert
that
we
currently.
A
E
And
so
the
thing
is
not
about
the
question
itself,
but
more
like
how
do
we?
How
could
we
improve
the
situation
here
so
that
that
the
api
changes
are
not
so
or
maybe
that
not
the
api
changes?
The
api
of
reader.build
didn't
change,
but
the
options
that
I
took
became
incompatible
or
illegal,
so
to
speak
overnight
right
so
maybe
we
could.
I
mean
one
proposal
would
be
that
that
he
had
a
few
tests
against
this
tiny
models
and
see
that
that
with
different
options
and
see
that
everything
works.
E
One
other
thing
where
I
have
actually
already
created
a
pr
prs
that
error
messages
should
be
as
informative
as
impossible
as
possible.
For
example,
I
just
got
like
executor,
does
not
support
this
and
this,
and
then
I
already
knew
that
it
was
due
because
the
aot
executor
was
changed
to
the
graph
executed
by
the
way
that
deprecated
parameters
are
handled.
E
Oh,
I
knew
this
already,
but
otherwise
I
would
have
been
totally
confused,
so
I
changed
this
in
a
pr
so
that,
in
this
case
the
executable
name
is,
is
given
and
there's
the
list
of
supported
options
and
the
name
of
the
option
that
is
incompatible.
So
this
is
it's
a
general
thing
like
I.
I
would
like
to
to
add
a
as
many
informative
error
messages
to
tvm
as
possible.
I
think
that's,
that's
also
not
a
problem.
E
No
one
should
have
any
objections
against
this,
and
the
other
thing
is
like
I'm
not
100
sure
that
the
way
fabricated
parameters
are
handled
is
really
ideal.
It's
very
hard
to
see
what's
actually
happening,
especially
if
you
take
a
specific
combination
of
aot
and
other
options,
then
in
the
end
you
end
up
with
a
graph
executor,
and
this
is
totally
confusing.
In
my
opinion,
I'm
not
sure
if
there
are
other
opinions
on
this,
no
it
might
or
go
ahead.
A
Yeah
I
mean,
I
think
so.
First
of
all,
I
think
you
know
no
one
should
feel
like
there's
any
barrier
to
improving
the
error
messages.
That's
definitely
a
part
of
tbm
that
needs
to
be
worked
on
and
fixed,
and-
and
so
apologies
for
for
that,
because
I
know
that
that
can
be
a
little
bit
confusing
and
you
know
with
this
particular
change.
There's
a
yeah
there's
a
couple
of
things
at
play
here.
A
A
Right
after
I
finished
talking
no
problem
yeah,
I
mean
for
this
specific
problem.
So,
first
of
all,
what
I
was
saying
was
that
no
one
should
feel
you
know
like
they
can't
improve
the
tbm
era.
Messages
like
everyone
should
feel
very
welcome
to
do
that
and
like
please,
please
submit
prs
for
that,
and
I
think
that
you
know
we
desperately
need
more
to
improve
the
error
messages
so
that
people
are
are
more
successful
with
you
know,
with
their
use
of
tbm.
A
With
that
said
too,
I
guess
one
thing
I
was
curious
about
as
well
was
in
this
particular
case,
were
you
guys
actually
running
code
with
aot
or
just
running
the
compilation
pipeline
with
the
previous
api,
because
I
was
curious,
it
kind
of
looked
like
you're
free,
like
I
just
added
support
for
using
aot,
with
c
plus
plus
in
like
a
very
limited
way.
So
I
was
curious
if
you
were
actually
invoking
the
compilation
pipeline
before
and
saying
you
know,
use
aot
with
c
plus.
E
A
Call
that
that
weren't,
that
would
never
have
worked
if,
if
you
were
to
actually
try
and
build
and
run
that
code,
yeah
and
so,
but
now
to
give
some
more
context
on
right.
There
has
been
a
couple
of
changes
to
tdm
relay
build
and
actually
before,
I
think
last
before,
like
a
few
months
ago,
like
october
or
december,
essentially
right
after
we
did
the
last
tbm
release,
we
had
actually
left
really
tv
and
really
built
pretty
much
the
same.
A
I
think
for
quite
some
time,
but
what
we
did
so
we
kind
of
intentionally
waited
for
the
last
cvm
release
to
go
through
and
then
there's
been
an
ongoing
discussion
between
chris
sidebottom
and
manoopa.
I
think
manufacture
is
here
at
least
and
myself
and
a
couple
other
like
tnt
and
junior,
about
the
right
way
to
organize
the
compilation,
like
the
configuration
options
for
the
tbm
compiler
and
as
part
of
that
and
and
kind
of
to
help
with
micro
tvm.
A
We
had
split
out
some
of
the
options
from
target
that
didn't
really
seem
like
they
necessarily
belonged
on
on
target,
at
least
as
far
as
kind
of
micro,
tv,
auto
tuning
is
concerned,
and
those
were
the
executor
and
the
runtime
options.
And
so
what
was
previously
placed
in
target
were
those
two
options.
A
I
think
that
as
part
of
that
pr,
there
were
a
couple
of
deprecated
options
that
we
actually
should
probably
fix
sooner
rather
than
later,
because
I
think
this
has
been
causing
a
bunch
of
confusion
in
the
community,
so
this
was
kind
of
the
reconstructive,
decorated
options.
Kind
of
the
origin
of
the
reconstruction
decorated
options
was
to
try
to
make
an
api
like
a
backwards,
compatible
change
to
the
relay
build
parameters.
A
A
We
in
fact
did
not
get
this
100
right,
where
the
the
executor
falls
back
to
to
graph
in
certain
cases,
so
we're
kind
of
we
definitely
are
going
to
fix
this
before
we
release
tbm
0.9,
but
I
think
that
it
seems,
like
folks,
are
running
into
this
more
and
more
so
we
should
maybe
at
least
try
to
fix
the
reconstruction,
deprecated
options
function
or
otherwise,
like
change.
The
way
that
we.
A
E
Yeah
yeah,
I
mean
I'm
glad
you're
bringing
this
up.
Maybe
it's
just
from
my
expression
or
for
my
impression
it's
maybe
just
better
to
to
just
fail
if
the
options
are
fabricated,
because
or
I
mean
I
know
why
you
want
to
do
this-
you
want
to
help
users,
but
it's
at
the
moment.
It's
a
bit
more
on
the
side
that
it
confuses
people
more
like.
If
you
just
raise
an
exception
with
you,
did
this,
but
better
do
this.
It
might
actually
be
more
helpful.
A
A
So
maybe
the
immediate
action
here
is
to
like
improve
the
error
message
when
you,
when
you
have
a
incorrect
combination
of
of
targets
in
in
this
particular
in
relay,
build
so
yeah
feel
free.
If
you
have
specific
improvements
that
you
want
to
make
to
raise
prs
there,
I
think
that
would
be
great,
okay,
but
yeah.
H
I
I
think
issue
might
help
here,
just
explaining
what's
happening.
I
I
think
we
we
are
kind
of
aware
of
this
issue.
This
might
be
a
failed
attempt
in
trying
to
keep
the
backward
compatibility
when
we
did
that
split
out
of
attribute
that
we
felt
like
truly
doesn't
belong
to
the
target,
but
I
guess
from
our
side
we
are
waiting
for
there's
another
rfc
called
the
compilation
config.
Please
have
a
look
at
that
as
well
see
whether
that
can
solve
the
issue
we
might
end
up.
H
What
we
might
end
up
probably
doing
is
add
this
verification
to
that.
If
that
gets
true,
but
I
think
we
are
kind
of
waiting
for,
I
think
collage
rfc,
to
see
how
the
target
deficit
should
be
so
that
if
you
follow
this
discussion,
you
can
see
there
was
a
conflict
between
what
the
target
should
mean
in
tbm,
which
is
just
why
this
work
is
withholded
at
the
minute.
A
Right
yeah,
I
think,
there's
made
some
progress
on
on
here,
but
what
manufacture
is
right
is
that
there's
we
that
we
sort
of
need
to
resolve
this
rfc
just
in
order
to
stabilize
on
like
the
kind
of
the
the
proper
or
sort
of
the
the
next
set
of
keywords
that
we
were
going
to
pass
into
tv
and
relay
build.
So
that's
kind
of
left
us
in
this
kind
of
halfway
position
here.
A
F
Maybe
just
a
comment,
a
quick
comment
to
andrew
about
the
api
stabilization.
Maybe
we
should
keep
an
eye
on
not
trying
to
change
the
entry
point
for
the
for
the
aut
code,
and
by
that
I
mean
that
we
recently
changed.
The
tvm
gen
underline
default,
underline
run,
underline
model
called
the
aot
right
and
it
was
now
generating
tvmgen
underlying
default
on
their
line
and
they're
lying
tvm
underlining
main
underlying
underlying
so
that
broke
some.
F
H
H
A
This
shouldn't
have
been
an
api
change,
but
it
might
be
that,
because
the
function
wasn't
marked
static,
that
you
could
actually
still
call
it
yeah.
So
maybe
gustavo
take
a
look
at
this
underscore
run
function,
so
it's
just
a
tvm
gen
default
underscore
run
rather
than
run
underscore
model.
One
of
those
functions
is
the
sort
of
wrapper
function
that
matches
the
eight.
The
the
the
interface
that
you
request
through
the
target
and
the
other
one
of
those
functions
is
the
the
tier
function.
A
It
was
just
to
make
the
the
tier
generated
function.
It
was
just
changed
to
match
the
to
better
align
with
the
name
of
the
the
main
function
in
inside
of
the
tier
module.
But
theoretically
that
shouldn't
have
been
a
user-facing
change,
so
maybe
it'd
be
worth
making
sure
that
we've
like
understood
your
use
case
properly
and
and
that
you
don't
need
to
work
around
the
like
existing
interface
entry
point
as
well.
F
F
It
was
never
clear
to
me
which
one
I
should
use,
because
when
I
was
compiling
a
model-
and
I
specified
in
the
target
link
parameters,
equal
zero
and
I
was
selecting
the
aot,
there
was
a
bug
which
will
emit
one
function
or
another
one.
If
I
don't
put
the
link
parameters
equal
zero,
so
I
discussed
that
with
chris,
so
I
in
the
end,
I
never.
It
was
never
clear
to
me
what
was
the
function.
The
entry
point
for
the
eot.
A
A
A
F
G
H
A
Yeah
yeah,
thanks
for
reporting
that
cool
any
other
topics
for
discussion,
kind
of
around
api
stability
or
or
questions
about
tbm
relay
build,
or
anything
like
that.
I
guess
the
last
thing
that
I
will
you
know
say
here
too
is
like
one
of
the
focuses
we
do
want
to
actually
get
moving
towards
is
is
better
defining
our
release
process
and-
and
I
would
like
us
to
increase
the
release
cadence,
although
we
haven't
taken
that
up
with
you,
know
the
community
or
in
any
sort
of
rfc
threat
or
anything
like
that.
A
Yet
so
it's
not
like
I've
already
proposed
anything,
but
you
know,
as
we
start,
you
know,
thinking
about
having
a
release
process
and
having
a
more
frequent
release.
You
know
this
sort
of
a
thing
will
be
much
more
much
more
important
to
to
kind
of
document
properly
and
and
make
sure
people
are
aware
of
these
changes.
A
Going
once
and
going
twice
cool
all
right.
Well,
I
think
that
is
a
wrap
for
this
community
meeting.
We'll
have
another
one
next
week
same
time
same
place
and
we'll
talk
next
week
about
fuzzer
for
relay.
So
if
you
guys
are
interested
in
that,
you
know
be
great
to
see
you
then
and
again,
if
there's
other
other
topics
that
you
guys
like
to
discuss
just
post
it
up
in
the
doc
before
the
meeting
so.