Hi Joel, I think this is very reasonable question. I would say - it depends.
Incremental small changes are always welcome - easier and quicker to review and less prone to miss something. If they are self contained and we can release anytime with them committed, even if the CEP is not finished yet - then they can be committed to trunk, once reviewed etc. Otherwise, we can use feature branch as we did with TCM and Accord, for example. This helps to split the work in manageable PR sizes and also more people can collaborate on the CEP, working on the feature. “E.g., with the PR mentioned above, it might not be obvious from the changes in the PR what the larger intent is, so it could look like low-value code reshuffling, rather than a building block.” The commit will mention a ticket number part of CEP epic (I assume you will have one to cover the different parts you will commit separately), to make it clear what its goal is. Hope this makes sense, Best regards, Ekaterina On Mon, 27 Oct 2025 at 14:23, Joel Shepherd <[email protected]> wrote: > Hi C* devs - Small request and a slightly larger question ... > > I have a small PR out as a first step towards (CEP-50: Auth negotiation) > - Refactoring out most assumptions of a single authenticator outside of > Config and DatabaseDescriptor: > https://github.com/apache/cassandra/pull/4427 ... gentle ping if anyone > wants to take a look. > > Larger question - I'm used to a workflow where devs submit a number of > small CRs/PRs building up a larger piece of work, instead of posting one > or two big reviews at the end. I want to verify what this community > prefers. One advantage I can see to fewer, bigger PRs is that there is > more context to evaluate the overall approach with. E.g., with the PR > mentioned above, it might not be obvious from the changes in the PR what > the larger intent is, so it could look like low-value code reshuffling, > rather than a building block. > > So, what working style would be better for you? > > Thanks -- Joel. > > >
