> But I would suggest that we are more productive when
> raising and discussing concrete examples and specific patches
You make a good point. Can you provide some concrete examples of your own?
Ironically, this entire proposal so far rests on hypothetical lost
contributions by hypothetical companies and individuals.
I would also like to take issue with a talking point running through much of
this discussion, that those who are focused on quality assurance have
"different priorities" to those who now want to ship features into 5.0: we also
want to ship features, we're just doing the work the project agreed upon as a
prerequisite to that.
On 15/09/2020, 22:00, "Mick Semb Wever" 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.
>
I am going to take a stab at closing the loop on this thread.
So far no one has indicated any desire to maintain a cassandra-5.0 branch.
While people have expressed concerns about what it would mean for the
release date and quality of 4.0-rc. As a community we don't have an answer
to these concerns. But I would suggest that we are more productive when
raising and discussing concrete examples and specific patches where-ever we
see a potential impact, like we have done with the messaging system
rewrite, those bugs that slipped 4.0-alpha, and the byte array backed cells
rewrite.
Since a number of people have asked off-list for more detail and
clarification on how the cassandra-5.0 branch would work in a way that
doesn't require community voting/approval, and incase anyone does step up
to take it on, the following is a more detailed writeup to the workflow i
was thinking…
1. Patches are reviewed by two Committers on tickets that are marked `4.x`.
a. These patches are not relevant for any current versions (2.2, 3.0,
3.11, 4.0)
b. If these patches require a CEP, then they must have first passed the
CEP.
c. These are patches from new contributors that we would otherwise lose.
d. Reviewers are not retreating from 4.0-rc efforts.
2. When successfully reviewed, the single commit that makes the patch is
committed to the cassandra-5.0 branch.
3. The ticket is transitioned to "Ready to Commit", and a comment added
that the patch now resides in the cassandra-5.0 branch.
4. At regular intervals, the cassandra-5.0 maintainers rebase (and rerere)
the branch off trunk.
a. ci-cassandra.a.o runs CI on the cassandra-5.0
5. When 4.0 is branched and the feature freeze is announced over, an email
to the dev ML is sent that the patches parked in the cassandra-5.0 will
soon be committed.
a. There needs to be a balance here between appreciating late-reviewers
who were busy Doing The Right Thing being given a chance to provide
feedback, and that two trusted committers have already signed off on the
patch.
6. The cassandra-5.0 branch is fast-forward merged into trunk (minus any
commits that have had reviews re-opened on them).
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
