I second David. I think I can speak up here as I perfectly fit into the bucket of "new people trying to contribute".
While it is true that reviews tend to take a long time I am perfectly happy with people who eventually look at them. It is understandable that there is a lot of going on and a committer / more experienced people do not have time to give a feedback immediately but as long as it is not forgotten completely (which has never happened to me), to me personally it does not matter too much how "fast" something is reviewed and merged even though I would be delighted if my changes are reviewed and merged faster (who would not not be, right?) I do not think that making yet another branch would make any significant difference, it can always be done against trunk and it would be harder to merge back as there might be a lot of conflicts etc ... Anyway, I am trying to go over tickets which are fixing and improving upcoming 4.0 and they are retrofitted into older branches if applicable. It is a very nice compromise. It gives signals to folks like "sure, we look into it, but if it fixes things in 4.0, it will be looked at even faster", so it motivates people to primarily focus on 4.0 which directly benefits the project to release 4.0 sooner. There is also an argument in this thread that having cassandra-5.0 would leave the burden of rebasing / fixing conflicts to respective contributors, quoting: "A cassandra-5.0 branch in-tree where the burden of maintenance would fall on people using the branch seems to mitigate that concern.". To be honest, I find myself preparing the branch for committers / reviewers perfectly fine and it is the minimum I can do so they do not have to - it is just a basic courtesy to prepare my work in such a way that it is reviewed comfortably and it can go straight in. I am even semi regularly ensuring that my open branches are on-par with the trunk every other day so once a comitter takes a look, everything is in place. I do not know if I am an exception but this is just natural process to me. 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. On Thu, 10 Sep 2020 at 22:25, David Capwell <dcapw...@gmail.com> wrote: > > > > > 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. > > 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. > > 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). If we open up reviews for non 4.0.0 work then my fear is > that even less review time will be allocated to 4.0.0 work. > > - who would be willing to help maintain this cassandra-5.0 branch? > > > I do not have the time so I will not be able to help with 5.0 work. > > - should it be kept external in a GH fork? Or would you rather have the > > branch in our main git repository? > > > 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. > > On Thu, Sep 10, 2020 at 12:58 PM 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
