Thank you for your input. Different members of the community have different interests, and there are common shared goals. One thing to be mindful of is that there are different ways, and some may work for certain modules, circumstances, and the current community demands.
In the end, it is also about the real practical executions of the community. Let me first expand on some of the points here.
Responsibility of maintenance
The reality is that the responsibility of mostly maintenance falls onto the members who contributed and developed the modules and related features. Such merit is developed through contributions. So naturally, most communities lean towards empowering the decisions of these members as long as the contribution is scoped in modules.
As a community with diverse needs, nobody is required to be aware of all modules to contribute. In practice we also pay attention to the modules we normally engage with. Based on our past year’s contribution activities, members who designed and maintained the core modules, such as arithmetic, relay IR design, TensorIR, AutoTVM, and some of the graph IR nodes, are responsible for and still actively maintain these modules in main.
Maintainers of core modules in the main branch are also now maintaining unity. But they all took the extra mile to bring things of existing modules to main to fulfill their responsibility, even if that incurs a good amount of overhead in the past year.
It is the same group of people who would continue to ensure that the features in the main continue to work as no changes go through them, through the module isolation and changes. We would lean more towards them for thinking about ways of incorporation.
Preserving main modules As stated above, the development practices as of now bring all the changes in the existing modules to main. Changes to these modules are covered by tests in the main. Other tests are turned off in unity due to cost, as many modules are not structured through a UT approach, which brought undesirably long time, and changes to unity are not related to these modules. We will of course, work together to ensure that the relevant modules don’t break and work to fix them when that happens. These are concrete conversations that we can have to enable the community.
Bring community awareness
Some of the suggestions boils down to the common goal of community awareness. There are many ways to achieve the goal, and the community is doing that in the past year, and continue to do so in the incoming months:
Sending modules in chunks to the main would have been a great evolution approach one year ago. The community worked to do some of the approaches when the unity branch was established. At the current state, however, the approach likely will be much less practical or desirable due to the energy and complexity involved to also maintain the goal of bring timely foundational model support.
In practice, we need pragmatic ways to enable the goal of bringing foundational model support timely. Ideally such support should have landed months ago, and timing matters, especially given the current ML/AI space. There is a great risk of lost momentum and relevance. We would already run into that risk in practice if we didn’t empower unity development.
This being said, we would love to see the community spend energy on more awareness. Please ask questions about the modules and bring suggestions and discussions, as we repeatedly mentioned in the past one year. We would love to work together to solve concrete questions like “here is how we bring BYOC” and these energies are worth spending. There are likely months we can continue to do so, and likely more to come.
Action matters and speaks louder
Many discussions we have are about how to approach our goals. Where naturally the community can have different opinions. Regardless of the conversation of how. We need concrete action and executions to land – which in term needs support from community members doing these ground works.
Having a seemingly perfect approach won’t necessarily get us LLM support, or even get the community to collectively work toward that. We need real groundwork to make things happen, and empower the community to make these ground works.
Actions and results speak louder, and that is what users turn to the community for. We would need to avoid running the risk of being over-bureaucratic, as we do not exactly command that the community should take exactly one approach.
The reality is simple: insisting one seemingly perfect engineering approach won’t give us solutions for LLM. Nor will they resolve real technical challenges at the core, while the right architecture(and empowering members that does ground work to bring them) is the real key.
Following one specific approach is not a necessary nor sufficient condition to get a “good or right project”. Approaches can only facilitate and empower the community towards the goal.
In the end, it is the community who comes and builds code, does the groundwork, maintains the existing modules, and brings real LLM support. These are real works that every member sees taken into consideration when we make the collective decision on ways to move forward. We all have to do real groundwork to earn merits and, as a natural consequence, alignment from community members, which in turn is reflected in community strategy and collective choices that naturally empower these ground work.
It is good that we brought up these possible alternatives for the community to consider. Let us also work on ground works to help show the viability of the path. e.g. here is one approach, and here are some examples on enabling LLM or other needs through this approach.
These extra information can help community decide the path forward taking them into consideration.
