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> > > >
