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
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
: 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, and have 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
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
> 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
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
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
+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
+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
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
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
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
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
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
+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
16 matches
Mail list logo