As requested, I'm alerting the ML that I've got the first patch of several
to come. This one only addresses the ColumnFamilyStore class - and only
changes the name. There's follow up tickets to change method and variable
names. As we agreed, I'm doing this incrementally, so please let's keep
tha
Perfect!
-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Thursday, March 22, 2018 8:10 AM
To: dev@cassandra.apache.org
Subject: Re: Paying off tech debt and correctly naming things
Cool. I think there’s general agreement that doing
From: Jason Brown [mailto:jasedbr...@gmail.com]
Sent: Thursday, March 22, 2018 7:14 AM
To: dev@cassandra.apache.org
Subject: Re: Paying off tech debt and correctly naming things
Jon,
Thanks for bringing up this topic. I'll admit that I've been around this code
base for long enough,
Cool. I think there’s general agreement that doing this in as small bites as
possible is going to be the best approach. I have no interest in mega patches.
> The combined approach takes a
> change that's already non-trivially dealing with complex subsystem
> changes and injects a bunch of t
Jon,
Thanks for bringing up this topic. I'll admit that I've been around this
code base for long enough, and have enough accumulated history, that I
probably can't fully appreciate the impact for a newcomer wrt naming.
However, as Josh points out, this situation probably happens to "every
non-triv
> Some of us have big patches in flight, things that actually
> pay off some technical debt, and dealing with such renames is rebase hell :\
For sure, but with a code-base this old / organically grown, I expect
this will always be the case. If we're talking something as simple as
an intellij rename
Poor and out-of-date naming of things is probably the least serious part of our
technical debt. Bad factoring, and straight-up
poorly written components is where it’s really at.
Doing a big rename for rename sake alone does more harm than it is good,
sometimes. Some of us have big patches
in fli
Having been through a bunch of refactors in other projects, I would suggest
doing small incremental patches isolated in related parts of the code. It would
also be nice if you could give us a heads up on changes you're making.
Best of luck!
Dinesh
On Tuesday, March 20, 2018, 3:04:43 PM PDT,
+1 - can help with sections of the code
--
Rahul Singh
rahul.si...@anant.us
Anant Corporation
On Mar 21, 2018, 4:25 PM -0500, Lerh Chuan Low , wrote:
> For reasons others have mentioned (nightmare to continuously update branch
> and resolve merge conflicts, existing patches/big features..) it wi
Please please please ping the list and ask if anyone has big commits ready to
merge before actually committing any huge automated refactors - people who may
be sitting on big patches will thank you if they don’t have to rebase against
huge IntelliJ refactors .
--
Jeff Jirsa
> On Mar 21, 201
+1 if you are willing to take it on. As the person who performed the
Table->Keyspace rename of 2.0, I say good luck! From hindsight of doing that,
as others suggested, I would come at this in multiple tickets.
I would suggest a simple class rename with intellij refactoring tools or
something a
For reasons others have mentioned (nightmare to continuously update branch
and resolve merge conflicts, existing patches/big features..) it will be a
nightmare. It seems like in software projects (just basing it off personal
experience) people typically refactor if a ticket they are working on
touc
On Wed, Mar 21, 2018 at 3:48 AM, Sylvain Lebresne wrote:
[ ... ]
> - pure code renaming is one reasonably simple aspect, but quite a few
> renaming may have user visible impact. Particularly around JMX where many
> things are name based on their class, and to a lesser extend some of our
> tools
I really don't think anyone has been recently against such renaming, and in
fact, a _lot_ of renaming *has* already happen over time. The problem, as
you carefully noted, is that it's such a big task that there is still a lot
to do. Anyway, I've yet to see a patch renaming things to match the CQL
n
I agree that the refactoring make sense but I also know the pain of merging
branches with smaller refactorings. When you have to make a patch for
several branches and that you have to go through several round of reviews
it can be pretty painful.
I know that pain too well so I am not in favor of the
As someone who came to the codebase post CQL but prior to thrift being
removed, +1 to refactor. The current mixing of terminology is a complete
nightmare. This would also give a good opportunity document a lot of code
that simply isn't documented (or incorrect). I'd say it's worth doing it in
multi
+10
There are 2 hard problems in CS: naming things and cache invalidation
Le 20 mars 2018 23:04, "Jon Haddad" a écrit :
> Whenever I hop around in the codebase, one thing that always manages to
> slow me down is needing to understand the context of the variable names
> that I’m looking at. We’
17 matches
Mail list logo
