Thanks Ming. Certainly, different PMC can take a different approach towards release. We are not suggesting that every PMC should take our approach. In the particular case of TVM, the community has been working on several major features including Ansor, uTVM and it does not make sense to cut the release say right now.
Again, the PPMC wants to produce high quality releases according to feature plans coordinated with the community, rather than creating more releases. Notably the last release was pretty recent as well. While there is one release manager in the past two releases, many PPMC members(including myself) participated in the release to make sure that release is in high quality. I imagine I could have added my name to the release manager as well :) Also the PMC contains several Apache members who have previous experiences in cutting releases in TLP projects. So we are very confident that the PMC can continue to do so. TQ On Fri, Aug 28, 2020 at 7:25 PM Ming Wen <wenm...@apache.org> wrote: > I think only two releases and only one release manager are blocking issues. > Considering that TVM merges 150 PRs a month on average, but only two > releases within a year and a half, that is, users use codes that are much > behind the master, which is not friendly to the community. > > Second, there is no conflict between high-quality releases and frequent > releases. Many Apache projects have maintained frequent and high-quality > releases. > > Third, since there is a good release document, why is there no other ppmc > to serve as release manager? > > Tianqi Chen <tqc...@apache.org> 于 2020年8月29日周六 上午9:51写道： > > > Thanks Matt! > > > > That was indeed the approach we used before. The main problem of this > > approach is > > - There could be certain upstream changes (say tensorflow get updated) > that > > may not retrigger the rebuild > > - The CI instance itself can quickly get crowded by the historical cached > > images and causes disk overflow problems. > > - Overall we find it is very hard to reproduce the CI error when there > is a > > problem because of the potential mismatch(due to stale build) > > > > So the community switched to using a stable binary tag as for more stable > > env without blocking the CI, while periodically updating > > these images when this is a dependency change. > > > > TQ > > > > On Fri, Aug 28, 2020 at 6:47 PM Matt Sicker <boa...@gmail.com> wrote: > > > > > Is there even a need to upload the Docker images for CI? Docker > > recognizes > > > layers by checksums, so CI build agents will cache the image layers > > > regardless of whether or not you upload them to Docker Hub. Layers get > > > rebuilt when the Docker file changes or you force an update. > > > > > > On Fri, Aug 28, 2020 at 20:12 Tianqi Chen <tqc...@apache.org> wrote: > > > > > > > Thanks Justin and Henry for the discussion thread. > > > > > > > > > > > > > > > > Please allow me to dissect and summarize again some of the discussion > > > > > > > > points:) > > > > > > > > > > > > > > > > C0: Docker Image > > > > > > > > - There was a mis-understanding that the docker image like ci-gpu > > > > > > > > contains tvm. They do not, and instead contain an environment to > > > > > > > > build and run test cases. > > > > > > > > - The thirdparty binary cache is used to speed up the test build. > > Anyone > > > > > > > > could build these binaries from a TVM source. > > > > > > > > - To avoid confusion about the branding, we have renamed the docker > hub > > > > > > > > name to > > > > > > > > a different name that does not contain tvm so that it is clear as a > > > > > > > > thirdparty. > > > > > > > > > > > > > > > > C1: Pointing to Apache Release > > > > > > > > - The PPMC 100% agree that we should produce high-quality Apache > > > > > > > > compatible releases, and refer to them in the documents. > > > > > > > > - The installation documentation points to the official release > > download > > > > > > > > page [1]. > > > > > > > > - There is a for developer section, which gives instructions to > > > developers > > > > > > > > about > > > > > > > > how to clone the code from the git repo. > > > > > > > > > > > > > > > > C2: Number of releases > > > > > > > > - The PPMC wants to produce high quality releases according to > feature > > > > > > > > plan coordinated with the community, rather than creating more > > > releases. > > > > > > > > - The release process is well documented[2], > > > > > > > > - Per incubator policy[2], number of releases is not a hard bar for > > > > > > > > graduation. > > > > > > > > "Podlings do not need to actually publish a release...". Instead > the > > > most > > > > > > > > important > > > > > > > > thing is the demonstration of being able to cut apache release. > > > > > > > > - Besides the release process being well documented and there are > > already > > > > > > > > two high-quality releases(without WIP). The PMC contains several > > Apache > > > > > > > > members > > > > > > > > who have previous experiences in cutting releases in TLP projects. > > > > > > > > We are very confident that the PMC can continue to do so. > > > > > > > > > > > > > > > > C3: The discourse forum > > > > > > > > - The discourse forum, like the use of github, is mainly a way for > user > > > > > > > > community to > > > > > > > > engage with the project. > > > > > > > > - The usage of discourse forum is voted by the community[3] > > > > > > > > - The community follows the public archive principle, which means > > > > > > > > everything is archived > > > > > > > > to mail-lists. Again, everything happens (also) happens on a > > mail-list. > > > > > > > > - The discourse forum is currently maintained by a few PMC members as > > > > > > > > volunteers, > > > > > > > > as a thirdparty service to the community. > > > > > > > > - Again, the development happens in github, everything mirrored in > dev@ > > . > > > > > > > > The existence of the forum > > > > > > > > would not block the development. > > > > > > > > > > > > > > > > Finally, to summarize. I believe one of the main reasons behind these > > > > > > > > issues are trust rather than procedural. > > > > > > > > As a ASF member, I am certainly strive to make sure the related > > volunteer > > > > > > > > maintained resources > > > > > > > > will continue beyond a certain individual by many ways including: > > > > > > > > > > > > > > > > - Introduce multiple volunteers from different organizations in the > PMC > > > to > > > > > > > > do the work. > > > > > > > > - Make sure the messages are backed up to mail-list. > > > > > > > > - Help INFRA to manage certain services instead if they are willing. > > > > > > > > However, note in cases like CI > > > > > > > > INFRA is also happy to let the PMC make specific choices. > > > > > > > > > > > > > > > > While many of the arguments in the above points boils down to "what > if > > > the > > > > > > > > few people did something evil via loophole X". > > > > > > > > And similar arguments can be applied to committer nominations in > > general. > > > > > > > > As I may quote from our committer > > > > > > > > nomination message "We like to work on trust rather than unnecessary > > > > > > > > constraints". > > > > > > > > This is the message that keeps bringing me back and makes me proud > as a > > > ASF > > > > > > > > member. > > > > > > > > > > > > > > > > There is no "one way" to the Apache way[3]. IMHO, the best thing I > love > > > > > > > > about the ASF is indeed the people, and the > > > > > > > > trust we give to each PMC as long as things are operated under the > > Apache > > > > > > > > Way. The TVM PPMC has been working hard to > > > > > > > > build a healthy, diverse and independent community. And strives to > > > protect > > > > > > > > the Apache brand and uphold apache release policy. > > > > > > > > Again, we welcome constructive feedback for continued improvement. > > > > > > > > > > > > > > > > Thank you! > > > > > > > > > > > > > > > > TQ > > > > > > > > > > > > > > > > ----- > > > > > > > > - [1] > > > > > > > > > > https://tvm.apache.org/docs/install/from_source.html#install-from-source > > > > > > > > - [2] https://incubator.apache.org/guides/graduation.html > > > > > > > > - [3] > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread.html/c34b728f01d1030146594e47e0706cd1990ed731d06e3c179b7d501a%40%3Cdev.tvm.apache.org%3E > > > > > > > > - [4] https://www.apache.org/theapacheway/ > > > > > > > > > > > > > > > > On Fri, Aug 28, 2020 at 5:15 PM Henry Saputra < > henry.sapu...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Sure, that is easy to fix and good suggestion. But, hope it is not > a > > > > > > > > > blocker issue. > > > > > > > > > > > > > > > > > > On Fri, Aug 28, 2020, 5:09 PM Justin Mclean < > > jus...@classsoftware.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The "install from source” page should probably point people to > the > > > > source > > > > > > > > > > releases rather than the latest code in GitHub. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Justin > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > > > > > > > For additional commands, e-mail: > general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Matt Sicker <boa...@gmail.com> > > > > > >
