Based on the two RFCs I've reviewed, there are two points related to the
RFC tracking issue could be improved IMHO.
1. We currently state that the tracking issue should be opened after the RFC PR
is merged. However, it means the author needs to file another PR to update the
issue link, which se
cc @tqchen @hogepodge @areusch @jroesch
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/13#issuecomment-887681011
Hi @comaniac,
Thanks for suggesting this, it's been on my mind :smile_cat:
I'd suggest that "nearly done" is ambiguous? As a less ambiguous alternative
I'd propose always opening a tracking issue (if the RFC is big enough to
require it) when you raise an RFC and if it ultimately gets rejected
> I'd suggest that "nearly done" is ambiguous? As a less ambiguous alternative
> I'd propose always opening a tracking issue (if the RFC is big enough to
> require it) when you raise an RFC and if it ultimately gets rejected we just
> close the issue? This also allows code to evolve alongside th
cc @apache/tvm-committers for awareness. Given this change seems to be
non-controversial, we can adopt lazy consensus and merge after 3 days if no
objection comes up
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://g
LGTM thanks @comaniac
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/13#issuecomment-887696449
> > I'd suggest that "nearly done" is ambiguous? As a less ambiguous
> > alternative I'd propose always opening a tracking issue (if the RFC is big
> > enough to require it) when you raise an RFC and if it ultimately gets
> > rejected we just close the issue? This also allows code to evolve alon
> Deleting an issue is not something we should do - keeping a record of why
> something was rejected is useful on a later date to know why but perhaps the
> issue of too many issues with the label is solved by a query for open
> rfc-tracking issues ?
>
> Ramana
I think the record would always
i don't mind if we have a bunch of closed tracking issues. we can categorize
them. i agree with @u99127 that maintaining a record is important, and i also
think it makes sense that the first PR to land on a tracking issue would be its
RFC. i think committers should be able to notify authors at t
> i don't mind if we have a bunch of closed tracking issues. we can categorize
> them. i agree with @u99127 that maintaining a record is important, and i also
> think it makes sense that the first PR to land on a tracking issue would be
> its RFC. i think committers should be able to notify auth
@comaniac the RFC in my mind is mainly a design-level description of some
aspect of TVM. Like e.g. PEP, they are meant to be consumed by people less
familiar with the TVM codebase in order to gain familiarity.
the tracking issue, on the other hand, documents the method and progress by
which th
> @comaniac the RFC in my mind is mainly a design-level description of some
> aspect of TVM. Like e.g. PEP, they are meant to be consumed by people less
> familiar with the TVM codebase in order to gain familiarity.
>
> the tracking issue, on the other hand, documents the method and progress by
>> On generate_project method, and considering TVMC, my only comment is that it
>> should allow a project creation based also on MLF .tar, instead of only a
>> "live" executor.
>I agree; let's merge additional logic in project.py to do this as follow-on to
>this impl.
Sure! I'll submit a follow
@Mousius please take another look when you can and explicitly approve!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/8#issuecomment-887879286
Thanks for driving this review @comaniac. I'll get to this later in the week.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/6#issuecomment-887889315
@tkonolige @guberti @mehrdadh please take another look and explicitly approve
if you're good w/ this
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/8#issuecomment-887894876
@comaniac i view the core data structures and interfaces as part of the
design-level documentation. i think they belong in Reference-level explanation.
see for example my RFC #8 --this includes the introduced interface as part of
the RFC. details such as where code lives are not considered in th
I'm not sure I envisioned the tracking issue number/link be explicitly placed
into the RFC. The tracking issue referencing back to the RFC PR and and RFC
itself seems like it would be sufficient, but I can understand the desire to
codify that as part of the RFC.
--
You are receiving this becau
18 matches
Mail list logo
