It seems like there are many people in this thread that would rather we not 
make a “grouping” CEP for these ideas, but rather consider each one 
individually.  I will close out this CEP thread then, and discussions can 
continue on individual tickets.

I think we got some nice discussion on this thread on what people would like to 
see from these type of refactoring tickets, so that will be good information to 
take forward as we work on individual tickets.

Thanks for the discussion everyone.

-Jeremiah Jordan

> On Oct 27, 2021, at 1:28 AM, Dinesh Joshi <djo...@apache.org> wrote:
> 
>> On Oct 25, 2021, at 1:22 PM, Jeremiah D Jordan <jerem...@datastax.com> wrote:
>> 
>> The currently proposed changes in CEP-18 should all include improved test 
>> coverage of the modules in question.  We have been developing them all with 
>> a requirement that all changes have at least %80 code coverage from sonar 
>> cloud jacoco reports.  We have also found and fixed some bugs in the 
>> existing code during this development work.
> 
> This is great! We, as a project, should encourage improved test code 
> coverage. So I welcome this change.
> 
>> So do people feel we should re-propose these as multiple CEP’s or just 
>> tickets?  Or do people prefer to have a discussion/vote on the idea of 
>> improving the modularity of the code base in general?
> 
> My personal preference would be to see this work appear as individual CEPs or 
> even JIRA tickets with discussions but definitely not one giant CEP that is 
> pulling together a lot of different changes.
> 
> I really like the idea of building pluggable modular components. However, I 
> am concerned about few things.
> 
> 1. Performance regression.
> 2. Breaking backward compatibility for our users & tools.
> 3. Interfaces with single implementation.
> 
> I would like to ensure that we are mindful of these concerns while making big 
> refactors.
> 
> Thanks,
> 
> Dinesh


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Reply via email to