►
From YouTube: Apache TVM Community Meeting, March 30, 2022
A
Great
so
welcome
everyone
to
this
march
30th
edition
of
the
tdm
community
meetings,
our
agenda
for
today
I
will
share
so
I'd
start
with
introductions,
but,
as
I
mentioned,
I
think
we
have
a
lot
of
familiar
faces
on
the
call
here.
I
don't
see
anyone
that
wants
that.
That's
I
recognize
is
new,
but
if
you
do,
you
want
to
say
something
feel
free
to
just
interrupt
me.
A
And
hearing
none
of
that
see,
we
just
have
one
announcement
this
week,
which
is
about
dropping
support
for
cafe
ii.
This
was
posted
on
the
forum,
I
believe
yesterday.
So
what
happened
was
folks
were
updating
the
pi
torch
version
that
we
were
using.
Here's
the
the
forum
thread.
You
guys
can
click
through
on
to
to
kind
of
read
about
this,
and
I
guess
I'm
also
noticed
that
sort
of
the
way
we
install
cafe
two
is
through
pie
torch,
and
we
noticed
that
cafe.
A
And
yeah
hearing
none.
I
think
we
can
move
on
to
our
one
agenda
item
for
today,
which
is
rfc
raised
by
david
around
allowing
prs
to
merge
via
comments
and
I'll.
Maybe
turn
over
the
floor
to
him
to
talk
about
it
david.
Would
you
like
to
see
yeah
you're
on
the
call
here?
Would
you
like
to
share
screen,
or
I
can
also
kind
of
show
the
rfc
text
on
my
screen?
A
B
It
cool
yeah,
so
the
reason
we
brought
this
up
is
because
it's
gonna
it
would
be
like
kind
of
a
workflow
change.
So
we
wanted
to.
You
know,
ask
a
community
what
you
guys
think.
So,
basically,
there
are
two
independent
issues
that
we
noticed.
One
is
that
the
commit
messages
are
pretty
bad,
sometimes
just
because
of
what
github
defaults
to
when
you,
like
click
the
merge
button
on
a
pr-
and
I
think
you
know
romero-
brought
up
this
point
with
his
other
related
post
about.
B
You
know,
guidelines
about
how
we
do
commit
messages
which
generate
a
lot
of
good
discussion,
but
the
main
problem
is
like
it
has
this
default,
where
it
just
uses
like
a
commit
from
the
actual
pr
branch
which
a
lot
of
times,
people
just
write.
Some
nonsense
like
update
or
whatever,
and
it's
just
like
that
it
ends
up
being
in
maine,
and
it's
just
like
you
know
you
have
to
click
through
to
go
to
the
pr
and
you
have
to
have
internet.
It's
just
like
not
great.
B
The
second
problem
is
this:
like
one,
two,
three,
four:
five
steps
that
are
laid
out
right
here
and
basically
for
people
that
don't
have
like
right
access.
If
someone
approves
their
pr
before
ci
is
done,
they
have
to
get
another
like
ping
session,
with
a
committer
to
actually
go
and
merge
the
pr.
Even
though
it's
like
totally
been
accepted,
they
just
need
someone
to
come
in
and
click
the
button
for
them.
B
The
idea
is,
we
would
have
a
bot
that
you
interact
with
via
comments
in
your
pr,
so
you
leave
a
comment.
That's
just
like
at
tpm
dashboard
merges
pr
and
it
would
check
the
number
of
conditions
and
if
it
passes
the
merge
of
pr,
obviously
the
conditions
would
be
like
it's
been
accepted
in
the
latest
revision
by
a
committer,
and
then
you
know
because
it's
automatic
we
can
use
whatever
information
we
want
from
the
pr
for
the
commit
message.
B
B
So
that's
pretty
much.
It
there's
some
open
questions
of
like.
Should
anyone
be
able
to
do
this
versus
just
like
committers
being
able
to
do
it
and
then
other
things
like?
Should
we
disable
the
merge
button
and
have
this
be
the
only
way
to
merge,
pr's
and
stuff,
like
that,
so
I'll
open
the
floor
now
to
anyone
with
any
thoughts
or
anything
like
that.
C
C
C
So
what
I'm
trying
to
say
is
that
in
our
ville,
a
pretty
regular
site
for
the
commit
message
guideline
is
precisely
the
second
point
of
your
rfc,
which
is
proposing
to
to
get
as
the
final
commit
message
to
land
in
the
tree.
Get
it
from
the
pure
request
body
and
try
to
you
know,
apply
the
commit
message
guideline
when
people
are
filling
in
the
the
message
in
the
pull
request
body,
you
know
that,
does
it
make
sense.
B
B
E
C
Pull
request
body
you
know,
because
in
manuka's
proposal
the
git
lint
will
run
against
the
commit
messages,
but
since
we
are
dragging
the
commit
message
from
the
pull
request
body,
the
robot
needs
to
you
know:
lint
the
pre-request
body,
not
the
commit
messages,
yeah
that
that
part
right.
So
what
manuka
is
proposing
there
works
if
we
have
commits
against
which
the
gitlint
can
run
against
in
this
ci.
C
But
since
you
we,
if
we
were
a
proposal,
the
final
commit
message
which
actually
need
to
be
run
against
the
the
linker
is
the
pull
request
body
and
we
were
not
able.
We
don't
know.
So
that's
what
I'm
asking
if
the
bot
can
do
that
you
know
inspect
the
purpose
body
and
run
the
linter
against
it.
That
would
be
a
prerequisite
to
you
know
for
that
pragmatic
approach.
That
manoeuvres
is
proposing,
which
is
it's
a
good
idea
in
our
film.
You
know
a
necessary
step,
so
would
that
be
tricky?
C
B
I
don't
imagine
caitlyn
is
too
intensive,
so
you
know,
I
think,
like
you
know,
ideally
it
should
respond
within
like
30
seconds
which
give
actions
gives
us,
and
I
think
you
know
reasonable
lent.
Rules
should
be
no
problem.
So,
even
if
we
have
to
do
a
couple,
you
know
write
a
little
bit
of
goku.
I
don't
think
it's
a
huge
deal.
It's
certainly
possible.
C
No,
it's
just
yeah
closing
saying
that
the
proposal
is
especially.
The
second
part
is,
is
really
awesome
and
I
strongly
support
that
and
that,
as
I
said,
is
a
prerequisite
in
our
view
to
the
commit
message
guideline.
Otherwise
you
know
there
isn't.
You
know
there
are
some
deep
issues
regarding
the
how
we
reveal
finger.
So
if
you,
if
you
don't,
you
cannot
stick
with
that
plan
that
is
proposing
as
the
second
item
of
the
rfc.
So
the
commit
message
guideline
is
pretty
much.
A
A
You
know
when
it's
sort
of
just
a
guideline,
rather
than
having
some
kind
of
a
linter
tool,
I
mean,
I
think,
that's
kind
of
the
the
spirit
of
linter
tools
and
having
something
like
this
in
in
the
ci,
I
think,
makes
sense.
I
know
that
right
now.
I
think
if
you
edit
the
commit
message
and
or
sorry
if
you
edit
the
pr
title
it
causes
jenkins
to
rerun.
A
I
know
that
we
were
working
on
trying
to
fix
that
basically
and
I'm
wondering
if
it
might
be
possible
to
push
some
of
this
checking
into
jenkins
itself,
so
that
you
know
the
same
ci
merge
process
could
check
the
pr
body
that
we
would
be
using
for
the
ultimately
for
the
commit
or
if
it
makes
sense
to
put
that
in
the
the
merge.
The
the
tvm
merge
bot
that
we're
discussing
over
here
on
this
on
david's
proposal.
A
Another
question
because
I
think
this
you
know
this
kind
of
auto
merge
thing
has
been
I've
seen
this
in
several
different,
like
revision
control
systems,
also
in
in
large
companies.
I
think
this
was
implemented.
You
know
five
or
six
years
ago,
or
at
least
more
as
sort
of
a
productivity
enhancement,
and
it
definitely
works.
A
One
thing
that
I've
seen
before
is
the
ability
to
approve
a
pr
and
then
I
guess,
approve
it,
but
require
the
pr
to
be
manually
merged
by
someone,
and
I
don't
know
if
that's
potentially
you
know
sometimes
what
happens
is
you'd
like
to
signal
to
others
on
the
thread
that
you
are,
you
know,
approve
the
pr
and
that
you're
fine
with
it.
But
you
know
perhaps
there's
like
some.
A
You
know,
sort
of
modulo
fixing,
one
small
thing
and-
and
so
you
want
to
you
know,
withhold
basically
an
auto
merge.
I
don't
know
if
that's
something
we
think
about
doing
here
or
if
that's
I
mean,
I
also
believe
in
sort
of
baby
steps
and
kind
of
incrementally
making
everything
better
here.
But
that's
just
one
feature
I
wasn't
sure
about.
If
folks
had
thought
about
here,.
B
A
B
Yeah,
I
think,
certainly
reasonable
to
have
it
like
check.
You
know,
reviews
or
comments
or
whatever,
and
we
could
have
like
a
little
flag.
That's
like
you
know,
don't
listen
to
merge,
requests
on
this
pr
or
something
like
that,
and
we
could
also
do
the
same
thing
for
like
if
someone
looks
at
a
pr,
but
they
want
someone
else
to
look
at
it
as
well.
We
could
have
a
way
of
like
you
know
it's
accepted
on
github.
It
has
a
stamp
from
a
committer,
but
we
want
someone
else
to
look
at
it
as
well.
A
These
two
things
would
let
people,
I
think,
kind
of
implement
that
on
top
of
all
of
this,
so
that's
that's
one
question,
there's
also
sort
of
the
question
of
like
should
a
a
pr
author
be
able
to
request
a
merge
based
on
that
actually
before
we
move
on
to
that,
I
think
murder
did
raise
his
hand,
so
maybe
I'll
I'll.
Let
him.
D
B
A
Like
that
yeah
I
mean
one
thing
we
should
avoid
is
letting
prs
you
know
block
on
one
specific
person.
You
know
unless
that
person
has
explicitly
requested
changes
or
something
like
that,
and
then
even
in
that
case
you
know
we
still
like
to
have
sort
of
a
timeout
in
that
sense
like
if
it's
been
a
week
or
something
and
and
that
person
hasn't
replied
on
the
pr
and
other
commuters
feel
strongly
it
should
go
in.
We
typically
do
have
some
sort
of
a
timeout
there,
but
I.
D
B
Right
so
that
was
my
original
plan
was
like
it's
not
mergeable.
Unless
the
latest
revision
has
been
accepted
so
like,
if
you
push
it
would
need
to
be
re-accepted.
Essentially,
if
you
were
trying
to
merge
it
going
into
andrew's
point,
he
was
just
sort
of
talking
about
which
is
can
non-committer
pr
authors
request
emerge.
B
A
To
re-review
it
yeah
and
then,
as
to
your
like
specific
question,
more
dad,
I
was
just
googling
a
little
bit
and
it
looks
like
there
is
a
github
setting
for
this,
so
you
can
dismiss
what
it
is
called
dismiss,
still
approvals
when,
when
you
push
pr
commit
so
github
could
potentially
do
that
as
as
well.
If
we
wanted
to
move
that
direction
to,
it
seems
like
we
should
that,
since
what
that
you
know
that
would
sort
of
amount
to
requiring
a
little
bit
more
involvement
from
committers.
You
know
this.
A
This
proposal
basically
would
remove
involvement
from
from
committers
and
then
or
not
removed,
but
it
would
it
would
minimize
committer
involvement
and
then
moving
towards
a
proposal
that
would
require
committers
to
you
know
like
approve
things
more
frequently
would
require
more
commuter
involvement.
Maybe
I'd
propose.
A
E
Yeah,
just
real
quick
on
that
one,
which
you,
I
think,
you're
sort
of
alluding
to
having
worked
in
repos,
where
every
time
you
push
to
commit
it
needed
to
be
re-reviewed
and
worked
in
repost,
where
it
didn't
the
ones
where
it
needs
to
be
re-reviewed.
I
think,
as
the
developer,
you
have
a
tendency
to
not
make
like
say.
Oh,
I
needed
to
fix
this.
I
wanted
to
add
this
extra
readme
thing,
or
I
wanted
to
add
this
extra
thing
that
would
make
this
this
pr
better.
E
You
might
not
do
that
because
then
you
have
to
go
through
all
the
the
extra
work
of
getting
that
person
to
reapprove
again
or
getting
someone
to
reapprove,
so
it
just
it
puts
more
barrier
to
to
quality.
I
think,
if
small
fix
ups,
that
the
other
side
of
that
argument
is,
but
then
people
can
sneak
in
changes
that
breaks
up,
but
you
know
obviously,
but
I
think
we're
trying
to
make
it
easier
here,
so
yeah
re
requiring
approval
every
commit
can
be
a
double-edged
sword.
A
Yeah,
I
also
kind
of
believe
in
like
incremental
improvements
here
and
kind
of
reacting
to
the
way
the
community
treats
things,
and
so
you
know
I
think
it'd
be
I
mean
at
the
end
of
the
day
we're
talking
about
merging
revisions
into
a
source
called
a
source
control
tree.
We
can
always
revert
them
if
something
happens
that
we
thought
was
undo
and
I'm
not
saying
that
we
should.
A
You
know,
take
that
to
kind
of
the
other
end
of
the
spectrum
here,
but
at
the
same
time
you
know,
there's
there
shouldn't
be
any
sort
of
I
mean
we
can.
We
can
try
this
out
basically
and
see
how
it
goes,
and
then
we
can
always
walk
it
back
or
add
more
controls
if
we
feel
like
folks,
are
abusing
it.
So.
B
B
B
A
Yeah
awesome
yeah
thanks
again
for
everyone
for
coming
to
the
meeting
join
us
next
week.
We'll
have
a
I
believe.
Well,
I
won't
commit
to
this
until
we've
formally
moved
this
from
the
backlog
to
the
discussion,
but
I
believe
right
now
next
week
we're
slated
to
have
a
discussion
about
the
collage
rfc,
which
is
kind
of
upcoming
work.
That
octomell
is
hoping
to
merge
into
the
repo
in
the
coming
months.
So
yeah
thanks
again
everyone
and
we'll
see
you
next
week.