I can offer my anecdata: I know of two major enterprises as well as have had two interviewees unsolicited bring up to me that they have walked away from or bounced off the project due to the feature freeze / branching strategy. I may be the anomaly given the volume of people in the ecosystem I interact with, but I assume it's more than just the ones I've seen.
Mick, correct me if I'm wrong but the merge path for a bugfix to 2.1 that applies up to 4.0, as an example, would look like: 2.1 → 3.0 → 3.11 → trunk With no extra work required and an accumulation of a backlog of things on trunk not on the cassandra-5.0 branch. If someone else were working on something in the cassandra-5.0 branch, they'd need to rebase/rerere the 5.0 branch on trunk before making whatever changes. In effect this would move the burden from merge resolution to whomever was choosing to work on the cassandra-5.0 branch instead of maintainers working on 4.0. > Is there such a backlog of tickets that have been reviewed and not going into 4.0.0? Chicken or egg debate right? Nobody is going to review code for post 4.0 right now if there's nowhere to put it since it'll just atrophy and need constant rebasing and thus re-review. Or it ends up in a fork somewhere. As I understand Sankalp's primary (and quite reasonable) argument the last time we discussed this, the concern was the extra work needed to merge forward for people working on 4.0. A cassandra-5.0 branch in-tree where the burden of maintenance would fall on people using the branch seems to mitigate that concern. Also, when 4.0 GA'ed wouldn't we just trunk become a 4.0 branch and then cassandra-5.0 become trunk? On Thu, Sep 10, 2020 at 4:32 PM, Benedict Elliott Smith <bened...@apache.org > wrote: > We know we are turning away more and more contributions > > Do we? I haven't been aware of much of this occurring at all. > > On 10/09/2020, 20:58, "Mick Semb Wever" <m...@apache.org> wrote: > > We know we are turning away more and more contributions and new potential > dev community with our 4.0 feature freeze, and it has been going on for a > while now. > > I would like to suggest we create a cassandra-5.0 branch where we can > start to queue up all reviewed and ready-to-go post-4.0 commits. > > This is not to distract from getting 4.0 out, where our primary focus is, > but as a stop-gap in losing those contributions. The effort of the > cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those > that wish to take it on, and the branch can be located in whatever GH fork > those > individuals wish to keep it in. 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 while their tickets remain in "Ready to Commit" > status. The goal of this effort would be, a) we are giving the signal to > contributors to get involved again (even while our primary focus in on > stabilisation and testing efforts), and b) maintaining CI status on the > sequence of commits that are ready to go into trunk post 4.0-rc. > > My questions are… > - who would be willing to help maintain this cassandra-5.0 branch? > - should it be kept external in a GH fork? Or would you rather have the > branch in our main git repository? > > regards, > Mick > > --------------------------------------------------------------------- To > unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional > commands, e-mail: dev-h...@cassandra.apache.org >
