The deeply coupled nature of some areas of our codebase does have some constraints it imposes on us here to your point. Without sensible internal APIs a lot of this type of work expands into two phases, one to refactor out said APIs and the other to introduce new functionality.
It probably depends on what systems we’re extending or replacing and how tightly coupled the original design is as to which approach is feasible given resourcing. On Fri, Feb 3, 2023, at 7:48 AM, Sam Tunnicliffe 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.
