[quote="gromero, post:8, topic:12334"]
I think the onus should *not* be on the reviewers, and I think that an ask like
that would avoid it: it’s a submitter’s duty to write a good commit message,
just like a correct/good code.
[/quote]
I definitely agree we should try these suggestions and add
[quote="manupa-arm, post:5, topic:12047"]
I am not sure I follow this proposal. Can you elaborate ?
[/quote]
It's mostly that we trust all code running on a branch but not necessarily code
running from PRs from forks, same as how Jenkins treats the `Jenkinsfile`
today. After thinking about thi
[quote="areusch, post:4, topic:12220"]
committers have reviewed and one wants to approve the PR but not merge it until
the others have looked the PR over.
[/quote]
One of the main reasons of this work would be to explicitly remove this step,
though it makes sense to still limit the ability to
# [RFC] Merge Bot
## Summary
PRs authors must currently wait for changes to be manually merged by a
committer clicking the "merge" button. A large amount of time can often elapse
between CI going green, a PR being approved, and this merge button being
pressed. This RFC proposes a safe, self-
TVM has two methods of user engagement today:
* GitHub [PRs](https://github.com/apache/tvm/pulls) and
[Issues](https://github.com/apache/tvm/issues)
* The [Discuss forum](https://discuss.tvm.apache.org/)
Historically both GitHub and Discuss have been used to develop on TVM, with
design discus
Posted the https://github.com/apache/tvm-rfcs/pull/58 with some links to PRs
that should address some of the concerns.
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/13)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscri
[quote="areusch, post:7, topic:12095"]
I agree we have this, I’m not sure it scans very well (for example, the links
are in Markdown so someone isn’t going to mentally parse those and render them
in their head). Perhaps we can improve the template and make it a bit more
organized.
[/quote]
It was brought up that it would be nice to have the ability to not only cc
specific people as reviewers but groups of people by labels. PyTorch does
something [similar](https://github.com/pytorch/pytorch/issues/24422) which we
could mostly copy. So labels could be automatically assigned based
Running arbitrary commands directly on the node is already possible in several
places in the `Jenkinsfile`:
* https://github.com/apache/tvm/blob/main/Jenkinsfile#L97
* https://github.com/apache/tvm/blob/main/Jenkinsfile#L127
* https://github.com/apache/tvm/blob/main/Jenkinsfile#L167
So our secu
# **Summary**
Move `.github/CODEOWNERS` to `.github/CODEOWNERSHIP` to avoid triggering
GitHub’s [automatic review
requests](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#about-code-owners).
Add GitHub Acti
# Summary
Rebuild Docker images per-build rather than use the pinned Docker Hub images in
the [Jenkinsfile](https://github.com/apache/tvm/blob/main/Jenkinsfile#L48-L54).
# Guide
Note: This is a spin off discussion from
[https://discuss.tvm.apache.org/t/rfc-a-proposed-update-to-the-docker-ima
On the implementation side a bot (likely this new one:
https://github.com/tvm-bot) with triage-level permissions could ensure that
`[skip ci]` is present in the PR title if any of the commits in the PR have
skipped CI (if a commit comes later on where CI isn't skipped, the submitter
can manua
12 matches
Mail list logo
