Thank you @areusch . First of all, I think @Hzfengsy has already addressed many points you bought up in the past, including: - Putting the CI/testing as part of the important factors to consider - Clarifying the definition of S0 - Clarifyng n how deprecation of S0 happens
I would like to acknowledge that you have made your point clearly in your last point. Most of those points are disagreement on how to do things. In light of such disagreement, it is important to acknowledge each others’ view, reevaluate, and come back to also put the community's voices into consideration. Let me first try to address some of the cases you bought up: My read is that the decision is around “module-establishment” but not blank approval of all code that comes. All the subsequent code changes are still subject to the normal review process. CI is indeed one important area of the codebase. It is also equally important in other areas, such as community member contributing code, document, importer, different modules. No area is certain superior to another one. We are working together to empower each other. One thing to keep in mind though is that CI/testing is only good if we have community members who come and use them. It is a great thing to have comprehensive tests, and we work collectively to resolve issues in testing, CI, system design, documentation and other places. Remember we are fostering a culture that empowers each other. Let us see how the two scenarios you mentioned will play out in the empowering culture (which I believe we all strive to do): Imagine at some point, the integration test suite is added, but this involves regression tests that add 1 hour to the CI. That particular code is receiving the normal review process, and will be blocked, which requires the contributing team to be mindful (either move integration, or come and help work CI to be able to support such cases): - When some regression happens after the code gets merged, open-minded team members can always come and revert the tests, and work together to improve them. - If it gets down to fixing Jenkinsfile, people volunteer to help, just like in other areas. I have personally helped maintain Jenkinsfile for the first few years and would be more than happy to help improve Jenkinsfile for a module that gets supported by the majority of community members. My belief is other members will also do so. - Bottom-line, despite some hiccups, we bring a module that welcomes more community members, while still keeping other modules to support other community members. Remember that problems do arise in the community and we work collectively to address them. We also have tools in our hands and multiple decision points(including reverting) to iteratively improve. If we simply block the gate, we simply will not have those troubles, nor will we empower or even have those community members around who would otherwise not be part of the community. It is great to us collaboratively working together iteratively – which means indeed a few disruptions, but we also welcome more people to work together to bring in improvements. We all pay our credits to the community in one way or another. While not everyone might help in CI, and reverting some of their PR might cause a bit of burden on others, they help reviewing code in other modules, fixing regression tests, writing docs, and bringing in architectures that reduces burdens. In the case of someone proposing a new S0 module and not getting majority support. That would entail that there is at least one -1 from the PMC members. Which also means that it would get rejected at any other possible mechanisms. Not knowing PMC won’t be a problem at all because many of us are eager to review, and empower good proposals from community members. I also do not think relevant subject areas would be a problem since we have some of the best experts in ML compilation. Again you will find how much of an empowerment mindset we have in here. Establishing a module indeed has a lot of factors to consider, there are more negative considerations from the PMC, likely they have already considered the code and community factors. In such cases, I would still expect us to see constructive conversation and reasoning. **OSS development is not a single bundled thing**. - We establish module - We add PR changes - We revert patches that brings regression, CI issue or other cases Each step has **their own contexts**, set of stakeholders. They can come from different people. Some volunteers can take over others. While it is important to set marks through RFC, roadmap, signaling, and strategy. It is also important to be able to facilitate and empower each other through each of those steps. The same thing applies to process RFCs. We bring in the process RFC to address things one step at a time. While clarifying S1, S2 is indeed important, which can be a topic of future discussions. Same would go for improving the stability of TVM overall – which I believe we all are working hard as a community. Sometimes bringing new modules is part of that process. I don’t think S0 has to do with stability btw, it only has things to do with the impact scope of the project – one module can be very stable and remains in S0. On the other hand, we might choose to refactor a S1 module that touches many areas (in that sense S1 might become unstable). They all go through the same process of code changes, documentation, release notes that signal changes. It is natural that some parts of the codebase will be under more active development than others, which also comes with clear documentation, release notes that signal these changes. There will also be roadmaps as part of the RFC that tracks what they propose to do, as well as follow ups RFCs(and different conversations) that track additional changes. All of this information will help to inform our community members – academic and industry alike. One thing to remember though is that being in OSS development means we cannot simply bend to the development needs of a single (industry or academic) player. We are empowering each other in this journey together. That means we need to also accommodate other industry players who need features in newer modules(while not disrupting old ones), academic contributors who contribute novel modules that are then taken over by industry members who help(and are willing) to maintain them. Having a few different modules helps here, where those who favor stability will certainly lean more heavily over longer established ones, while other industry players might benefit from the latest one. We see that happen for example in the PyTorch ecosystem and other ML ecosystems. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1338700949 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1338700...@github.com>
