Replies inline, though I think Josh answered everything well enough already.
> The effort of the cassandra-5.0 branch maintenance: rebasing (git rerere); > > is just upon those that wish to take it on > > > I don't follow. If a bug fix goes into 4.0 do we not need to sync this > with 5.0, if so then this would be the 5th branch to keep in-sync, and if > the feature freeze is lifted then this branch may diverge making it harder > to apply the patch to. > We are talking about things that would only go into a 5.0 branch. As soon as the feature freeze is lifted, then all the commits in the 5.0 branch are rolled onto trunk (i.e. a fast-forward merge). The branch is regularly rebased off trunk. That work is on those willing to take on the endeavour, not the community. Tickets that have been reviewed and are (aside from the feature-freeze) > > ready to be committed, can be committed to the `cassandra-5.0` branch > > > Is there such a backlog of tickets that have been reviewed and not going > into 4.0.0? What I see are ideas and things punted from review, so it > would be good to see what this backlog is and how large. > You're correct, we are talking about a backlog of tickets that has not materialised. We have enough signals to know why they are not materialising. We can't say what will materialise, hopefully folk will come back. That's why we can't ask for "the backlog" in advance. My main fear is reviews of new tickets. A complaint I have heard multiple > times from several people is that not enough people are reviewing and > reviews take a long time (number of reviewers is small and their backlog > keeps growing). Absolutely agree with you David. Lack of reviewers, and focusing reviewers on 4.0, is crucial. I'm pretty sure everyone agrees. But new contributions is community health and growth, and there's genuine concerns we're losing them. And we *are* seeing it. > To me GH fork is the same as not committed and not reviewed. If a fork > would help the community then I am ok with it, but I don't see it as ready > to commit. > The feature freeze is about what can and can't go into trunk (and us not branching yet cassandra-4.0). There's no restrictions around reviewing tickets and transitioning or commenting them as "ready to commit" on the presumption the reviewer is one of those bearing the burden of the cassandra-5.0 branch maintenance and ensuring the fast-forward merge of it to a post-4.0 trunk is of the same standard expected of every commit pushed. If the community wanted to extend the feature freeze to blocking jira transitions to "ready to commit" for post-4.0 work, those reviewers could just do that book-keeping themselves. No community vote or consensus is required for those willing to do this, because it can be done externally. So I'm thinking going into such process formalities distracts us from having the real conversation… who's willing to do it? and if you are, do you believe you can do so without taking any (review) time away from 4.0 efforts? and is it clearly understood that your additional effort is restricted to contributions from new significant contributors that we feel we would otherwise lose? I know folk will have strong opinions on this, that's no surprise, it's meant as a discussion opener.
