I'm not sure a CEP is necessarily a big, complex piece of work that needs to be split into multiple tickets. There could be single-ticket CEPs that don't need multiple tickets, and still need the bureaucracy of a CEP due to the impact of the change. However that probably isn't the common case.
Also, there could be complex CEPs with multiple steps that can be incrementally merged to trunk because some of the steps have a value on their own. For example, dynamic data masking (CEP-20) first creates CQL functions for masking data, then it allows to attach those functions to the schema, and then it allows to use UDFs as attached masking functions [1]. Each incremental step has a value on its own. For example, the first step alone is what MySQL dynamic data masking consists on, just a bunch of functions. I think that CEP components that offer value on their own to the users can perfectly be merged to trunk. That's because we could suddenly cut a release including those changes and be happy with having included them. However, if there are partial changes that don't give value to the end user those changes should probably be in a feature branch. And the feature branch could be merged every time it contains a releasable piece of work. If the changes on that feature turn out to be massive, it could be a good idea to create a separate ticket just for the merge, so reviewers can jump at it and give a final pass with a global perspective. [1] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking#CEP20:DynamicDataMasking-Timeline On Fri, 3 Feb 2023 at 12:48, Sam Tunnicliffe <s...@beobal.com> wrote: > This is quite timely as we're just gearing up to begin pushing the work > we've been doing on CEP-21 into the public domain. > > This CEP is a slightly different from others that have gone before in that > it touches almost every area of the system. This presents a few > implementation challenges, most obviously around feature flagging and > incremental merging. When we began prototyping and working on the design > presented in CEP-21 it quickly became apparent that doing things > incrementally would push an already large changeset into gargantuan > proportions. Keeping changes isolated and abstracted would itself have > required a vast amount of refactoring and rework of existing code and > tests. > > I'll go into more detail in a CEP-21 specific mail shortly, but the plan > we were hoping to follow was to work in a long lived topic branch, with > JIRAs, sensible commit history and CI, and defer merging to trunk until the > work as a whole is useable and meets all the existing bars for quality, > review and the like. > > > On 3 Feb 2023, at 12:43, Josh McKenzie <jmcken...@apache.org> wrote: > > Anything we either a) have to do (JDK support) or b) have all agreed up > front we think we should do (CEP). I.e. things with a lower risk of being > left dead in the codebase partially implemented. > > I don't think it's a coincidence we've set up other processes to help > de-risk and streamline the consensus building portion of this work given > our history with it. We haven't taken steps to optimize the tactical > execution of it yet. > > On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote: > > On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie <jmcken...@apache.org> wrote: > > > > My current thinking: I'd like to propose we all agree to move to merge > work into trunk incrementally if it's either: > > 1) New JDK support > > 2) An approved CEP > > So basically everything? I'm not sure what large complex bodies of > work would be left. > > >
