Hi Ekaterina - Thanks for the suggestions.
On 10/27/2025 11:31 AM, Ekaterina Dimitrova wrote:
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.
Thinking about it, this kind of overlaps with the ongoing discussion
about forks, backports, etc., and the desire to keep trunk releasable at
any moment. Ideally it would be possible to slip in a large change via a
bunch of little commits that are always releasable, but the bigger the
change the riskier that sounds. (Each little commit carries non-zero
risk of introducing something bad in trunk; a bunch of little commits
probably makes the risk add up.) I'll consider a feature branch, unless
there's strong opinions against.
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,
Yes it does: thanks -- Joel.
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.
