Chiming in after being notified of the change to the wiki. We accounted for all
this at the time, even for release votes. Note the phrasing: "Discussion /
binding votes on releases (Consensus: min 3 PMC +1, no -1)"
That is, only positive votes from PMC members are counted, but negative
committe
al is finalized and any major
> committer dissent reconciled,*” being a prerequisite for moving a CEP to
> [VOTE]. Given the as yet unreconciled committer dissent, it wouldn’t even be
> appropriate to move to a VOTE until we get to the bottom of this repair
> discussion.
>
>
their needs. However, given the complexity of implementing either
> approach, we need to select one for the initial CEP deliverables.
>
> Overall, I’m leaning toward the snapshot-based approach. The
> trade-off—additional disk usage during infrequent repairs—seems more
> acce
> but the snapshot repair design is not a viable path forward. It’s the first
> iteration of a repair design. We’ve proposed a second iteration, and we’re
> open to a third iteration.
I shan't be participating further in discussion, but I want to make a point of
order. The CEP process has no ve
> Like something doesn't add up here because if it always includes the base
> table's primary key columns that means they could be storage attached by just
> forbidding additional columns and there doesn't seem to be much utility in
> including additional columns in the primary key?
You can re-
Yep, that approach seems more than sufficient to me. No need for lots of
ceremony, but good to keep everyone in the decision loop.
> On 9 May 2025, at 13:10, Josh McKenzie wrote:
>
>> I think it doesn’t cost us much to briefly discuss new language features
>> before using them.
> I had that th
I’d also like to explore a bit further the isolation guarantees we’re promising
with "Strict Consistency Mode” - and the protocol details. By strict, do we
mean linearizable? Either way, we should state the guarantees explicitly so we
can evaluate whether the protocol can meet them. Also, if the
Consistent backup/restore is a fundamentally hard and unsolved problem for
Cassandra today (without any of the mentioned features). In particular, we
break the real-time guarantee of the linearizability property (most notably for
LWTs) between partitions for any backup/restore process today.
Fi
slack if you have any trouble.
> On 16 Mar 2025, at 10:44, Benedict Elliott Smith wrote:
>
> Hi everyone,
>
> To update you: the last patches we considered blockers have landed in the
> cep-15-accord branch. Caleb has now started rebasing the branch onto trunk. I
> expec
I want to break out at least one or two shared library projects. Both accord
and in-jvm-dtest-api should share code with the Cassandra main project,
particularly executors/futures/collections/concurrency utilities. This is
something that has caused me some recurring friction over the past few ye
s,
>>> it's easy to fire up a cluster (I do it constantly) and try it out.
>>>
>>> I think if we were to do this, out of consideration we should time box the
>>> amount of time for an evaluation and unless someone raises an objection,
>>> conside
Hi Stefan,
My reading of this mailing list thread is that they think clearspring is junk
(probably fair) and so you shouldn’t use it or convert it. I am not sure this
actually means it cannot be done.
That said, a simpler option might be to produce both sketches until we can
“upgrade” all of t
> So great to see all this hard work about to pay off!
>>> >
>>> > On the questions/concerns front, the only concern I would have towards
>>> > merging this to trunk is if any of the caveats apply when someone is not
>>> > using Accord. Assuming th
My understanding then is that we are free to merge once we are ready? We will
be directing our resources on this basis, so please pipe up promptly if you
disagree. We will update the list once we have our final patches merged (which
should be a good time to kick the tyres for those inclined), an
n 5 Mar 2025, at 17:22, Patrick McFadin wrote:
>
> What is the timing for starting the merge process? I'm asking because
> I have (yet another) presentation and this would be a cool update.
>
> On Wed, Mar 5, 2025 at 1:22 AM Benedict Elliott Smith
> wrote:
>>
>&
Some quick thoughts of my own…
=== Performance ===
- I have seen heap dumps with > 1GiB dedicated to metric counters. This patch
should improve this, while opening up room to cut it further, steeply.
- The performance improvement in relative terms for the metrics being replaced
is rather dramati
. You seem to have left yourself off the list of contributors
>>> though, even though you’ve been a central figure in its development :) So
>>> thanks to all accord & tcm contributors, including Benedict, for making
>>> this possible!
>>>
>>> On Tue, Ma
Hi everyone,
It’s been exactly 3.5 years since the first commit to cassandra-accord. Yes,
really, it’s been that long.
We will be starting to validate the feature against real workloads in the near
future, so we can’t sensibly push off merging much longer. The following is a
brief run-down of
The PMC is happy to announce that Jeremiah Jordan has joined its membership.
Jeremiah has been a member of this community for almost 15 years. I hope you
will join me in welcoming him to the committee.
One thing to consider in this discussion is integration with dtests, and in
particular the simulator. It would help to improve coverage if we had a
“client” that could operate without going over the network (or, going over a
simulated network), so that it can be controlled by the simulator.
The
The more we talk about this, the more my position crystallises against this
approach. The feature we’re discussing here should be easy to implement on top
of user facing functionality; we aren’t the only people who want functionality
like this. We should be dogfooding our own UX for this kind of
atures experience a state change, finding more
> avenues to get the word out will be important.
>
> On Tue, Dec 10, 2024 at 10:04 AM Benedict Elliott Smith
> wrote:
>>
>> As an aside, it would be nice to admit we basically revisit everything each
>> time it become
This is another topic we basically revisit afresh every time :)
I think it’s fine to bump for marketing or vibe reasons, I would support it. I
don’t think we need to confect some weak semverish justification.
> On 10 Dec 2024, at 13:01, Brandon Williams wrote:
>
> Even if TCM is api-compatibl
later when the
relevant context arises.
> On 10 Dec 2024, at 13:00, Benedict Elliott Smith wrote:
>
> I agree with Aleksey that if we think something is broken, we shouldn’t use
> euphemisms, and for this reason I don’t like unstable (this could for
> instance simply mean API u
I agree with Aleksey that if we think something is broken, we shouldn’t use
euphemisms, and for this reason I don’t like unstable (this could for instance
simply mean API unstable). If we intend to never need this descriptor, we
should avoid bike-shedding and insert a “placeholder” for now to be
Yep, I agree with all of this line of discussion. +1 any reasonable variation
of Aleksey, Patrick and Jeremiah’s proposals.
> On 10 Dec 2024, at 12:29, Jeremiah Jordan wrote:
>
> I agree with Aleksey and Patrick. We should define terminology and then
> stick to it. My preferred list would be
mply made the default w/ the guardrails it already has around these
> things becuase there simply isn’t a usable alternative.
>
>> On Dec 10, 2024, at 9:13 AM, Benedict Elliott Smith
>> wrote:
>>
>>
>>> There is no reason it should ever be more capable than S
> There is no reason it should ever be more capable than SAI for any
> partition/token-restricted query use-case, and I don't really see how there's
> any short-term path for any local 2i implementation in C* to be efficient for
> anything else
While I am not personally aware of much evidence p
> Good usage:
>> Collection names = new ArrayList<>();
> becomes
>> var names = new ArrayList();
>
This “good” usage quickly becomes bad, as you’re going to have to mix “good”
and “bad” together, e.g.:
>> var names1 = new ArrayList();
>> Collection names2 = myObject.getNames();
Now, when I
I’m glad you brought this up Stefan, I’d been meaning to raise this myself. var
is valuable for hacking and scripting, but I think it is counterproductive for
a codebase like ours, that is mostly read not written, and where this keyword
creates inconsistencies in where information for navigating
If you exclude test changes, there’s < 50k added and ~2k removed. This works
out to ~7% of the scale of 8099 for lines modified, if this is the benchmark
for disruption.
Altogether, this is a very small patch from the perspective of the existing
codebase. Probably doesn’t even come close to the
works well in most scenarios and doesn’t require
>>>> significant knowledge and tuning. I think past implementations of the
>>>> dynamic snitch are good evidence of that. However, I expressed the same
>>>> concerns internally for a client level project where w
I just want to flag here that this is a topic I have strong opinions on, but
the CEP is not really specific or detailed enough to understand precisely how
it will be implemented. So, if a patch is already being produced, most of my
feedback is likely to be provided some time after a patch appear
Well, that looks like item number one to fix when we change the serialisation
format. We should clearly not duplicate query strings we have recently logged.
We do however appear to also serialise the bind variables, which benefit from
being in the format we already have available in memory.
> O
1) That is not the current state of the code;
2) We should anyway not be codifying something just because a handful of people
have been doing it.
C-10241 does not accord with this view either - it makes clear the debug log
output should be for "where we can log things that might help if somethin
I disagree with all of this. Debug logging can be enabled for production
clusters, but it should not be on by default.
DEBUG should not be taken to mean “background activities” and we should stamp
this out wherever this has been occurring. DEBUG means verbose logging for use
debugging system be
I think I have already proposed a simple solution to this problem on the
thread: if anyone says it’s a hot path (and cannot be persuaded otherwise), it
should be treated as such. Saves argument, but permits an easy escape hatch if
everyone agrees with minimal discussion.
I think this is a good
Syntactically, if we’re updating settings like compaction throughput, I would
prefer to simply update a virtual settings table
e.g. UPDATE system.settings SET compaction_throughput = 128
Some operations will no doubt require a stored procedure syntax, but perhaps it
would be a good idea to spli
I think we need to briefly step back and think about what the syntax means and how it fits into existing syntax.It seems that the dimensionality verbiage assumes we’re logically introducing N vector fields, so that each row adopts a value for all of the vector fields or none. But in practice we ar
Closing the loop on seeking consensus for UX/UI/API changes, I see a few
options. Can we rank choice vote please?
A - Jira suffices
B - Post a DISCUSS API thread prior to making changes
C - Periodically publish a list of API changes for retrospective consideration
by the community
Points raise
My only slight concern with this approach is the additional memory pressure.
Since 64yrs should be plenty at any moment in time, I wonder if it wouldn’t be
better to represent these times as deltas from the nowInSec being used to
process the query. So, long math would only be used to normalise
x those two items, would we be in agreement on this being
> both the core of the syntax we want and compatible w/ the wish list for
> future items?
>
>
> On Sun, Aug 14, 2022 at 12:25 PM Benedict Elliott Smith
> wrote:
>>
>>
>>>
>>> Verbose v
ke.
>
> Deconstructed:
> LET x = SELECT x FROM ...
> LET y = SELECT y FROM ...
>
> Nested:
> LET (x, y) = ((SELECT x FROM…), (SELECT y FROM))
>
> I'm trying to summate but let me know if I missed something. I apologize in
> advance to Monday morning Caleb, who wil
gt;
Yep, this was already agreed way back with the earlier proposal.
> On 14 Aug 2022, at 16:30, Avi Kivity wrote:
>
>
>
> On 14/08/2022 17.50, Benedict Elliott Smith wrote:
>>
>> > SELECT and LET incompatible once comparisons become valid selectors
>>
FROM..
IF a > 1 AND d > 1…
> On 14 Aug 2022, at 13:55, Avi Kivity via dev wrote:
>
>
>
> On 14/08/2022 01.29, Benedict Elliott Smith wrote:
>>
>> I’ll do my best to express with my thinking, as well as how I would explain
>> the feature to a user.
I’ll do my best to express with my thinking, as well as how I would explain the
feature to a user.
My mental model for LET statements is that they are simply SELECT statements
where the columns that are selected become variables accessible anywhere in the
scope of the transaction. That is to
Perhaps we just restrict “trivial” patches to trunk? If it requires several
PRs/branches then a Jira is perhaps warranted, and perhaps if it is trivial and
unimportant it’s better not to waste the project’s time managing the overhead.
This would also be simplified with a modified merge strateg
> We can start by putting the bar at a lower level and raise the level over time
+1
> One simple approach that has been mentioned several time is to run the new
> tests added by a given patch in a loop using one of the CircleCI tasks
I think if we want to do this, it should be extremely easy
I think a change like this could be dangerous for a lot of existing automation
built atop nodetool.
I’m not sure this change is worthwhile. I think it would be better to introduce
e.g. -ste and -ete for “start token exclusive” and “end token exclusive” so
that users can opt-in to whichever sc
e Eggleston wrote:
> Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a
> little trickier. Assigning null to a column seems ok, but we should raise an
> exception if they're doing math or something that expects a non-null value
>
> > On Jun
AFAICT that standard addresses server-side cursors, not the assignment of a
query result to a variable. Could you point to where it addresses variable
assignment?
Postgres has a similar concept, SELECT INTO[1], and it explicitly returns NULL
if there are no result rows, unless STRICT is specifi
For a minor/major? I can imagine doing this for a patch version, but this is of
much less importance to downstream users.
Do you have any examples of projects that do this for major/minor development
branches, as you propose?
I'm just a bit confused about the proposition to decouple from releas
> Vendors are also free to support and provide hot-fixes and back ports on
> these unreleased versions, outside of the community's efforts or concerns
This seems to me like we're endorsing the release of these versions by
downstream maintainers? Even if we decide to modify this proposal and say
Well the other problem I see is that this could create a lot of confusion for
our users, if more versions start popping up (and/or versions are skipped).
It's hard to row back from unwanted versions in the wild, and we may end up
having to either support them or disappoint our users.
Do we have
Hmm, ok. I see some possible issues with this. You mention one possibility,
i.e. that downstream may end up releasing these versions for us? Which
potentially complicates our lives, whether we want it or not.
Would this apply to only trunk, or to all existing major/minor releases?
I wonder if
Sorry, I may be being dense, but it's not that I didn't parse your
justification for it, but that I literally don't understand what the proposal
is.
On 03/05/2021, 08:30, "Mick Semb Wever" wrote:
> I didn't really understand the unreleased versions proposal though.
Benedict, two bri
+1 to semver, shippable trunk, feature flags, and better documentation about
feature support and compatibility edges - we should have a single page with a
table of version x feature, with a summary and links to detailed explanations
of everything important a user should be aware of.
I didn't re
Thanks Aleksei,
Some of these are great points, but to respond specifically to the checkstyle
suggestion: I hope to kick off some (minor) discussion around codestyle soon to
modernise our guide, however I would personally prefer that code style
enforcement remains relatively light touch. Some o
board to help to track newcomers contributions:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463&quickFilter=2088
Apparently Brandon is cheating to appear as a newcomer but we will solve
that. He should be at the Nightmare level ;-)
Le mer. 28 avr. 2021 à
I think there are two main hurdles, one is restoring contributor interest in
mentoring, and the other is finding newcomers that actually want to stick
around. These are perhaps two sides of the same coin, though. An ugly truth is
that it isn't very enjoyable or rewarding to help newcomers when t
atrick
>
> On Tue, Apr 27, 2021 at 10:16 AM Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
> > Quake has it like
> >
> > - I Can Win
> > - Bring It On
> > - Hurt Me Plenty
> > - Hardcore
> &g
ormal.
- Ultra-Violence - Hard.
- Nightmare - Very Hard.
-
On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith
wrote:
> Perhaps we could replace both Complexity and Difficulty with e.g.
> Experience?
>
> Newcomer
> Learner
bring it on its own thread later so
we don't go too far away from the original, and more important, topic which
is how to attract and retain new contributors to the project.
Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
bened...@apache.org> escreveu:
al)
- Hard (current Challenging)
- Very Hard (current Byzantine)
Please let me know what you think.
Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> If you're wondering, they're documented:
>
https://cw
;
> > > > > I believe Paolo started with the project through a contributor
boot
> > > camp.
> > > > > Also if I remember correctly some of the ones that were done were
> > > > internal
> > > > > at DataStax and it helped
t;problem" to have enough
committers to look at it over a (preferably) shorter period of time
and make that feedback loop shorter. That's it. You might have the
best guides and whatever but if a dust settles at it no guide will
make it happen.
On Tue, 27 Apr 20
I think that all of the bootcamps we ran in the past produced precisely zero
new contributors.
I wonder if it would be more impactful to produce slightly more permanent
content, such as step-by-step guides to producing a simple patch for some
subsystem. Perhaps if people want to, a recording co
I think my earlier response vanished into the moderator queue. Just a few
comments:
1) The Paxos latency (and correctness) improvements I think should land in
4.0.x, as we have introduced a fairly significant regression and this work
mostly resolves outstanding issues with LWTs today.
2) If we
> it would make sense to put that information on a *Roadmap* page
That makes sense to me, and I'm looking forward to agreeing a roadmap. I think
it will be nice for the project to start properly looking to the future again.
On 01/04/2021, 14:06, "Benjamin Lerer" wrote:
Thanks everybody.
There is no legal reason; this was disavowed on LEGAL-288. The ostensible
reason is that Roy Fielding, who filed the papers of incorporation, interprets
the charter to require this. I don't think, however, anybody has challenged
this interpretation of the charter. I certainly do not interpret it
As I'm sure you're aware, only a couple of people in the community are able to
follow or participate in board discussions without being expressly included.
On 30/03/2021, 09:51, "Justin Mclean" wrote:
Hi,
JFYI I've started a discussion about this on the board list [1]. Note that
that
> I think the situation is a little more seriously that you may realise, I
> suggest you look at what actions the board has taken in similar situations in
> the past
I thought you had already indicated the likely remedy: the removal of
non-compliant releases?
I’m puzzled by your desire f
+1
On 29/03/2021, 21:16, "Ben Bromhead" wrote:
+1 good sensible suggestion.
On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova
wrote:
> I also like the latest suggestion, +1, thank you
>
> On Mon, 29 Mar 2021 at 14:16, Yifan Cai wrote:
>
> > +1
> >
>
> This is not a retrospective change just a clarification on what should be
> self evident.
This is a non-sequitur surely? Can something that is self-evident need
clarifying? Or do you suppose it is self-evident to all besides the feeble
intellects of this community?
I think a self-evident pol
I thought you had indicated you were anyway raising this with the board?
Either way, I don't personally see any issue with delaying the vote by a week
or so if it will bring some official clarity to this issue, now it has been
raised. How quickly can we expect to see changes reflected in the off
> I guess you are asking for something official from VP Legal Affairs or the
> ASF board? If so I can make that happen.
I would prefer the official policy pages to be updated to have a clear
statement on this, so this problem can be solved in perpetuity.
> IMO it does, the project can choose to
Hi Justin,
You are probably right, but as far as I am aware you are not an official source
of ASF policy on this matter. The official policy pages do not stipulate this,
so I would appreciate if you could get them updated to accord more clearly your
beliefs before the project makes the necessar
> Including Category B binaries in a source release is mentioned in ASF policy
> here [1].
Sorry to keep banging the same drum, but I read this before our earlier emails,
and if this is the intended meaning it needs to be rewritten. I also doubt this
was the intended meaning of the original aut
> Because a source release could not contain compiled code
Again, I don't see this stated explicitly. Perhaps the guidance should be
clarified if this is the intention?
On 27/03/2021, 01:59, "Justin Mclean" wrote:
Hi,
> Could you clarify why you think this is incompatible with ASF po
> I suggest you read the whole thread. The outcome was that it's OK to put jars
> in version control but not in a source release.
There was no outcome AFAICT? There was a suggestion that was explicitly
caveated as only a suggestion that required formal approval by VP Legal, which
does not seem
> When I did download the the 3.11.10 release [2], I can see that it contained
> compiled binary files (jars), which I don't think is in line with ASF release
> policy.
Could you clarify why you think this is incompatible with ASF policy? AFAICT
the policy only stipulates that binary releases _
focus on first.
What do you think?
Le mar. 2 mars 2021 à 06:29, Berenguer Blasi a
écrit :
> +1000 on some form of roadmap for visibility and planning
>
> On 1/3/21 18:35, Benedict Elliott Smith wrote:
> > I completely agree we should consider any roadmap
w we
plan to use CEPs moving forward.
.
Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith a
écrit :
> I guess I meant that I don't foresee roadmap discussions having a hard
> requirement of CEP for all goals we might discuss, though it would
probably
> be
a strongly held position on
either (but think it's probably better they're not intrinsically tied in either
direction).
On 01/03/2021, 12:13, "Benedict Elliott Smith" wrote:
I guess I meant that I don't foresee roadmap discussions having a hard
requirement of
I guess I meant that I don't foresee roadmap discussions having a hard
requirement of CEP for all goals we might discuss, though it would probably be
expected that many of the biggest proposals would already at least have a
minimal CEP to be filed, you're right.
Certainly if an advanced CEP ex
rk" is not restricted to items in the project
roadmap and developers can still make contributions to work unlisted in the
project roadmap, I think having a project roadmap is certainly a step in
the right direction.
Thanks,
Sumanth
On Mon, Mar 1, 2021 at 1:18 A
A while back somebody privately raised the idea of a project roadmap to me, and
I’d like to propose we formally consider it as a project now that 4.0 is
approaching completion.
I think there are two major benefits to agreeing a roadmap:
1) It helps us to coordinate finite project resource
Fair enough.
On 26/02/2021, 20:45, "Mick Semb Wever" wrote:
Should we wait for e.g. five clean CI runs in a row? Historically flaky
> tests have been a real issue for the project, and CI success probably
> shouldn't be taken instantaneously for releases.
There are tickets fo
Very nice.
On 26/02/2021, 21:36, "Melissa Logan" wrote:
Hi all,
We are excited to share the almost-complete Cassandra website design
(CASSANDRA-16115). Huge thanks to Lorina Poland, Anthony Grosso, Mick Semb
Weaver, Josh Levy, Chris Thornett, Diogenese Topper, and a few others
Should we wait for e.g. five clean CI runs in a row? Historically flaky tests
have been a real issue for the project, and CI success probably shouldn't be
taken instantaneously for releases.
On 26/02/2021, 19:38, "Michael Semb Wever" wrote:
> * We’re within line-of-sight to closing out
for some deprecated feature, trunk gets
> > bumped to 5.0.0. More releases happen from trunk 5.0.0, 5.1.0, 5.2.0,
> 5.2.1
> > development on trunk continues on. Time for a new maintenance branch
> with
> > 5.3.0 so cassandra-5.3 gets cut...
> >
>
But, as discussed, we previously agreed limit features in a minor version, as
per the release lifecycle (and I continue to endorse this decision)
On 28/01/2021, 16:04, "Mick Semb Wever" wrote:
> if there's no such features, or anything breaking compatibility
>
> What do you envisag
> if there's no such features, or anything breaking compatibility
What do you envisage being delivered in such a release, besides bug fixes? Do
we have the capacity as a project for releases dedicated to whatever falls
between those two gaps?
I'd like to see us have three branches: life suppor
We have had a very problematic history with release versioning, such that our
users probably think the numbers are meaningless.
However, in the new release lifecycle document (and in follow-up discussions
around qualifying releases) we curtail _features_ once a release is GA, and
also stipulate
eaking change has been introduced,
does it make sense to release a major?
On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith
wrote:
> Perhaps we could also consider quarterly "develop" releases, so that we
> have pressure to maintain a shippable trunk? Thi
d-cycle RC, that a user wanting
shiny features can grab, providing feedback throughout the development cycle.
On 26/01/2021, 14:11, "Benedict Elliott Smith" wrote:
My preference is for a simple annual major release cadence, with minors as
necessary. This is simple for the user com
My preference is for a simple annual major release cadence, with minors as
necessary. This is simple for the user community and developer community:
support = x versions = x years.
I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, and we cut a release a
Joshua McKenzie
> wrote:
>
> > Reasonable categories. We haven't discussed what qualifies where for 4.0
> > have we? (new lacking | changed modest | old lacking)
> >
> > On Fri, Dec 11, 2020 at 9:14 AM Benedict Elliott Smith <
> &
In my opinion...
- Expected to find serious bugs (e.g. new poorly tested features): Block beta
- Anticipated to possibly find serious bugs (e.g. extensively changed features
with modest testing): Block RC
- Anticipated not to find serious bugs (e.g. old unchanged but poorly tested
features): Blo
Perhaps we should skip v5, and move to v6 for the new protocol to avoid this
issue?
On 08/12/2020, 10:53, "Sam Tunnicliffe" wrote:
CASSANDRA-15299 has revised the wire format of CQL native protocol to add a
framing layer around the existing CQL messages. This is targetted at protocol
v5,
1 - 100 of 431 matches
Mail list logo
