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
> 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
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
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
I agree with Jason Brown: good topic to address, effect not trivial. Going
whole hog too risky. Careful meticulous small areas at a time with warning to
everyone so they can chime in if they are working on that area and would prefer
it left alone for now.
I wouldn't want it to delay others
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 thi
Cassandra devs,
We use workflows in some of our clusters (running 3.0.15) that involve
"SELECT DISTINCT key FROM..."-style queries. For some tables, we
observed extremely poor performance under light load (i.e., a small
number of rows per second and frequent timeouts), which we eventually
traced
Syvlain explained the problem in CASSANDRA-4536:
" Let me note that in CQL3 a row that have no live column don't exist, so
we can't really implement this with a range slice having an empty columns
list. Instead we should do a range slice with a full-row slice predicate
with a count of 1, to make su
Is OpenJDK really not addressing this at all? Is that because OpenJDK is
beholden to Oracle somehow? This is a major disservice to Apache and the
java ecosystem as a whole.
When java was fully open sourced, it was supposed to free the ecosystem to
a large degree from Oracle. Why is OpenJDK being s
See the legal-discuss@ thread:
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201803.mbox/browser
.
TL;DR jlink-based distributions are not gonna fly due to OpenJDK's license,
so let's focus on other paths forward.
On Thu, Mar 22, 2018 at 2:04 PM, Carl Mueller
wrote:
> Is OpenJDK
You should check the 3.x release. CASSANDRA-10657 could have fixed your
problem.
On Thu, Mar 22, 2018 at 9:15 PM, Benjamin Lerer wrote:
> Syvlain explained the problem in CASSANDRA-4536:
> " Let me note that in CQL3 a row that have no live column don't exist, so
> we can't really implement this
As I mentioned in IRC and was pasted earlier in the thread, I believe
the easiest path is to follow the major releases of OpenJDK in the
long-term-support Linux OS releases. Currently, Debian Stable (Stretch),
Ubuntu 16.04 (Bionic (near release)), and Red Hat / CentOS 7 all have
OpenJDK 8 as the de
On 03/22/2018 05:30 PM, Michael Shuler wrote:
> Ubuntu 16.04 (Bionic (near release))
Ubuntu 18.04 (Bionic) :)
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cass
On Thu, 22 Mar 2018 16:04:16 -0500, you wrote:
>Is OpenJDK really not addressing this at all? Is that because OpenJDK is
>beholden to Oracle somehow?
I suspect it is more a case of OpenJDK (as in the entitites other than
Oracle that are members) haven't historically been involved in the
providing
I think Michael is right. It would be impossible to make everyone follow
such a fast release scheme, and supporting it will be pressured onto the
various distributions, M$ and Apple.
On the other hand https://adoptopenjdk.net has already done a lot of the
work and it's already rumoured they may tak
15 matches
Mail list logo
