I think we all agree that bringing the features development in unity is desirable for the many reason listed and stressed over and over in the posts above.
The strategy to bring the changes and incorporate unity changes, seems less optimal and less inclusive, given nobody in the community is expected to keep in sync with changes introduced in unity, as development branch.
Just taking the path that is most convenient for a subset of the community (like moving unity to be the new main, or nominating unity as the main branch) would force unknown and potentially breaking changes into the codebase, while leaving developers and end-users to their own devices, to figure out what works and what doesn’t. I don’t think it is an onus of the development community to keep track of all development branches.
I would like to suggest that together with T0, T1 and T2, that we consider a T3 and take “unity” as a regular contribution and merge it into main in organised chunks of features that would make more sense in the git history.
T3: Extract major features from
unityand raise feature-level PRs againstmain. Fast-track them onto main once documentation and testing are in place, and currentmainCI passes.
This is also an opportunity for us as a community to understand the changes coming in, organise commit messages, describe features in an inclusive way, making sure documentation exists, etc.
A positive side seems that many of these changes are local to specific namespaces, and having them integrated in patches shouldn’t be a lot of work. From an engineering point of view, it looks more in line with the common practice in upstream project and much more inclusive as well, when compared to taking just a blob of ~200k+ lines into the project.
More importantly, I don’t think it is right to impose such a bulk change in the project this way. At the same time, I understand the time pressures some might feel, but those should be put in perspective of keeping the project coherent and visible to the wider community (not only unity branch maintainers).
The main reasons for T3 (a.k.a. orderly moving unity features to main) are:
1.Diff delta / opportunity for code review
Before becoming unity branch in TVM repo, there were hundreds of changes in which the broad community had no chance to review (the main cause being it was host somewhere else for a long time).
According to a rough comparison done on GitHub, the diff between unity and main today (including submodules) is something along the lines of “888 changed files with 211,567 additions and 8,684 deletions”.
2.Bundled features
In tandem with “unity” as a branch, there are quite a few features being brought in such as ”MSC Graph”, “Disco”, etc. which are largely unknown to the wider community, so in moving them orderly into main, is an opportunity to advertise those better to the community.
Remember all these features/tests become responsibility of all to maintain once they are integrated with the code.
3.Test coverage of the branch
Many tests and CI validation parts are currently disabled in the unity branch, which will require current contributors to rework features and also for them to figure out if their support works at all in the new landscape, which seems hostile to current contributors that have visibility of ”main”.
In moving changes orderly from unity to main, it has the advantage of at least guaranteeing minimum compatibility with current test base, so that we can keep the “revolution with impact minimization in mind” commitment stated above.
The cost of the change will always be somewhere, I’m just advocating that we don’t simply pull the plug on features people are currently relying on in main for lack of testing, and replace it with a less tested/reviewed version of it.