On Fri, 13 Dec 2024 at 06:06, Jeremiah Jordan
wrote:
> TL;DR - in progress migration off 2.2 to 5.0 is annoying as there were
>>> different bugs in the past we have to support again. Out of process
>>> migration to me feels far more plausible, but feels annoying without
>>> splitting off our rea
>
> TL;DR - in progress migration off 2.2 to 5.0 is annoying as there were
>> different bugs in the past we have to support again. Out of process
>> migration to me feels far more plausible, but feels annoying without
>> splitting off our reader/writer… doable… just more annoying…
>
>
This is your
I think it does not make a lot of sense to get away from Ant unless we
split it into more jars. Splitting it into more jars while moving away from
Ant at the same time is just too much work. So, what is the point of having
monolithic cassandra-all in Gradle / Maven? Smoother release? We mastered
th
> but I still find myself very rarely interacting with ant
I think that is where most people are as not many actually maintain or modify
ant… there are so many things that bug me (lack of cache, making sure new
people use the right version (was totally fun to learn 4.1 didn’t build with
the def
btw if you think about that ... if we ever felt some strong urge to move
from Ant we could not overcome and we had code split to more modules /
subprojects already, then moving such an already-splitted project from Ant
to whatever else would be just an exercise. It would be like "OK we split
Cassan
We already have an established "alpha," IMO, and it's called branch
and trunk. For example, the CEP-15 branch is the alpha for Accord and
TCM, and then it will be merged into trunk. The next stop is beta and
on to the regular release train.
I'm just optimizing to keep it simple and clean for end u
> My expectation is that in trunk SCM CASSANDRA_4 would change to SCM
> CASSANDRA_5.
Assuming you upgrade from 4.0 to 5.0, then you are running on CASSANDRA_4… how
many people know that they are expected to do something about that (Sam
documented the steps earlier)? What if you leave things al
> I have for a while advocated for a shared lib to also share between Harry,
> accord, dtests etc
Big +1 for a shared lib for our concurrency and test utils. Been intending to
start working on this for a while now, but never got to do this so far.
On Thu, Dec 12, 2024, at 5:58 PM, Benedict wrot
> I think that will not happen until we are out of Ant as doing this multi jar
> / subproject mumbo jumbo is not too much appealing to ... anybody?
I find it more or less equally painful to make a change in a large Gradle,
Maven, or Ant project. I consider myself a pretty active contributor, bu
Why would ant get in the way? We already build multiple jars, and accord will be a submodule. We have far more organisational issues to overcome than ant.I have for a while advocated for a shared lib to also share between Harry, accord, dtests etcI am however not 100% sure about splitting read/writ
> will not happen until we are out of Ant as doing this multi jar / subproject
> mumbo jumbo is not too much appealing to ... anybody?
There's some folks working on a CEP around our build system and supporting a
shared library (came up in a thread on #cassandra-dev; that's the extent of my
knowl
> I think that will not happen until we are out of Ant as doing this multi
jar / subproject mumbo jumbo is not too much appealing to ... anybody?
This is a contentious/controversial topic, but the more I work with gradle
the more I lean towards ant's simplicity. That said, I'd support moving
away
No, we initially tried to preserve all the previous paths and put the whole
thing behind a feature flag, but it was just way too pervasive and doing so
would've added years to the project. So for the period before the CMS is
initialized, certain operations are not available.
However, it should
These are all good ideas but in practical terms I think that will not happen
until we are out of Ant as doing this multi jar / subproject mumbo jumbo is not
too much appealing to ... anybody?
From: Paulo Motta
Sent: Thursday, December 12, 2024 17:35
To:
> +1 on moving the read/write logic into its own jar.
+1, not only read-write logic but anything used by both the server and
subprojects (ie. cassandra-sidecar), for example JMX Mbeans and other
interfaces.
I think one way to do that would be to split cassandra-all into
cassandra-server and cass
+1 on moving the read/write logic into its own jar.
Doug
> On Dec 11, 2024, at 7:21 PM, David Capwell wrote:
>
> From a disk format point of view the only thing I remember was the disk type
> bug with UDTs. Bringing that logic back was hard as the type system (in 5.0)
> tries to avoid allowi
My expectation is that in trunk SCM CASSANDRA_4 would change to SCM
CASSANDRA_5. I think we should be striving to support full
downgrade/rollback ability to the previous major version from trunk.
With TCM I would expect that when running in CASSANDRA_5 mode that
initializing TCM would not be poss
> But MVs are not alpha or preview, as they are not actively being worked on.
> They are currently broken. Calling them ‘alpha’ makes ‘alpha’ overloaded and
> less useful.
I'm asserting they should either be marked 'alpha/Preview' and actively being
worked on, or be deprecated and removed.
To P
I think it would be better to avoid 'alpha' since we do beta releases,
and I agree with Aleksey that we'd be overloading 'alpha' and perhaps
causing confusion.
Kind Regards,
Brandon
On Thu, Dec 12, 2024 at 8:58 AM Benedict wrote:
>
> I think alpha is fine. It communicates fairly well that there’
Thanks for clarifying your view and sorry for the diversion on the thread
topic, let’s get back to it. It looks like this warrants its own discussion
on future of MVs in the era of accord (whether we still want to provide
eventually consistent MVs in the current format, or remove it in favor of
Acc
I don’t think they should be called or treated as the same feature. Or at least we should rebrand. They also have quite different properties.I would prefer to introduce “Global Indexes” backed by accord, since this is also a clearer name, and gives us a clean break from the mess of MVs. We can deci
> If we don’t intend to begin fixing the feature within the next year or so
we should deprecate it entirely.
+1 - this is probably topic for another thread but isn’t MVs fundamentally
solved with Accord? In my ignorance this is “just” a matter of adding an
Accord backend to MV syntax to fix it rel
I think alpha is fine. It communicates fairly well that there’s no near term expectation they will be production capable. There is (I think) still an intention to improve them, but they are janky. If we don’t intend to begin fixing the feature within the next year or so we should deprecate it entir
> But MVs are not alpha or preview, as they are not actively being worked
on.
fwiw I think Jaydeep and Runtian are looking into improving MV status quo
according to
https://lists.apache.org/thread/d3qo3vjxn4116htf175yzcg94s6jq07d
On Thu, 12 Dec 2024 at 09:45 Aleksey Yeshchenko wrote:
> But MVs
But MVs are not alpha or preview, as they are not actively being worked on.
They are currently broken. Calling them ‘alpha’ makes ‘alpha’ overloaded and
less useful.
> On 12 Dec 2024, at 14:00, Josh McKenzie wrote:
>
>> But we also need an approved non-euphemism for features like MVs (I sugges
Hi all,
OpenTelemetry has become the industry standard for telemetry data in
distributed systems. Tracing, in particular, enables developers to
track the full "path" a request takes through the application,
providing deep insights into distributed applications.
I have drafted a proposal to integr
> But we also need an approved non-euphemism for features like MVs (I suggest
> ‘broken’) and possibly a softer version of it ('dangerous') for our existing
> features that work fine in some narrow well-defined circumstances but will
> blow in your face if you don’t know exactly what you are doi
Hi sam
I can help with the validation of AlibabaCloudSnith.
Sam Tunnicliffe 于2024年12月12日 周四下午9:20写道：
> This patch is probably now ready to merge, having been through several
> iterations of review and with green CI. Before that though, I just want to
> send one more reminder about it. We've endea
This patch is probably now ready to merge, having been through several
iterations of review and with green CI. Before that though, I just want to send
one more reminder about it. We've endeavoured to preserve all existing
behaviour and to keep configuration 100% backwards compatible. However, so
I don’t like ‘unstable’ either, albeit for a different reason, but I don’t
think three is enough and fits, as we already have some features that don’t fit
into either of (preview,beta,ga) - released but broken, released but dangerous,
deprecated, removed.
For new features going forward, alpha (
Hey,
these are interesting metrics when it comes to the number of commits for an
individual like mentioned in that list you compiled, but I want to emphasize
that the way I look at it is that it really just means how big "throughput" the
project has when it comes to how many commits they can ma
31 matches
Mail list logo
