Hi,

In the recent DISCUSS thread on merging incremental feature work[1] I mentioned 
that we've been preparing a code contribution to support CEP-21[2]. Today we 
have a branch based off trunk which supports a significant subset of the 
functionality described in the CEP. Whilst being mindful of the recent 
discussions on merging large features incrementally, we have been working on 
the assumption that this would land in trunk in a complete and usable form. 

To that end, we're proposing work is carried out in a long-lived feature branch 
and only merged to trunk when all the usual bars for quality are met, including 
a regular CI pipeline on that feature branch. The idea is to push the partially 
implemented version to a public repo now as it is, giving the community a way 
to get a better idea of the approach, to provide initial feedback and even to 
begin checking out the integration points. In parallel, we will create the 
feature branch and begin moving portions of the implementation across to it so 
that it can be more easily reviewed. This way of re-organising the git history 
into semantically meaningful commits feels way more achievable than a giant 
rebase.

Are there any concerns about this approach?

[1] https://lists.apache.org/thread/c39yrbdszgz9s34vr17wpjdhv6h2oo61
[2] 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata

Reply via email to