For significant new feature work, the option of working in a public, > long-running, trunk-based feature branch is available. If we look at a > specific example like CEP-7/SAI, I’m not sure how it would benefit much > from a 5.0 branch, at least until it fundamentally depended on other > 5.0-targeted work. >
Caleb, I'm seeing an important value to the branch (given there's no inter-dependencies between patches) is the CI builds on the cassandra-5.0 branch, and the efforts of rebasing centralised from many feature branches to one preview branch. Raising the CEP process is interesting. Anything significant enough to warrant a CEP still has to go through that process (which has limited throughput atm) and I can't imagine anything that size making it to the cassandra-5.0 before we got to 4.0-rc (which is hopefully in a few months). But we are sending the clear signal that we are no longer shutting out these contributions. Maybe the effort should be done in the area of getting more people on > board technically so they can start to review things themselves (which > indeed takes a lot of time and patience) instead of creating a new > branch so they can pile up their stuff there. Stefan, the cassandra-5.0 is not a substitute for reviews. Good habits in preparation for reviews: like rebasing your feature branch, having CI results ready to view; and the review process itself remains exactly the same, and will take the same time as before. You do have strong review preparation habits in place. I can see that the CI builds (not just a selection of tests but the whole complete pipeline) being part of the value you are taking advantage of here. We want to re-apply that value also to the cassandra-5.0 branch with its patches that are post-review yet, not yet merged to trunk. That CI would help smoke out the combination (sequence) of reviewed patches all put together, and easing the burden of the re-review of those patches, before they land in trunk. Again… if the feature freeze is now a quickly shortening window, it's going to be very limited to what might make it into such a branch, so mostly about sending the signal that this final hurdle can be worked around if it means we retain any such significant new contributions. Work conducted without the engagement of the community can also expect to > be heavily revised when the community finally engages with it, as signalled > with the CEP process. Benedict, good point and it loops into what Caleb touches on. The CEP intends to bring out community involvement earlier in the development cycle, to avoid the late revisions. And under the feature freeze the CEP process is an obvious bottleneck and I don't think we can get around that. As far as dev involvement goes, it doesn't stop just because something is merged to trunk, commits in trunk can also be re-reviewed and then reverted, but that's something we want to avoid. So yes, ofc there will be those that want to have their say on things sitting in the 5.0 branch that have otherwise met reviewer requirements, at the same time (as long as the branch remains limited in its scope) this does lengthen out the dev cycle for these contributions providing more patience and soak time for all. I would expect that the maintainers of the branch extend the opportunity for late reviewing to those that were doing The Right Thing focusing all their time on getting 4.0 out, before those commits go into trunk. Opposed to this, if we do these contributions in secret to avoid these types of discussions, only raising them once the feature-freeze is lifted, there may be a flood-gates rush and it will be even harder for folk to put in late reviews. I would certainly rather see exceptions made and things done in public (even if in a fork), though the main concern we are hearing is folk simply walking away altogether. I agree with the social responsibility perspective as well, but it's not something we can enforce. If folk want to do this we can't stop them and we should listen to why they believe it is a valuable exception. I do believe the discussion and hearing out people's frustrations: how overloaded and focused on 4.0 they are, and the concerns of how this risks delaying 4.0; should happen and is of immense value.
