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’
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’ve now removed thrift the transport, but the variables, classes
and comments still remain. Personally, I’d like to go in and p
18 matches
Mail list logo
