Yes, I think that some refactors can also be directly merged if they have a value for the end user on their own. Changes providing cleaner, better documented and less tightly coupled code can have that value, even if they aren't a new feature. Things like new APIs without an implementation probably don't have that value.
I guess the criteria could be that partial CEP changes can be merged if they would still make sense if there were a release the next day. Or, even better, as if the next steps on the CEP were to never be completed. On Fri, 3 Feb 2023 at 13:13, Josh McKenzie <jmcken...@apache.org> wrote: > 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. > > >
