Merged #13 into main.
--
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#event-5107036807
> Meanwhile, I do agree that "nearly done" is too vague. I might rephrase it to
> "when the RFC is about to be accepted, a committer should remind authors to
> open a tracking issue and update the link before merging". How does that
> sound?
Thanks for updating this, I think this is much better
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
@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
> @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
@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
> 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
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
> 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'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
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
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
> 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
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
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
15 matches
Mail list logo
