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 >> <mailto: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.
