►
From YouTube: Apache TVM Community Meeting, November 18, 2021
Description
Monthly Apache TVM Community
This month the topic was improvements to the release and packaging process. More information at https://discuss.tvm.apache.org/t/tvm-community-meeting-november-18-2021/11475
A
Hi
everyone
and
welcome
to
the
november
2021
edition
of
the
apache
tvm
community
meeting
a
reminder
that
the
meeting
is
being
recorded
and
will
be
shared
to
the
apache
tvm
community
mailing
meeting
youtube
channel
over
over
at
octoaml.
We
have
a.
We
have
a
playlist
that
that,
where
we
archive
all
of
these
meetings-
and
so
you
can
catch
up-
we
have
a-
we
have
a
pretty
good
agenda
set
up
for
today.
A
A
A
A
A
You
can
see
the
you
can
see
the
schedule
and
the
lineup
that
we
have
for
that.
It's
going
to
be
it's
going
to
be
pretty
great.
We
have
lots
of
great
speakers.
We
have
a.
We
have
a
pretty
good
schedule
lined
up
for
the
event
which
we've
gone
live
with.
We
haven't
posted
all
the
lightning
talks
yet,
but
those
will
be
that
schedule
will
be
coming
up
soon.
We
also
have
a
full
day
of
tutorials.
Leandro
is
going
to
be
presenting
at
these
and
and
we're
using
a
new,
a
new
platform.
A
So
we've
upgraded
our
experience
from
last
year
and
we're
going
to
be
using
the
what's.
The
platform
called
welcome,
which
is
going
to
give
us
a
main
stage,
but
also
a
number
of
breakout
rooms
and
have
a
really
great
chat,
platform
and
ways
for
people
to
to
interact
with
one
another.
So
we're
super
excited
about
that
and
please,
if
you're,
if
you're
speaking,
you
know-
and
you
see
tweets
come
through
on
apache
tv
ham,
retweet
them-
you
know,
get
people
to
come
and
talk
because
the
event
is.
A
Is
we
very
much
want
it
to
be
about
what's
happening
in
the
community
and
what's
and
what's
going
on
in
the
community,
which
is
why
we
have
a
hundred
speakers
who
are
who
either
working
on
tvm
or
who
are
working
on
advanced
machine
learning
or
working
in
open
source?
Just
kind
of
like
talk
about
this?
You
know
we're
having
over
the
two
days
we're
having
five
hours
of
community
sessions,
spread
over
compilers
track
and
an
edge
track
so
that
you
know
we
the
community
will
be
able
to,
like.
A
You
know,
chat
about
a
lot
of
the
issues.
They've
been
working
on
and
work
and
work
through
some
things,
and
so,
rather
than
just
be
like
a
bunch
of
pre-recorded
talks
where
people
are
going
to
be
talking
to
one
another,
we
really
want
it
to
be,
like
you
know,
a
collaborative
and
engaging
event
for
everyone.
So
you
know
thank
you
for
everyone
who
submitted
talks
and
who's
presenting,
and
I'm
really
excited
to
to
to
be.
You
know
that
we're
doing
the
event
again
this
year
and
and
for
everyone
to
join.
A
A
C
Yeah,
thank
you
very
much,
just
a
a
small
amount
to
your
announcement
of
our
talk,
so
I'm
doing
a
joint
presentation,
a
joint
tutorial
with
gustavo,
who
is
also
on
the
call
yes
about
tbmc
yeah,
so
you
can
see
him
on
zoom
as
well.
So
yes,
as
chris
mentioned,
we
do
have
a
well
a
set
of
things
that
we
want
to
to
propose
as
a
discussion.
C
A
trend
that
we
are
seeing
in
the
community
where,
where
we
are
trying
to
organize
different
things
with
regards
to
versioning
releases
roadmap
and
all
this
kind
of
is
expected
to
improve
as
the
the
project
also
evolves
and
the
community
evolves.
So
what
I'm
gonna
present
today
and-
and
there
are
lots
of
people
in
the
call
that
that
will
also
have
something
some
things
to
add-
is
this
main
topics
or
global
topics
that
we
need
to
keep
keep
discussing
and
evolving?
I
I've
got
some
suggestions
of
specific
actions.
C
So
it
all
starts
with
our
release.
Cadence
we've.
I
think
we
have
done
a
release
last
year
in
the
third
quarter
of
our
calendar
2020,
and
we
are
pretty
much
involved
in
doing
a
release
right
now,
but
it
was
sort
of
we
discussed
this
a
while
ago,
I
think
around
april,
and
now
it
kind
of
just
kind
of
yeah.
C
C
D
Yeah
thanks
leandro,
like
my
suggestion,
is
pretty
pretty
straightforward.
I
think
we've
had
we
like
now,
we've
got
the
0.8
release
out,
which
is
fantastic
or
we're
getting
close
to
it,
like
that's
a
whole
year's
worth
of
software
development
into
one
cut,
and
I
think
we
now
need
to
start
practicing.
This
more
often
get
ourselves
more
used
to
this
idea
of
doing
releases.
D
So
I
like
for
me
the
next
steps
is
to
look
at
what
we
could
do
for
another
release
and
how
do
we
iteratively
improve
to
the
point
where
you
know
we
can
get
things
on
roadmaps
and
also,
I
think,
one
of
the
things
that
andrew
started
doing
around
the
last
release
was
starting
to
collect
together
just
issues
that
we
wanted
to
include.
So
we
started
to
plan
more
rigorously
what
our
release
looks
like.
D
C
E
Yeah
absolutely,
I
also
agree
that
having
more
frequent
with
releases
is
a
great
idea
and
I
think
it
would
be
great
to
incorporate
that
on
the
road
maps.
Actually,
if
you
look
at
my
original
proposal
for
the
road
maps,
I
did
things
by
quarter
by
quarter
just
because
the
releases
aren't
regular
enough
for
us
to
like
categorize
things
into
releases.
E
E
C
Yeah
I
mean
yeah,
I
guess
we
are
all
on
the
same
direction
and
I
think
I
mean
it
sounds
awesome.
This
I
mean
the
efforts
on
drumroll
to
organize
release
filtering
many
hundreds
of
commits
to
to
put
that
into
a
release.
After
such
a
long
time,
I
think
we
could
sort
of
reduce
the
effort
needed
if
we
just
do
more
releases
that
will
generate
a
smaller
backlog
of
changes
and
and,
as
you
said,
incorporate
these
changes
that
we
all
need
to
learn.
C
F
Thoughts
as
well-
oh
sorry,
I
didn't
mean
to
interrupt
you.
No,
it's
fine
yeah.
I
mean
this
is
something
I've
been
also
thinking
about.
So
I
just
wanted
to
like
lend
my
support
for
the
idea
of
a
cadence
release.
I
I
was
I
I
was
going
to
kind
of
come
back
to
this
more
in
the
new
year,
but
I'm
glad
we're
talking
about
it
now,
and
you
know,
I
think
you
know
nothing
else.
You
know,
of
course,
like,
like
the
open
source
process.
Goes.
F
We
wouldn't
necessarily
decide
anything
here,
but
just
like
I've
been
having
quite
a
few
thoughts
kind
of
just.
You
know
marinating
in
my
mind,
right
now
about
like
what
we
want
to
you
know,
cadence,
and
and
how
should
we
kind
of
go
about
this
and
I
think
yeah,
I
kind
of
support
the
quarterly
cadence
it
lines
up
with
the
roadmap
pretty
well
and
kind
of
on
the
release
process.
F
We
actually,
I
did
check
and
we
actually
have
like
the
steps
written
down
on
our
our
documentation,
for
what
the
release
process
is.
I
think
one
of
the
first
things
that
would
be
great
to
do
is
just
have
just
go
through
those
steps
with
junior
and
audit
those
steps
and
make
sure
that
that
actually
accurately
reflects
what
we're
doing
today.
Basically
to
do
that
process
and
start
codifying
right.
C
F
F
But
you
know
we
shouldn't
let
you
know
some
some
concern
about
0.9
being
the
last
pre
1.0
version
number
available,
stop
us
from
doing
quarterly
releases,
basically-
and
I
think
it'd
be
better
if
we
actually
started
to
work
on
the
release,
process
and
kind
of
nail
it
down
before
we
move
towards
stabilizing
to
1.0.
Basically,.
G
G
I
think,
for
historical
reasons
like
or
just
for
historical
context,
I
mean
we
were
for
a
while
getting
a
release
out
like
on
average
every
four
months
or
something
like
that.
I
think,
as
we've
grown
this
year,
we
haven't
really.
You
know
the
number
of
people
available
to
release
and
the
pro
the
amount
of
work
required
to
do.
It
is
like
kind
of
grounded
to
a
halt.
So
I
think
the
main
thing
just
to
emphasize
is
like.
G
I
think
we
need
to
make
the
process
more
automatic
easier
to
execute
so
that
it's
easier
for
us
to
distribute
as
more
people
grow,
and
I
think
that
is
the
most
important
thing
to
do
first
and
then
we
can
figure
out
how
to
stabilize
towards
a
1.0.
I
mean
for
more
example
like
I
was
when
I
was
working
on
rust,
which
was
during
this
grow
up
period.
We
did
the
same
thing
where
it
was
sort
of
chaotic
for
a
while,
and
then
they
stabilized
and
sort
of
these
train
releases
and
then
1.0
came
out.
G
E
Yeah,
I
agree
completely
with
what
you've
said
jared
and
having
talked
to
generou
as
he
did
this
release.
One
of
the
biggest
like
blocking
factors
was
trying
to
categorize
all
of
the
previous
commits
that
had
been
made
in
the
past
year
into
different
types
of
buckets,
and
this
is
really
something
that
we
would
be
doing
as
part
of
the
roadmap
anyways.
So
hopefully
that
lowers
some
of
the
burden
and
then
also
having
some
automated
processes
to
generate
the
release.
Notes
would
also
reduce
the
burden
even
further,
so
yeah.
G
C
Some
issues
are
not
so
easy
to
describe
because
one
they
include
fixes
in
different
parts
of
the
code
and
the
other
one
is
that
the
commit
messages
don't
represent,
what
is
being
committed,
so
it
makes
it
challenging
to
be
categorized
in
this
way.
So
again,
on
my
very
initial
topic,
this
is
something
that
we
have
been
discussing
around
and
gustavo
who's
in
the
call
he's
got
some
actions
being
done
in
that
direction
and
that
just
to
handle
the
thing.
G
Right,
I
think
one
thing
just
to
jump
on
that
leonardo
is
like.
I
feel
like
one
thing
andrew,
and
I
were
talking
about-
is,
I
think,
maybe
some
clarifications
and
improvements
like
in
terms
of
how
to
bring
process
changes
in
the
rfc
process
and
get
them
kind
of
ratified,
because
I
think
right
now,
like
people
are
just
really
busy,
and
so
they
kind
of
like
our
energy
is
diffused
because
everyone's
trying
to
get
their
own
features
out
the
door
and
we
have
stuff
going
on
inside
of
our
own
jobs
and
lives
and
everything.
G
So
I
think
if
we
can
like
kind
of
crystallize
the
ability
to
like
agree
and
move
forward
on
some
of
that
stuff,
that
would
help
quite
a
bit,
because
I
feel,
like
that's
one
of
the
missing
pieces,
to
doing
this.
It's
something
that's
on,
like
my
my
radar
to-do
list
to
think
about
yeah
cause,
then
I
I
think
it
would
be
easier
for
us
to
be
like
hey.
We
made
a
change
to
the
process
here
we
go
and
then
you
know
it's
easier
to
tell
people
what
to
abide
by.
G
I
think
on
the
commit
message
thing
too
part
of
it
is
also
as
reviewers,
I
think,
maybe
before
we
squash
rebase,
we
at
least
ask
for
people
to
rewrite
the
top
commit
to
have
a
more
useful
message.
Some
people
are
much
better
than
this
about
earlier
much
better
about
this
than
others,
and
so
maybe
this
is
just
something
that
we
add
to
the
review
guidelines
to
kind
of
stay.
H
Thanks
jared
yeah,
I
totally
agree
with
your
comments,
especially
with
the
thing
about
bisecting,
which
can
get
quite
complicated
in
some
times
and
in
that
sense
I've
we've
started
discussing
about
the
committee
quality
message:
equality
when
we
were
discussing
about
the
code
guidelines
some
time
ago,
and
there
was
a
discussion
created
in
the
this
discuss
forum,
and
I
just
would
like
to
you
know
share.
I
have
just
a
page
with
some
items
which
I
would
like
to
share,
which
are
the
thoughts
which
are
in
in
my
mind.
H
H
So
basically,
I
collected
it's
just
basically
a
kickoff
regarding
that
subject,
which
I
do
think
it's
quite
important,
and
this
is
an
excellent
time
to
start
discussing
that.
So
this
is
more
a
kickoff
and
sort
of
brainstorm
about
what
is
in
my
head,
and
basically
I
divide.
I
divided
this
into
sections.
The
first
one
is
is
more
related
to
the
limitations,
as
I
understand
it
of
github,
and
so
you
mentioned
about
the
bisecting
and
the
this
is
something
that
I
realized.
H
That
happened
a
few
times
back
when
we
had
a
future
been
contributed,
a
change
which
would
incorporate
some
fixes,
but
that
is
not
mentioned
or
even
divided
in
a
a
patch
set
and
it
will
complicated,
bisecting
and
or
even
when
you
get
log
for
the
logs.
This
also
complicated
things
a
little
bit.
So
one
of
the
things
I
I
realize
is
that
we
should,
you
know,
make
it
more
obvious
that
we
are
here
is
the
future.
H
H
Ideally
that
should
be
contributed
as
a
patch
set
right
in
my
understanding,
but
on
the
end,
on
the
other
hand,
currently
we
sca,
as
you
said,
we
squash
the
entire
pull
request.
So
even
if
somebody
starts
or
creates
a
pull
request
and
took
care
to
separate
all
the
commits
in
a
in
a
pa
in
a
patch
set
and
and
starts
a
pull
request,
it
will
end
up.
H
It
will
land
in
the
tree
as
a
single
commit,
and
for
that
I
don't
have
an
answer
for
that,
but
so
the
question
I
have,
would
it
possible
or
be
okay
to
lend
the
pure
requests
keeping
the
patches
that
structure
you
know?
So
if
it
so
like?
This
is
an
open
question.
I
don't
have
an
answer
for
that,
but
I
was
wondering
if
it
would
help
and
in
in
my
understand
it
would
help.
H
But
again
I
would
like
to
collect
some
inputs
and
start
a
discussion
about
it,
and
so
we,
what
I
mean
is
we
can
separate
the
commits
and
start
pull
requests.
But
in
the
current
state
of
affairs
we
land
as
a
single
commit.
This
is
a
poor.
This
is
what
I
understand
the
it
is
attached
to
the
limitations
of
the
github,
but
we
can
of
course,
tweak
that
a
little
bit
when
we
are
submitting
land
in
the
patch,
so
I
feel.
G
If
we
made
it
easier
for
people
to
send
prs,
then
we
could
just
send
different
pr's
that
land
as
a
clean,
singular
patch,
but
we
tend
to
mix
things
right
now,
because
if,
in
the
process
of
doing
code
review,
someone
finds
an
issue
like
I
feel
like
people
tend
to
just
make
the
fix
in
place
so
like
I
might
want
to
disentangle
like
I'm,
not
necessarily
against
this.
I
think
just
figuring
out
how
to
disentangle
all
these
things,
because
I
feel
like
one.
G
I
Yeah,
maybe
as
another
option,
rather
than
just
landing
in
maine
or
say,
squashing,
that
we
could
also
have
it
be
a
no
fast
forward.
Merge
because
that
might
help
with
the
keeping
of
the
full
patch
sets
as
separate
commits
that
all
are
leading
up
to
the
conclusion
of
the
pr,
but
would
maintain
a
clean
history
if
you're
only
ever
following
the
first
parents
of
the
see
github
history.
G
I
agree
we
definitely
don't
want
to
fast
forward.
I
mean
I
I
mean
just
pausing
for
one
second
on
why
we
rebase,
I
mean
the
main
goal
is
to
try
to
keep
the
history
clean
in
terms
of
like
not
intermingling,
so
I
mean-
or
at
least
that's
why
a
lot
of
other
projects
do
it
as
well.
I
think
these
are
good
things
I
mean,
I
guess
the
question
in
one
of
the
questions.
Kind
of
comes
back.
G
G
C
C
D
F
F
F
I
think
we've
done
this
in
the
past
with
rfc
and
I
think
that
actually,
in
general,
rfc
is
probably
maybe
the
right
way
to
to
discuss
this,
but
I
think
it
would
be
great
if
the
rfc
kind
of
had
like
a
a
closing
date,
basically
after
which,
like
a
vote,
was
called
or
something
like
that.
I
haven't
really
thought
this
through
entirely
yet
in
terms
of
the
proposal.
But
basically
you
know
something
just
a
little
bit
more
final.
F
F
I
guess.
A
limitation
of
our
current
arrangement
is
that
I
guess
in
in
past
code
review
systems
where
I've
worked.
You
know
there's
a
notion
of,
I
guess,
a
change
progression
or
a
pr
progression,
and
what
that
captures
is
like.
Let's
say
that
you
make
one
set
of
patches
that
you'd
like
to
contribute,
and
then
people
make
comments
and
then
what
you
do
is
you
you
incorporate
those
comments
by.
F
You
know
interactive
rebasing
and
you
actually
place
the
changes
on
the
internal
patch
that
that
makes
sense
for
those
changes.
So
in
other
words,
if
let's
say
that
you,
I
don't
know
rename
some
files
and
then
you
you,
you
know,
add
a
feature
or
something
like
that.
After
the
rename
and
someone
says:
oh
the
rename,
you
know,
I
think
we
should
really
call
it.
You
know
bar
instead
of
foo
or
whatever,
and
so
then
you
go
and
you
edit
the
rename
commit.
F
H
No,
no,
it
was
just
about
to
say
that
the
third
item
was
precisely
capturing
that
case.
That
andrew
mentioned,
where
we
want
to
keep
the
logs
for
the
reveal
logs.
But
at
the
same
time,
when
you
use
crash
all
the
you
know,
if
you
don't
do
dash
force,
it
lands
with
a
bunch
of
commit
messages
which
are
the
results
of
the
review
process.
So
there
is
a
kind
of
trade-off.
H
G
G
G
So
you
know
my
thing
is
like
if
we
can
find
easier-
or
you
know
maybe
workaround
solutions
that
fix
some
of
them
were
a
large
part
of
the
pain
for
us
like
by
maybe
it's
process,
or
whatever
is
probably
the
easiest
thing
for
us
to
do
now.
I
mean,
I
know
chris
put
garrett
in
again
because
he's
a
big
garrett
person,
but
you
know
adopting
another
tool,
is
probably
going
to
be
like
its
own
set
of
challenges
and
getting
everyone,
because
I
know
everyone.
G
G
H
The
title
forms
we
should,
you
know,
use
the
proper
caps.
I
see
a
bunch
of
the
commits
which
then
follow
the
proper
caps,
for
instance,
or
a
format
for
the
for
the
caps
and
the
title.
It
also
doesn't
tag
you
know,
like
microtvm
units
tests.
I
think
I
know
this
is
evolves
over
time,
but
as
the
comp
components
appear
in
the
project,
but
this
we
should
try.
You
know
to
stick
with
it
and
enforce
it
when
specialists
submitting
changes
from
others,
for
instance
yeah
just
just
one
just.
C
One
thing:
if
just
being
mindful
of
time,
we
we
have
less
than
20
minutes
now.
Just
I
was
just
sorry
to
cut
your
comment.
We
have.
We
have
two
people
who
who
raise
hands:
okay,
sorry,
yeah,
yeah;
no,
it's,
okay!
It's
okay!
I
was
just
say
that
we
could
discuss
how
given
we
have
this
initial
proposal,
how
how
do
we
evolve
this
to
to
become
some
to
become
a
process
change?
And
I
would
like
to.
D
C
E
Thanks
leandro,
so,
basically,
here
with
the
title
change,
I
think
this
has
some
other
good
implications
to
it.
If
we
can
have
those
proper
tags
that
can
help
us
with
the
overall
categorizing
of
all
of
the
pull
requests
that
leads
into
the
roadmap
and
also
leads
into
the
release
process.
So
really
glad
that
you
mentioned
that
on
the
side
of
the
process
changes
like.
E
I
think
this
might
be
a
really
wonderful
opportunity
to
maybe
battle
test
some
of
the
ideas
that
andrew
has
around
this
idea
of
an
rfc
that
could
trigger
a
pmc
vote,
and
I
really
also
like
that
idea,
because
it
gives
some
context
to
some
of
those
boat
threads
that
hasn't
existed
in
the
past,
so
yeah.
I
would
love
to
hear
your
thoughts
on
that,
but
let's
have
david
talk
about
his
thoughts
too.
B
Yeah,
this
is
more
regarding,
like
the
actual
code
reviews,
so
like
other
tools
again,
like
fabricator,
have
a
notion
of
like
diffs
or
changes
that
are
stacked
on
top
of
each
other.
So,
like
you
have
a
pr
that
depends
on
another
pr
all
the
way
down
to
main
or
whatever
the
base
is
so
one
thing
we
use
a
lot
in
pytorch
to
sort
of
hack.
This
behavior
into
github
is
a
tool
called
gh
stack.
B
So
basically,
what
that
does?
Is
you
use
that
to
submit
your
prs
and
in
that
world?
There's
no
patch
sets
every
commit,
is
a
single
pr
and
that
way
like
you
can
get
a
lot
of
this
stuff,
where
you
can
push
an
update
to
just
one
part
of
your
set
of
prs
and
review
that
locally,
but,
like
it's
still
one
like
unit
of
change
that
you
can,
you
know
navigate
around.
B
G
The
repo,
which
is
something
we
don't
have
like
not
for
everybody,
and
so
that's
like
one
I'm
like.
I
totally
am
like
like
this
idea.
I
guess
like
one
meta
question
that
might
be
worth
you
know
us
investigating
is
like.
Is
there
a
way
to
do
it?
That
works
with
like
the
apache
repo
permission
model,
because
that's
one
of
the
tricks
that
we
have
is
like
some
of
us.
You
know
a
few
of
us
on.
G
C
Yeah
yeah,
I
fully
agree
so
we
do
have.
I
was
checking
the
documentation
this
afternoon
and
we
do
have
sort
of
a
git
tips
and
tricks
page
in
there.
So
I
think
it's
much
easier
as
a
change
for
us
to
just
tell
so
hey.
So
there
is
a
way
around
this,
and
this
is
written
on
this
page
and
and
we
just
sort
of
educate
the
the
community
when,
when
we
face
those
problems
again,.
G
C
C
Know
is
really
really
really
painful,
so
I
guess
so.
We
still
have
around
15
minutes,
and
I
would
like
just
to
I
mean-
maybe
come
back
to
that
point
on
how
we
could
really
get
sort
of
the
actionable
items
that
we
discussed
and
and
and
perhaps
push
them
as
as
rfcs
or
this,
this
sort
of
a
new
type
of
rfc
that
that
we
could
trigger
a
vote
and
because
most
people,
I
think
in
this
call,
for
example,
when
they
release
this
topic,
we
can
discuss.
G
G
Like
the
two
largest
problems,
right
now
is
like
we,
we
want
to
make
process
changes
and
come
to
consensus
about
it,
but
because
we
sort
of
have
loose
consensus,
we
often
get
just
stuck
where
like
people
are
busy,
I
know
what
happens
like
everyone's
busy
people
have
their
own.
You
know,
kids
lives
whatever
you
know
we
discuss
for
a
couple
days,
and
then
people
forget
about
it
and
unless
it's
pressing
or
there's
another
comment,
no
one
comes
and
resolves
it.
So
I
think
giving
a
lever
for
us
to
like
force
resolution
to
occur.
G
I
think
that
should
ideally
help
us
like
scale
up
in
terms
of
having
a
a
better
process,
and
I
think
in
part
of
that
we
can
have
everyone
can
contribute
what
they're
feeling
in
terms
of
like
how
we
should
realize
that
and
what
constraints
they
have,
because
I
think
another
part
of
it
which
we
haven't
discussed
and
figured
out
is
like,
I
feel
like
we
need
an
owner
for
all
the
rfcs
like
again
like
just
because
I
spent
a
lot
of
time
working
rust
like
in
rust.
This
sub
team
owns
every
rfc.
G
I
don't
think
we
have
enough
committers
to
like
assign
many
people
to
everyone.
So
maybe
it's
a
dyad
or
triad
or
a
single
person,
or
I
don't
know
what
that
looks
like,
but
I
think
we
should
think
about
that
to
make
sure
that
we
sort
of
have
a
good
sla
quality
of
service
on
on
making
sure
rfcs
actually
get
out
the
door.
Because
again,
I
feel
like
as
we're
having
these
growing
pains
this
year,
like
we
have
not
been
as
good
about
getting
it.
D
I
think
to
extend
on
that.
There's
probably
like,
like
an
overall
structural
thing
in
tvm
around
who
owns
specific
areas
and
actually
is
responsible
for,
like
even
pull
requests,
which
will
probably
map
quite
neatly
to
rfcs
like
who
owns
like.
I
know
we
have
code
owners,
but
there's
quite
a
lot
of
people
who
turn
up
on
code
owners,
so
they.
G
G
So
I
think
it'd
be
nice,
but
where
do
we
have
that
conversation
and
resolve
it
again
like?
I
know,
we've
had
like
we've
danced
around
it,
but
like
if
someone
who
isn't
me
wants
to
go
resolve
that
process
right
now
like
how
do
they
do
that?
I
think
that's
kind
of
the
question
in
my
mind
is
like
I
want
to
give
other
people
the
tools
to
go.
D
Okay,
I
was
just
gonna
say
I
think
yeah,
that's
that's,
probably
our
biggest
concrete
action.
Then
it's
like
how
do
we
make
that
process
change
to
allow
all
the
other
process
changes,
because
I
think
that
the
worst
thing
we
could
do
leaving
this
session
would
be
to
say
we
need
this
one
process,
change
and
and
not
have
some
concrete
actions
for
us.
G
G
I
know
everyone's
going
to
have
different
takes
on
how
to
realize
this,
and
so
I
think
what
we
should
do
is
at
least
just
kick
that
off
and
then,
ideally,
maybe
before
tbm
conference,
we
have
something
concrete,
either
up
as
an
rfc
that
we
can
all
ratify
or
as
maybe
maybe
it's
a
pmc
binding
vote
kind
of
thing,
but
we
can
figure
that
out
together
because
there's
some
people
who
I
think
are
also
important
voices
who
are
not
here
right
now
so
like.
I
think
that
would
be
part
of
it.
G
Right,
I
think
also
one
thing
that
is
figuring
out
how
to
do
this
binding
part,
because
I
think
this
comes
back
to
like
the
round
robin
assignments
in
order
for
us
to
actually
make
a
change
like
that.
We
actually
do
like
anything
that
touches
infra.
For
example,
inside
of
apache,
requires
a
binding
pmc
vote
in
order
to
make
the
change.
C
F
Yeah,
I
was
just
gonna
say
I
think,
there's
a
few
wrinkles
in
this
like
how
many
of
these
binding
changes
can
be
open
at
once.
What's
the
order
of
doing
things,
what
are
reasonable
time
frames?
Who
can
own
these
things
and
yeah
just
a
lot
of
other
issues
that
we'll
have
to
kind
of
sort
through
and
yeah?
F
I
think
that
this
rfc
plus
pmc
thing
is
going
to
take
a
little
while
to
you
know,
kind
of
formalize
and
write
down
and
and
come
to
agreement
on,
I'm
kind
of
on
the
fence,
whether
we
should
wait
for
that
or
just
open
an
rfc.
That's
not
the
traditional
type
of
rfc
and
almost
pilot
the
process
with
this
kind
of
a
change.
There's,
no
reason
why
someone
can't
currently
just
say
this
was
discussed
on
the
rfc
forums.
C
So
I
was
just
thinking
on
whether
thinking
thinking
on
on
gustavo's
recommendations
for
code
reveal.
I
was
thinking
that
more
just
as
a
a
regular
pr,
including
documentation.
For
that
I
mean
I,
I
think
some
things
could
be
sort
of
a
simplified
that
if,
if
we
agree,
because
in
the
end
that
that
would
be
the
the
concrete
item
right.
F
G
Yeah,
I
I
think,
if
we
can,
I
don't
think
we
have
to
block
doing
the
commit
changes.
My
only
like
suggestion
would
try
to
be
maybe
split
them
out
into
like
three
suggestions,
and
that
way
we
can
have
like
a
more
incremental
debate
about
the
individual
suggestions
instead
of
I
I
feel
like
one
chris
sullivan
said
this,
and
I'm
just
gonna
repeat
it.
C
C
G
C
C
We
we
go
on
on
rfcs
and
and
these
things
I'm
I'm
curious
as
well
on
seeing
how
we
could
go
about
with
the
releases
point
to
my
on
my
understanding
then
so
this
is.
We
are
free
sort
of
to
release
as
many
times
as
we
want
by
apache
rules
like
we,
we
released
only
once
this
year
and
I
don't
think
that
yeah.
C
G
I
think
the
challenge
is
that
we're
not
set
up
to
do
that.
For
example,
just
going
back
to
like
my
rust
example,
what
they
did
is
they
built
a
bunch
of
machinery
to
get
on
a
six-week
cadence
so
that
they
didn't
end
up
like
python,
where
you
waited,
you
know
a
year
and
a
half
to
do
one
release,
and
then
it
took
a
decade
to
move
versions.
G
So,
instead
of
you
know
dumping
a
bunch
of
changes
on
people
all
at
once
and
then
hoping
everyone
ports,
you
can
kind
of
bring
people
with
you
every
week.
You
know
piece
by
piece,
and
I
think
that
is
kind
of.
If
we
want
to
be
in
that
world,
we
just
need
to
set
ourselves
up
from
a
tooling
and
process
perspective,
where
it's
possible
to
do
that.
For
example
like
if
you
already
have
the
change
log,
you
have
all
the
issues
categorized.
G
D
I
think
the
so
my
concern
is
waiting
for
that
tooling
process
to
come
together.
You
know,
I
think,
that's
why
I
suggest
doing
this
iteratively
like
trying
to
get
to
a
release
faster
now,
and
you
know
we
kind
of
had
to
take
the
burden,
but
also
learn
what
we
need.
So
if
we
do,
if
we've
slowed
down
because
it's
hard
work,
then
we
need
someone
else
to
do
the
next
phase
and
hopefully
get
some
learnings
from
you
know
the
way
genre
did
it
and
continue
moving
forwards
and
then
hopefully
we
we
do
grow.
G
Yeah
yeah,
I
I
agree
I
mean
I
would
be
totally.
I
think
that
the
one
thing
I
would
advocate
for
is
like.
Let's
pick
one
one
improvement
we
know
is
gonna
help
and
then
try
to
release.
For
example,
my
personal
bias
would
be
like
let's
get
the
roadmap
and
try
to
do
the
issue
tagging
and
then
try
to
cut
a
release
again,
because
I
we
know,
I
think
that
that
would
move
the
needle
a
little
bit
on
on
the
effort
and
we
would
find
out
what
doesn't
work
about
that
process.
G
D
Yeah,
I
think
that
that
is
like
a
really
good
first
step.
It's
just
try
and
collect
together,
because
I
think
yeah,
it's
the
difference
between
the
release.
We've
just
done
would
be
to
just
collate
the
things
we
want
in
a
release
ahead
of
time.
That
would
be
a
good
step.
I
guess
what
what
would
be
the
the
way
to
go
about
that
and
get
that,
because
I
think
right,
apache
release
is
still
like.
It
requires
a
pmc
person
with
an
actual
machine
or
something
to
support
it.
G
I
think
when
producing
those
packages
and
assigning
them
is
the
last
step
that
requires
someone
to
do
that
again
if
everything's
prepared
and
then
you
know
or
too,
like
you
know
in
that
world,
I
don't
think
it's
as
much
work.
I
mean.
Maybe
the
first
step
is
proposing
this
week
or
whatever
next
week,
or
maybe
at
tvm
con
after
tvmcon
that
we
do
a
zero.
You
know
zero,
ten
release
or,
whatever
sorry,
zero,
nine
yeah,
I'm
always
off
by
one
anyways
yeah.
We
do
this.
G
My
brain
is
just
moving
already
and
that
we
start
to
prepare.
I
mean
because
I
think
that's.
The
other
thing
is
like
you
know.
Partly
my
analysis
is
because
tnt's
been
busier
at
cmu
like
he
normally
was
one
kicking
off
the
the
push
to
actually
make
the
release
happen,
and
no
one
did
that
this
year.
So
I
think
if
we
start
that
conversation
of
like
what
are
the
things
that
need
to
get
done
to
make
the
next
release
happen
now,
then
we
could
start
to
maybe
assemble
all
genders.
G
A
C
G
Yeah,
I
think,
because
there's
like
two
things
that
I've
been
working
on,
one
for
tbmcon
is
like
trying
to
refine
all
the
various
things
technically
that
we're
up
to,
and
I
think
then
this
is
sort
of
like
trying
to
refine
build
a
process
for
refining
what
we're
trying
to
do
in
the
community,
because
I
think,
in
order
to
do
all
the
stuff
that
we
want
to
do
the
next
year.
Those
like
we
need
like
simultaneous.
G
A
All
right
well,
thank
you
everybody.
This
was
a
fantastic
meeting
and
I
appreciate
everyone's
participation
and
you
know
it's
exciting
to
see
the
release
process
grow,
and
so
you
know
thanks
for
taking
the
point
on
this
leandro
for
proposing
it
for
the
for
the
process
this
month.
So
we'll
see
you
all
next
month,
at
tvmcon
and
yeah
have
have
a
great
day.