►
From YouTube: Apache TVM Community Meeting, May 11, 2022
A
Okay,
so
good
morning,
everyone
and
welcome
to
the
may
11th
edition
of
the
tbm
community
meeting,
I'm
andrew
I'm
one
of
the
tm
community
members,
and
so
today,
on
our
agenda.
Let's
see,
we've
got
our
usual
introductions,
additions
and
changes,
announcements
and
then
just
some
demos
to
walk
through
so
yeah.
This
time
just
wanted
to.
B
I
guess
I'm
the
first
time
the
first
time
that
I
joined
this
this
meeting
most
of
the
time
I
just
I
just
forget
about
it,
look
it's
on
my
calendar.
I
mean
it's
on
on
the
website,
but
then
I
forget
to
join
anyway,
so
my
name
is
christoph
christopher.
I
work
at
qualcomm
innovation
center
and
recently,
we've
really
ramped
up
the
effort
to
port
or
to
add
hexagon
as
a
full,
fledged
target
to
tvm
and
there's
a
lot
of
work
going
on.
B
A
A
Okay,
hearing,
no
others
we'll
go
on
to
our
our
next
little
bit
here,
so
just
want
to
open
up
for
any
additions
or
changes
to
the
agenda.
If
anyone
wants
to
bring
anything
up
and
talk
about
anything,
you
can
also,
let
me
know
here
or
just
add
it
to
the
agenda
list
and
hearing
none
of
those
we'll
move
on
to
announcements.
So
excuse
me
yeah
this
week
we
just
have
a
couple
new
reviewers,
so
I
guess
it's
been
a
couple
of
weeks
since
we've
done
this,
so
this
was
maybe
cumulated.
A
Couple
weeks,
but
ashitosh
and
nikola
from
arm
are,
are
now
reviewers
welcome,
as
well
as
alton
from
optimal,
and
we
have
one
you
committer
shio,
sao
also
from
optimal,
so
welcome
and
congratulations
and
so
moving
on
to
discussion
topics
this
this
morning
we
did.
We
have
a
couple
of
things
we
want
to
talk
about
today.
I
was
gonna,
give
an
update.
A
I
think
it's
something
that
has
been
coming
up
in
the
community
and
you
know
the
idea
of
getting
to
a
faster
release
cadence
so
that
we
can
get
changes
out
the
door
into
sort
of
a
pivot
solvable
form.
You
know
stable
consolable
form
much
more
quickly
will
kind
of
help
drive
adoption
of
tbm.
We
think
so
anyway,
we'll
talk
about
that
in
a
minute,
so
updating
just
on
the
the
python
dependencies
side
of
things.
A
A
A
test
run
run
a
ci
run
the
ci,
using
that
you
know
container
basically
to
test
it
and
and
see
to
see
if
anything
broke
against
the
new
container
and
since
then,
we've
actually
made
substantial
improvements.
There,
we've
we've
created
a
bot
that
automatically
builds
all
of
the
different
ci
containers
and
then
that
bot
then
can
then
you
know,
run
the
ci
kind
of
in
a
test
mode.
A
A
Basically
inside
of
this
docker
install
directory,
and
it's
just
a
series
of
pip
install
commands
now
prior
to,
I
think
it
was
like
october
2020,
these
pip
install
commands
because
they
were
kind
of
scattered
around
resulted
in
a
virtual
environment
installed
in
the
container,
or,
I
guess,
a
python
environment
in
the
container
that
could
contain
inconsistent
dependencies.
In
other
words,
if
tensorflow
depended
on-
let's
say
asher's,
you
know
version
18.,
but
sphynx
then
depended
on
azure's
version.
20.
and
tensorflow
said
it
wasn't
compatible
with
20..
A
A
You
know
just
once
so
all
of
the
packages
kind
of
have
you
know,
version
constraints
placed
in
one
spot,
and
so
you
know
this
is
kind
of
the
first
step
in
my
mind,
to
kind
of
consolidating
these
python
dependencies
into
a
single
location
rather
than
being
spread
out
across
a
bunch
of
different
docker
install
scripts,
now
they're,
all
just
right
here
in
this
file.
Now
the
problem
with
this
is
a
couple
of
things.
One
there's
there's
no
teeth
to
this.
A
You
know
this
file
here
it
it
informed
the
setup.pi
which
is
kind
of
what
we
used
to
generate
the
install
requires,
but
it
didn't
it
didn't
have
any
bearing
on
the
ci.
We
were
still
using
these
and
today
we're
still
using
these
docker
install
scripts
to
actually
set
up
the
ci
packages,
and-
and
so
you
know,
these
constraints
are
kept
in
sync
just
by
convention.
It's
not
there's
nothing.
A
You
know
requiring
us
to
keep
ethos,
uvella,
pin
to
3.2.0
in
the
setup.pi,
but
rev
to
you,
know
4.2.0
in
the
ci.
So
the
next
piece
that
I
kind
of
wanted
to
give
you
guys
an
overview
of
today
is
how
we're
going
to
actually
enforce
this
file
or
or
a
proposal.
I
should
say
for
how
we
could
enforce
this
file
and
we
don't
have
to
do
this.
A
This
is
something
that
you
know:
we've
been
kind
of
cooking
up
and-
and
you
know
it's
it's
a
possible
way
to
solve
this,
but
it
could
be
complex
it.
It
could
be
you
know
or
or
it
could
just
be
reflective
of
kind
of
the
the
nature
of
dealing
with
python
packages.
So
that's
what
I
want
to
kind
of
give
you
a
tour
of
today.
A
So,
let's
see
it's
actually
been
a
while,
since
I've
read
this
rfc,
so
I'm
just
thinking
about
it:
okay,
so
kind
of:
what's
what's
the
the
next?
How
do
we
then
make
this
step
from
having
this
gen
requirements,
file
and
and
moving
into
a
world
where
this
reflects
itself
inside
the
docker
containers?
So
let
me
flip
over
to
terminal
here
and
the
right
terminal.
A
Cool
okay,
so
so
this
branch
is
is
freeze
dependencies
and
you
can
see
this
on
my
github.
I
just
pushed
kind
of
my
latest
work
here
a
minute
ago
or
two.
So
I
will,
you
know,
show
this
up
in
the
browser
a
little
bit
later,
but
looking
at
the
let's
see
so
the
gen
requirement
script
largely
stays
the
same,
and-
and
you
can
run
this,
although
I
I'll
be
at
I'll,
say
I
haven't
actually
done
this.
A
So
this
might
break
here's
some
debugging
information
and
it
will
generate
it-
will
generate
basically
a
a
list
of
all
the
python
dependencies
by
by
part,
and
so
here
we've
broken
up
tvm's
kind
of
dependencies
into
core
into
one
piece
for
each
different
front-end
importer,
one
piece
for
tvmc
and
one
piece
for
things
like
ethos.
U
and
and
lastly,
development
dependencies-
and
you
can
kind
of
see
well,
okay.
A
And
then,
on
top
of
this
there's
a
script
called
freeze,
depth
and
freeze
depth
takes
the
information
from
this
gen
requirement
script
and
it
synthesizes
a
pi
project,
dot
toml,
so
you
guys
might
have
seen
this
pi
project
automal
in
our
root
directory
and
up
until
now,
it
kind
of
has
looked
like
this.
You
know
has
this
tool.black
here
and
that's
just
about
it.
So
what
I?
A
What
I'm
the
tool
I'm
using
to
to
kind
of
enforce
this
python
to
consolidate
this
path
on
dependencies
is
called
poetry,
and
we
don't
have
to
use
this
as
just
one
option,
but
it's
it's
one
that
I've
used
in
the
past.
So
it's
something
that
I
was
just
playing
around
with
here
and
so
the
idea
here
is.
You
know
you
give
some
metadata
about
the
package
itself.
A
The
constraint
solver,
then
you
know,
determines
a
selection
of
python
packages
that
satisfy
the
constraints
and
satisfy
all
of
their
declared
required
version
dependencies
and
then
produces
what
they
call
a
lock
file.
And
so
you
can
see
that
I've
done
this
now
for
say
the
x86,
64
or
sorry
I'll
switch
over
to
the
internals.
I
don't
ruin
the
output,
but
for
the
x864
architecture
in
this
docker
build
and
I've
checked
in
these
files.
A
A
It's
selected
a
version
and
it's
indicated
sort
of
whether
or
not
it's
it's
optional
and
it's
kind
of
decided.
It's
it's
pulled
that
package
and
let
me
see
if
I
can
find
that
at
the
bottom
here
it
will
for
each
package
list
kind
of
the
sha-256
so
that
when
you
go
and
install
this
package
from
this
point
forward,
you've
captured
you
know
the
file
signature.
A
And
so
then
what
we
can
do
is
is
copy
this
poetry,
log
file
into
into
a
docker
container
and
run
poetry
install,
and
then
only
those
packages
that
have
been
installed
or
or
selected
during
the
lock
process
will
be
installed
and
so
for
each
image.
You
know
for
each
image,
let's
say:
ci
qmu,
ci,
hexagon,
ci
cpu
that
sort
of
guarantees
them
to
use
the
same
python
dependencies
when
built
at
the
same
time.
A
So
I
guess
I
wanted
to
pause
here,
because
I've
been
talking
for
a
little
bit
and
and
just
like
ask
if
there
are
any
questions
about
this
to
start
with
here,
there's
a
couple
other
aspects:
I
wanted
to
briefly
discuss
around
how
we
specify
the
constraints,
but
I
just
wanted
to
pause
here
and
see
if
that
made
sense
to
everyone.
I've
kind
of
been
going
through
terminal
for
a
little
bit
here.
D
B
A
We
do
use
that
on
windows,
I
believe-
and
it
might
be
worth
looking
at
that
as
well
the
one
so
one
of
the
things
that
I
think
we
talked
about
when
we
first
started.
This
effort
was
like
what,
if
someone
doesn't
want
to
use
poetry-
and
I
think
you
could
apply
that
to
what,
if
someone
doesn't
want
to
use
conda
tng
was
very
much
in
the
camp
of
like
we
need
to
have
this.
In
fact,
the
main
reason
we
have
this
requirements
here,
I
guess
in
some
other
repo.
A
The
main
reason
we
have
this
requirements
directory
here
was
so
that
we
could
reduce
this
all
to
something
you
could
install
with
pip
install
dash
r.
Maybe
that's
the
the
main
reason
why
I
kind
of
liked
poetry
is
that
it
doesn't
force
you
into
that
specific
ecosystem.
You
can
still
go
through
and
then
take
this.
E
Yeah,
I
think
my
my
experience
with
working
with
conda.
It
does
a
lot
more
as
well,
so
it
like
you
can
install
not
just
python
dependencies
but
loads
of
other
things
into
the
environment
which
can
become
quite
it
becomes
quite
cumbersome
to
manage
the
contour
environments.
I've
actually
had
teams
migrate
off
conda
into
poetry
for
python
dependencies,
because
it's
just
that
it
kind
of
wraps
all
the
python
specific
problems
without
doing
much
else
yeah
and
it's
it's
hard.
F
Go
ahead,
I
stepped
on
someone,
oh
no
yeah.
No,
I
I
mean
I've.
I've.
I've
tried
to
use
condom
before,
especially
like
in
the
tv
we're
working
with
tvm,
because
I
think
we
might.
We
might
have
some
condo
installs
that
we
do
and
then
what
I
found
is
that
when
condo
goes
wrong,
it
really
goes
wrong
and
that
it'll
take
it'll.
Take
the
dependencies.
Solvers
will
take
hours
if
you,
if
you
absolutely
haven't
kept
it
up
to
date,
and
I
just
I've.
A
On
the
other
hand,
we
do
use
it
in
the
windows
build
as
well,
and
that
seems
to
work
pretty
well,
and
so
having
that
I
mean
it
seems
like
we're
going
to
keep
that
around
to
some
degree
and
so
yeah
it
could
be
just
worth
watching
one.
You
know
one,
you
know
question
about
kind
of
moving
outside
the
pi
pi
world
or
moving
into
a
different.
I
don't
know
if
it
actually.
A
I
need
to
to
double
check
on
this,
because
I'm
not
sure
if
I'm
completely
up
to
speed
on
exactly
how
conda
imports
python
packages,
but
you
know
when
you
use
like
the
debian,
installed
python
packages.
I
think
that's
that's
now
widely
considered
to
be
harmful
because,
like
it
doesn't
really,
you
know
then
you're
dependent
on
your
operating
system's
package,
maintainer
to
just
you
know,
to
rev
the
package.
So
it's
like
one
extra
person
in
the
the
loop
there,
but
that's
a
I'm.
A
C
A
Lightweight
yeah
and
it
does
use
pip
and
it
to
actually
do
the
package
install.
I
believe
the
dependency
revolution
resolution
is
is
done
outside
of
pip.
I
was
going
to
show
that
here,
but
well
I'll,
get
into
that
in
a
minute,
so
is
that
I
don't
know
does
that
anyone
else
have
any
thoughts.
Here
too,
I
mean
I'm
happy
to
keep
talking
here
and
then
I'll.
I
can
also
cover
some
things
about
the
constraints
as
well.
A
Yeah,
so
let
me
talk
a
little
bit
about
the
constraints
and
I
want
to
leave
some
time
to
talk
about
the
quarterly
release
rfc
as
well
in
case
folks
have
thought
about
that.
So
you
know
one
of
the
challenges
I
think
we
have
is
you
know
suppose
we
hold
back
a
package.
You
know
the
question
is
like:
why
do
we
hold
it
back
and
there
can
be
a
couple
of
reasons.
A
So
the
idea
here
is
that
let's
say
that
someone
adds
a
package
and
they
depend
on
a
particular
version,
or
you
know
it
must
be
above
or
below
a
certain
version
of
a
python
dependency
and-
and
it's
known
at
the
time
that,
like
you
know,
let's
say
it's
you're
saying
I
can't
build
anything
past
0.7
on
on
something
like
here's.
This
doc
utils
package,
it's
known
at
the
time
that
you're
you
know
introducing
this
dependency,
that
the
later
version
of
the
python
package
makes
an
api
change.
A
It's
completely
incompatible,
and
so,
like
you
know,
there's
no
question
that
this
is
going
to
break.
If
you,
if
you
use
the
latest
version
of,
say
docutils-
and
you
know
here-
we've
got
some.
You
know
workaround
that
we're
we're
using
here
for
now,
so
this
gen
requirements
is
kind
of
in
in
this
particular
proposal.
The
place
to
put
that
that
kind
of
a
thing.
Now,
that's
not
the
only
reason
you
may
want
to
constrain
a
package,
and
so
the
question
is:
where
do
the
others
go?
A
So
what
I
have
right
now
is
another
file
called
ci
constraints
and
currently
it's
in
a
different
format,
but
I
think
there
may
be
some.
You
know
massaging
needed
here
on
this
idea
to
to
get
things
in
the
same
format,
and
there
are
other
reasons
you
might
want
to
hold
packages
back
like
let's
say
that
you
know
I
come
along
and
I
want
to
add
just
some
new
utility
dependency
to
to
tvm.
A
Without
kind
of
confronting
these
larger,
you
know,
version
drifts
that
that
can
happen
in
the
repository,
so
the
freeze,
depth
tool
actually
goes
and
reads
through
this
constraints
list
from
the
functional
constraints
and
then
augments
it
with
the
constraints
in
this
ci
constraints,
basically
allowing
us
to
impose
two
different
sort
of
types
of
constraints
on
the
on
the
sort
of
built
package,
and
this
also
lets
us.
Then,
by
separating
these
lets,
you
run
general
gen
requirements
and
produce
sort
of
like
a
pip
insoluble
list
of
of
sort
of
functional.
A
That,
then,
that
you
can
then
sort
of
trial,
locally
and
sort
of
float
those
ci
constraints
up
to
the
latest
version,
if
you
want
to
without
necessarily
sort
of
dragging
those
in
so
the
idea
here
is
that
when
we
build
these,
you
know
when
we
freeze
the
dependencies
on
these.
On
top
of
these
architectural
base
revisions.
A
We
then
pull
these
kind
of
constraints
in
here,
and
this
list
allows
you
to.
You
know,
make
changes
to
the
ci.
Without
necessarily,
you
know,
modernizing
different
importers,
and
things
like
that,
so
you
know
that's
another
piece
here.
Is
that
basically
having
separated
constraints?
Now,
where
is
this
going?
A
So
the
third
piece
of
this
kind
of
consolidated
python
dependencies
thing
that
I'd
like
to
to
work
on
once
we
you
know
address
this
sort
of
ci
centric
issue
is
okay
as
part
of
the
quarterly
releases
process
that
we're
kind
of
coming
up
to,
and
just
also
in
general,
we
want
to
release.
You
know:
pip
installable
packages
of
tvm.
Well,
those
pivot
soluble
packages
should
probably
have
some
kind
of
install
requires,
and
right
now
we
don't
necessarily
say
tensorflow
has
to
be
even
in
the
2.6
family.
A
It's
you
know,
it's
really
like
you
know,
tensorflow
is
any
version,
and
what
we
actually
do
is
maintain
a
separate
list
of
of
install
requires
again
in
the
tlc
factory.
I
believe
that
generates
the
you
know
the
declared
dependencies
or
declared
requirements
for
for
tensorflow,
so
we'd
like
to
clean
that
up
in
a
way
that
reflects
what
we're
actually
testing
against
into
the
the
generated
python
package,
and
so
you
know
there's
a
couple
of
ways
about
this.
A
One
way
is
that
we
take
the
log
files
from
from
poetry
and
you
know,
scan
those,
and
perhaps
we
like
relax
some
of
the
constraints
given
here.
So
here
we've
pinned
tensorflow
to
2.6.2,
and
you
kind
of
want
to
do
that
for
the
ci,
because
you
want
to
make
sure
that
you
didn't
rev
tensorflow
and
maybe
it
was
sure.
Maybe
it
was
a.
You
know,
point
release
a
revision
release,
but
you
know
revving
anything
or
changing
anything
can
easily
drag
in.
A
You
know
functional
test
changes
that
then
we
have
to
go
update
so
kind
of
in
the
spirit
of
maintaining
the
separate
ci
based
constraints.
We
want
to
say
you
know
exact
dependencies
here,
but
if
we
were
to
translate
this
into
something
we
wanted
to
put
into
a
wheel
that
people
installed,
we
might
want
to
allow
some
flexibility
in
case.
You
know
they
want
to.
You
know,
float
forward
to
2.6.4,
you
know,
there's
a
security
release
or
something
like
that
that
you
know
in
theory,
should
not
affect
you
know:
performance
or
functionality.
A
This
kind
of
thing
varies
per
package,
so
it
depends
on
the
versioning
scheme
packages
that
use
semver.
You
know,
then,
have
this
sort
of
revision
schema
that
says
that
things
should
be
backwards
compatible,
but
other
packages
release.
You
know
based
on
like
a
date
based
release,
versioning
number
or-
or
you
know
some
some
different
versioning
number-
that
we
need
to
kind
of
think
about.
So
where
is
this
all
going?
A
A
Let's
then
extract
some
some
representation
of
the
the
versions
that
we
expect
to
work,
perhaps
relaxing
the
ci
constraints
and
functional
constraints
a
little
bit
and
then
fill
that
into
the
install
requires
in
in
the
wheel.
So
that's
that's
kind
of
the
piece
I
wanted
to
talk
about
constraints,
wise.
B
A
So,
as
a
starter,
I
think
I'd
like
to
solve
that
problem
and
then
yeah
you're
right.
We
could
consider
doing
something
like
a
pre-release
test
when
we
released
the
wheel,
so
at
least
at
the
time
that
we
released
the
wheel,
we
kind
of
were
confident
that
if
we
allow
these
dependencies
to
float
a
little
bit
more
like
at
least
the
unit
tests
pass,
or
we
could
do
more
testing,
I
think
that's
a
reasonable
thing
to
to
consider
it
here.
A
I
guess
utilities
of
the
user,
and
one
of
the
things
that
can
be
bad
about
overspecifying
install
requires
is,
if
you
have
two
packages
that
specify
it's
all
requires,
and
they
don't
agree,
pip
can
refuse
to
install
it,
and
so
we
want
to
be
a
little
bit
judicious.
I
think
about
what
we
actually
state
as
a
explicit
version
requirement
an
install
requires.
It
actually
might
even
be
interesting
to
generate
two
such
python
packages,
one
which
does
in
fact
constrain
these
versions.
A
G
G
G
It
does
make
it
a
little
harder
to
contribute.
So
we
have
to
be
very
careful
to
you
know,
document
the
process,
everything,
and
so
it's
just
you
know
extra
work
for
you
andrew.
I
had
one
other
point
about
the
architectural
split
for
the
packages.
So
one
thing
I've
been
thinking
about.
You
know
our
ci
docker
images
are
huge
they're,
like
20
plus
gigabytes,
which
is
big
even
for
docker
images,
and
one
way
I
was
thinking
we
could
fix.
G
G
A
You
know
if,
like
one
image,
is
a
superset
of
the
other,
you
can
run
kind
of
all
of
the
scripts
that
form
the
superset
after
you've
run
the
the
base
set
of
scripts
that
build
the
image,
and
so
you
can
wind
up
with
kind
of
one
image
that
provides
say,
two-thirds
of
the
layers
and
then
on
top
of
those
two-thirds.
You
can.
A
You
know,
supply
sort
of
a
delta
edition
and
so
it'd
be
interesting
to
think
like
what
we
could
actually
reuse
and
not
reuse
and
kind
of
do
some
more
analysis
there
to
see
if
that's
kind
of
think
about
bang
for
buck
and
things
like
that
there
but
yeah.
That's
definitely
I
mean
that
seems
useful,
so
we
could
maybe
explore
that
yeah
further
thoughts
about
kind
of
consolidating.
All
this
stuff
is
everyone,
like
generally
supportive
or
is
this
seem
super
complicated
or
yeah.
E
I
think
this
is
a
generally
like
a
huge
improvement
over
what
we
currently
have
yeah
installing
non-deterministic
packages
introduces
all
kinds
of
problems
like
if
you
get
some
bad
actors
or
something
like
in
the
mpm
community.
They
had
some
packages
that
contained
like
bitcoin
farmers
and
stuff,
so
yeah.
I
think
this
is
just
good
practice
to
lock
this
down.
A
Some
of
the
things
that
can
be
tricky
here
is
you
know
if,
if
tensorflow
depends
on
one
version,
you
know
we're
we're
subject
to
the
same
things
that
we're
concerned
about
when
we're
filling
say,
install
requires
when
we're
doing
you
know
this
locking
here
so
tensorflow
depends
on
some
version
of
I
think
like
there
was
a
package
called
gas,
for
example,
that
paddle
paddle
used
one
version
and
tensorflow
use
a
different
version
so
like.
If
you
look
in
my
gen
requirements,
I've.
A
You
know
to
what
degree
we
start
highlighting
these
things
and
and
what
degree
they
actually
impact
functionality.
You
know,
as
we
kind
of
go
down
this
road,
so
I
think
there's
going
to
be
some
operational
questions
as
we
do
this,
and
I
have
some
thoughts
about
how
we
can
kind
of
address
this
specific
issue.
But
you
know
those
are
they're
kind
of
like
let's
solve
that
problem
when
we
get
there
kind
of
a
thing.
A
Another
thing
I've
done
here
is:
if
you'll
notice
tensorflow
has
different
packages
for
gpu.
When
you
want
to
use,
I
guess
cuda
or
gpu
acceleration,
as
well
as
for
art
64,
and
so
what
is
kind
of
nice
is.
There
is
a
way
to
select
a
version
dependency
based
on
the
platform
which,
like
the
the
declared
machine,
type
and
poetry,
actually
does
take
this
into
account
when
it
is
doing
the
dependency
resolution.
So
it's
able
to
actually
use
these
criteria
to
exclude
those
incompatible
dependencies
from
being
installed.
At
the
same
time,.
A
B
A
B
And
same
for
paddle,
paddle,
and
so
just
the
thought
that
came
to
my
mind,
right
now
is,
if
we
could,
let's
say,
have
like
a
quality
vm
that
doesn't
have
any
importers
in
it
and
then
have
additional
packages
with
importers,
so
that
someone
who
is
not
interested
in
paddle
paddle
wouldn't
have
to
install
everything
all
at
the
same
time.
They
can
just
install
let's
say
tensorflow
or,
or
you
know
whatever
else
they
need
so
that
they
are
less
likely
to
run
in
some
kind
of
conflict.
A
And
so
like
the
way
we've
handled
this
right
now
is
that
we
declare
so
these
pieces
here
are
things
that
can
be
installed
separately.
So,
like
I,
have
an
importer,
paddle
paddle
here.
This
means
that,
if
you,
you
know
what
you
would
do
is,
you
would
say,
pip
3
install
apache,
tvm
importer
paddle,
and
this
would
only
install
paddle
paddle
and
then
I
think
the
syntax
is
like
this.
A
A
The
way
to
solve
that
is
probably
to
move
the
importers
outside
of
the
virtual
environment
and
go
to
sort
of
a
plug-in
style
importer
system
where
the
process
of
importing
a
model
is
basically
tbm.
Invoking
a
sub
process
that
then
spits
out
relay
like
text
and
that's
a
more
invasive
change
side.
You
know
talk
about
that.
If
we
get
there,
I
think,
but
I
think
that's
that
anyway,
that's
that's
my
idea
of
how
we
could
solve
it
and
there's
certainly
open
entertaining
other
ideas
there
too.
A
Okay
yeah!
No,
I
wasn't
aware
that
it's
already
kind
of
done.
Yeah,
yeah,
no,
no
worries
I
mean,
and
you
know
this
will
all
be
surfaced
more.
I
think
as
as
it
you
know,
lands
and
all
that
and
and
you
can
actually
run
these
commands
so
yeah,
okay,
so
yeah,
let's
talk
a
little
bit
about
the
quarter
quarterly
releases.
Let's
see,
I
can
share
this
screen.
If
you
want
david
or
if
you
wanna,
I
can
do
it.
G
All
right,
you
guys
can
see
the
rfc,
yes,
okay,
cool,
so
I'll.
Just
give
a
brief
summary,
and
I
think
a
lot
of
people
here
have
already
left
comments
on
it.
So
we
can
just
sort
of
jump
right
into
the
last
few
discussion
points.
So
basically,
tvm
hasn't
done
a
real
release
since
last
november,
which
is
some
number
of
months
ago
now.
G
So
this
rfc
proposes
that
we
will
do
a
release
sort
of
automatically.
It's
not
really
a
right
word,
but
just
every
three
months
we
would
try
to
get
a
release
out
the
door
just
so
people
can
get
new
changes
from
tbm,
so
this
rfc
sort
of
lays
that
out
in
the
the
various
details
of
like
the
schedule
and
how
we
actually
do
the
release.
G
So
the
main
point
is
that
we
would
have
a
single
person
a
contributor
or
committer,
that
is
the
release
manager
that
would
sort
of
run
through
all
these
steps
do
everything
required
for
an
apache
release
as
well
as
some
of
the
new
stuff
we're
working
on
to
get.
You
know,
pi
wheels,
published
and
stuff
like
that.
G
So
if
you
want
the
details,
you
can
read
the
rfc,
it's
rfc
67
and
the
rcs
repo,
but
there's
been
a
lot
of
good
discussion
so
far
on
the
comments
thread.
Some
of
the
main
questions.
I've
seen
that
are
not
really
resolved
is
number
one.
What
versions
do
we
choose
chris
hodgepod
at
this
point,
but
right
now
I
think
we've
just
been
bumping.
The
minor
version
every
time
we
update,
which
is
sort
of
a
nonsense,
versioning
scheme.
G
So
we
might
want
to
change
that
as
well
as
other
things
like.
How
do
we
get
people
to
use
feature
flags,
so
we
can
have
better
support
for
different
versions.
You
know
as
we
move
across
time,
and
how
do
we
support
like?
What's
our
support
plan
for
old
versions?
Do
we
just
completely
drop
them
after
we
release
a
new
one
things
like
that
so
opening
the
floor?
If
anyone
has
any
thoughts
or
anything
like
that,.
E
I
would
just
say
that,
like
naught,
releases
typically
are
unstable,
I
think
in
semantic
versioning.
They
are
considered
to
be
like
they
anything
can
change.
So
it's
I
think
it's
totally
acceptable
at
that
point
to
not
give
any
guarantees.
I
just
start
rolling
them
out
rather
than
worrying
too
much
about
the
the
versioning.
A
All
right
yeah,
it's
like
because
we're
on
zero
dot,
something
or
other
so
at
some
point
we'll
switch
to
1.,
you
know
1.0
and
then
at
that
point
we
might
need
to
start
thinking
about
stabilizing
apis
and
well.
I
guess
before
that
point
when
we
start
thinking
about
lighting
apis
and
you
know
making
sure
that
we
don't
break
anything
too
much.
G
Yeah,
like
I
don't
know
too
much
about
the
historic
releases,
but
it
seems
like
at
least
for
the
most
common
apis
they're
already
kind
of
stable,
and
I
think
it's
good
to
get
in
the
practice
of
doing
that.
Even
if
we're
not
1.0
but
yeah.
I
agree
like
we
shouldn't,
spend
a
ton
of
time
on
it
right
now,
right,
I'm
just
getting
releases
out
the
door.
A
Anyone
have
any
other
thoughts,
I
think.
Releasing
you
know
on
a
cadence
makes
a
lot
of
sense
and
we
should.
We
should
move
to
to
do
that,
and
I
know
that
we
have
at
least
one
blocking
or
I
don't
know
blocking,
but
we
have
one
issue
that
I
I
need
to
resolve,
and
so
we
can
start
doing
that,
and
maybe
the
resolution
is
that
we
don't
resolve
it
just
around
the
tv
and
relay
build
api.
A
But
well,
if
we
say
our
apis
aren't
stable,
then
maybe
we're
good
yeah
but
yeah.
We
do
I
mean,
even
today
we
do
think
about.
We
do
a
sort
of
attempt
to
not
cause
a
lot
of
turn
in
terms
of
tvm
versioning
and
all
that.
So
it's
still
good
to
think
about
this,
even
if
we,
even
if
we
are
sort
of
in
this
policy
of
like
yeah,
we're
zero
dot.
So
we
may
change
things.