Hi, further to my previous mail I've just pushed a new branch, cep-21-tcm, to the ASF repo. This represents the majority of the work to date on CEP-21 and is based on recent trunk (7ad746cc83). As you can see from Circle[1], there are a number of test failures at the moment, many of which are down to differences in test setup and we're working on getting this to parity with trunk. We were able to get the git history reorganisation done while doing a rebase, so there isn't any point in publishing the original dev branch as I originally proposed.
I've also created a Jira epic (CASSANDRA-18330) as an umberella for CEP-21 and over the coming days we'll start to file seperate tickets for the upcoming/remaining work. [1] https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249 > On 13 Feb 2023, at 17:18, Sam Tunnicliffe <s...@beobal.com> wrote: > > 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
