Re: Calling for release managers (Committers and PMC)

t; last post-vote publish step. > > > > > > > > > > regards, > > > > > Mick > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.ap

Re: [VOTE] Release Apache Cassandra 3.11.7

itbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.7-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.7-tentative -- Eric Evans eev...@apache.org ---

Re: [VOTE] Project governance wiki doc (take 2)

s in this thread as our > initial roll call count for electorate numbers and low watermark > calculation on subsequent votes. > > Thanks again everyone (and specifically Benedict and Jon) for the time and > collaboration on this. > > ~Josh -- Eric Evans john.eric.ev...@gmail.

Re: [VOTE] CEP-15: General Purpose Transactions

On Thu, Oct 14, 2021 at 11:32 AM bened...@apache.org wrote: > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, > as discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the transaction semantics

Re: New Apache Cassandra Group on LinkedIn

On Wed, Mar 9, 2022 at 12:39 PM Patrick McFadin wrote: > I'm not sure if they can merge groups but from what I'm reading that > wouldn't work either. What I'm seeing is a desire to not "promote vendors" > which I believe is working against the project's self-interest. LinkedIn is > the perfect

Re: [DISCUSS] List Apache Cassandra as a "company" on LinkedIn

o don't natively speak English might struggle to keep pace in real time (to name just a few reasons). This is probably why the ASF is so adamant about the use of email. -- Eric Evans eev...@apache.org

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever wrote: >> >> >> The TCM work (CEP-21) is in its review stage but being well past our >> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would >> like to propose the following. >> >> >> >> I think this presumes that 5.0 GA is date driven instead of feature >> driven. >> >> I'm sure there's a conversation elsewhere, but why isn't this date >> movable? >> >> >> -- Eric Evans Staff SRE, Data Persistence Wikimedia Foundation

Re: Changing the output of tooling between majors

g can create, and show a bit of empathy before submitting a change. For operators on the receiving end, it can be really frustrating, especially when there is no normative change (i.e. it's in service of aesthetics). -- Eric Evans Staff SRE, Data Persistence Wikimedia Foundation

Re: Changing the output of tooling between majors

in terms of the implementation of JSON/YAML format output. > Some commands are quite sophisticated and I do not want to be blocked to > change a field in human-readable out because providing corresponding > JSON/YAML format would be gigantic portion of the work itself. > > From what

Re: Changing the output of tooling between majors

ituation is to acknowledge that the console output is a contract, and act accordingly. In this case: offer (and promote) those structured replacements (JSON, YAML), document the intended instability, and follow through after a sufficient window. -- Eric Evans john.eric.ev...@gmail.com

Re: Changing the output of tooling between majors

gnificant adoption in the user community, > I would strongly advise against making breaking changes to the CLI output. > +1 -- Eric Evans john.eric.ev...@gmail.com

Re: Question regarding Client.set_keyspace(String)

() in 0.7. -- Eric Evans eev...@rackspace.com

Calling all library maintainers

://issues.apache.org/jira/browse/CASSANDRA-1703 Discuss! -- Eric Evans eev...@rackspace.com

Re: Calling all library maintainers

for solving all connection/interface challenges. I take your point, and I don't see it as a silver bullet, but this is going to be *much* less complex than SQL. -- Eric Evans eev...@rackspace.com

<    1   2   3   4