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
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
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo
