Re: [VOTE] Accept java-driver

[Erick Ramirez]

+1 

>

Re: Welcome our next PMC Chair Josh McKenzie

[Erick Ramirez]

Thanks Mick for everything you've done and continue to do for the project!
Congratulations Josh and thanks for stepping up! The community is in good
shape! 

Re: Removing columns from sstables

[Erick Ramirez]

When a column is dropped from a table, it is added to the
system.dropped_columns table so it doesn't get returned in the results. Is
that what you mean? 

>

[DISCUSS] Slack notifications for new Stack Overflow, Stack Exchange questions

[Erick Ramirez]

I previously floated with a couple of PMC members the idea of posting new
Stack Overflow/Stack Exchange questions to the #cassandra Slack channel.
The motivation for doing so include:

   - Promote/advertise the questions (AND answers) on Stack Overflow +
   Stack Exchange.
   - Answers on the Stack network are SEO-friendly unlike Slack
   conversations.
   - Asking on the Stack network reduces duplication for already-answered
   questions.

It was suggested that I do some research on whether other Apache projects
are already using the Slack integration but I haven't been successful in
finding any previous Jira tickets or info on ASF wikis so I logged a ticket
with the ASF Infrastructure team to ask (a) if it's been requested before,
and/or (b) if it's allowed (INFRA-24004
). The Slack-Stack
integration hasn't been requested before but Infra thought it was a good
idea and implemented it before I've had the chance to circle back to the
PMC for next steps.

In any case, does anyone have concerns about the notifications in Slack? Do
you foresee any issues with it? Cheers!

Re: Website fixes PR

[Erick Ramirez]

Thanks for doing this, Derek. We prefer to have an accompanying ticket for
all PRs for trackability.

Also, don't worry about the broken links in the headers/footers -- it's a
known issue. Cheers!

On Fri, 21 Oct 2022 at 04:08, Derek Chen-Becker 
wrote:

> I put together some minor fixes for the website dev documentation:
>
> https://github.com/apache/cassandra-website/pull/179
>
> I've tested these locally using the docker scripts, although antora seems
> to create broken links and navigation (confirmed this behavior even without
> my commit). I was told that this didn't need a JIRA ticket but I'm happy to
> create one to track if that's more appropriate.
>
> Thanks,
>
> Derek
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>

Re: unsubscribe

[Erick Ramirez]

Sorry to see you go. If you'd like to unsubscribe from the dev ML, please
email dev-unsubscr...@cassandra.apache.org. Cheers!

Re: [DISSCUSS] Access to JDK internals only after dev mailing list consensus?

[Erick Ramirez]

+1 to more visibility. What examples of JDK internals access did you have
in mind? I was just trying to think of some practical application where
this would apply. Cheers!

Re: unsubscribe

[Erick Ramirez]

Sorry to see you go. If you'd like to unsubscribe from the dev ML, please
email dev-unsubscr...@cassandra.apache.org. Cheers!

On Wed, 24 Aug 2022 at 23:01, Arpit J  wrote:

>
> Regards,
> Arpit Joshi
>
>

Re: unsubscribe

[Erick Ramirez]

Sorry to see you go. If you'd like to unsubscribe from the dev ML, please
email dev-unsubscr...@cassandra.apache.org. Cheers!

>

Re: [Proposal] add pull request template

[Erick Ramirez]

Yes, it's me. Guilty as charged. 

I appreciate the acknowledgement. Cheers!

On Thu, 18 Aug 2022 at 03:00, Amit Aggarwal 
wrote:

> Hi Erick,
>
> If you are the same Erick, Thank you for answering lots of questions
> related to Cassandra on stack overflow.
>
>
> Thanks
> Amit Aggarwal
>
> On 16-Aug-2022, at 2:28 PM, Erick Ramirez 
> wrote:
>
> I forgot to mention that whatever gets decided, I think it should be
> implemented across all GitHub repos of the project. See here for the
> complete list -- https://projects.apache.org/committee.html?cassandra.
> Cheers!
>
>
>
> *The content of this e-mail is confidential and is intended solely for the
> use of the individual or entity to whom it is addressed. If you have
> received this e-mail by mistake, please reply to this e-mail and follow
> with its deletion. If you are not the intended recipient, please note that
> it shall be considered unlawful to copy, forward or in any manner reveal
> the contents of this e-mail or any part thereof to anyone. Although
> Freshworks has taken reasonable precautions to ensure no malware is present
> in this e-mail, Freshworks cannot accept responsibility for any loss or
> damage arising from the use of this e-mail or attachments.*

Re: [Proposal] add pull request template

[Erick Ramirez]

I forgot to mention that whatever gets decided, I think it should be
implemented across all GitHub repos of the project. See here for the
complete list -- https://projects.apache.org/committee.html?cassandra.
Cheers!

Re: [Proposal] add pull request template

[Erick Ramirez]

Sorry. I hit "send" before pasting the link:

[1] https://cassandra.apache.org/_/development/patches.html

Re: [Proposal] add pull request template

[Erick Ramirez]

+1 this is a great idea. But personally, I'm not too fussed about the level
of detail that is in the template -- what is important is that contributors
are reminded that there needs to be a ticket associated with contributions.
Without being too prescriptive, aspiring contributors should really
familiarise themselves with how to contribute[1] so they would know to
search existing tickets first to avoid things like duplication.

 Additionally, I personally prefer details about a contribution to be
documented in a ticket rather than a PR because information stored in
tickets are more persistent. Having said that, it doesn't hurt to have the
details included in the PR as long as it is in the ticket too. Cheers!

>

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

[Erick Ramirez]

+1 from me. I think this will make it easier for new users. We just need to
document the procedure and make it obvious to everyone else that they need
to update their source. Cheers!

Re: slack channel joining request

[Erick Ramirez]

A friendly reminder that the dev@ mailing list is for discussions by
project contributors. I apologise if it appears I've encouraged non-dev
requests here. Cassandra users are reminded to please use the user@ mailing
list instead. Cheers!

>

Re: Slack channel

[Erick Ramirez]

Welcome! Check your email for details. Cheers!

Re: unsubscribe

[Erick Ramirez]

Hey, mate! Sorry to see you go. If you'd like to unsubscribe from the dev
ML, please email dev-unsubscr...@cassandra.apache.org. Cheers!

On Wed, 20 Jul 2022 at 09:11, Ben Krug via dev 
wrote:

> unsubscribe
>

Re: Joining Apache Cassandra Slack Channel

[Erick Ramirez]

Invite sent. Welcome to the Cassandra community!

>

Re: Thanks to Nate for his service as PMC Chair

[Erick Ramirez]

Thanks Nate for all the work you've put into the project and from
a personal perspective, the support that you've given me through the years.

Congratulations, Mick and thanks for stepping up to the plate. Cheers!

Re: Cassandra replicates data - point me to GitHub code

[Erick Ramirez]

A friendly note to let you know that the dev@ mailing list is for
discussions by C* developers. Please ask in the user@ ML instead. Cheers!

Re: Slow unit tests with Cassandra 4.x on macOS

[Erick Ramirez]

Johannes, I've copied the Dev ML to hopefully get a wider audience. Cheers!

On Wed, 1 Jun 2022 at 21:25, Johannes Weißl  wrote:

> Hello,
>
> We noticed that our unit tests are way slower on macOS after the upgrade
> from Cassandra 3.11.x to 4.x, e.g. over 8 minutes instead of 30 seconds
> (!).
> On Linux the duration stays more or less the same.
>
> After debugging, we found that operations like "DROP KEYSPACE" seem
> responsible for the increase. Also interesting: If Cassandra is started
> via Docker on macOS, the tests run as fast as on Cassandra 3.11.x again.
>
> Is this a known phenomenon? Do others experience it as well?
>
> Thanks,
> Johannes
>

Re: [Marketing] For Review: Changelog blog #16 for May

[Erick Ramirez]

>
> Chris, I just realised that no one had access to the doc.
>

Or maybe you've removed access since the review period has passed. My bad.


Re: [Marketing] For Review: Changelog blog #16 for May

[Erick Ramirez]

Chris, I just realised that no one had access to the doc. I was
specifically checking if there's a link to the World Party in the doc
because it's missing from the PR. Cheers!

On Sat, 28 May 2022 at 06:07, Chris Thornett  wrote:

> Hello everyone,
>
> The Changelog blog for May is available for the usual 72-hour community
> review:
> here: 
> https://docs.google.com/document/d/18gwAuK_pElAZixS2o9YZeqzOcDSF1qU36_GREHx5ipw/edit
> 
>
> Please leave amends in the comment. Thanks!
> --
> Chris Thornett
>

Re: Adding RSS feed to the Apache Cassandra website.

[Erick Ramirez]

Thanks for coordinating this. I'm happy to incorporate the manual process
(option 1) in my workflow when reviewing/publishing blog PRs immediately as
a quick solution if our intention is to go with option 2.

FWIW by "workflow" I mean step 6 of the Pipeline Overview documented in the
wiki here -- https://cwiki.apache.org/confluence/x/-6rkCw. Cheers!

Re: [DISCUSS] CASSANDRA-17669 - CentOS/RHEL installation requires JRE not available in Java 11

[Erick Ramirez]

Yeah, I agree. But in any case, is the dependency check relevant? It's just
expecting a Java higher than 8 which should be covered by the JVM version
check in the startup script, right?

[DISCUSS] CASSANDRA-17669 - CentOS/RHEL installation requires JRE not available in Java 11

[Erick Ramirez]

Package installations on CentOS/RHEL require JRE 1.8+ so on systems where
only Java 11 is installed, either (a) Java 8 is installed as a dependency,
or (b) the dependency check fails.

I haven't seen any tickets or previous discussions on this issue so here it
is -- since JRE is no longer available in Java 11, should we consider
dropping the dependency from the RHEL spec? We don't have this requirement
for Debian installations so dropping it from CentOS/RHEL just brings it
in-line. Thoughts? 

Re: [FOR REVIEW] Blog post: An interview with contributor, Aleksandr Sorokoumov

[Erick Ramirez]

I've posted a couple of minor formatting edits in the doc. Otherwise, it
looks good. Thanks, Alexandr! 

>

[DISCUSS] Proposed guide to asking good questions in Community channels

[Erick Ramirez]

I was chatting to Bowen Song a couple of weeks ago and we stumbled on the
topic of "low quality questions". They're the kind of questions that
usually lack information and/or context that make them difficult to answer.
As much as we hate it, we end up answering these questions with a bunch of
other questions.

Bowen and I talked about the idea of drafting a one-page document so there
is some sort of a minimum standard (for lack of a better expression) when
asking questions. The outcomes we are striving for are:

   - community is more inclined to respond
   - users hopefully get faster responses
   - users hopefully get better answers
   - the project has a higher community engagement from better user
   experiences

For the record, the idea is NOT to be prescriptive and NOT to act as a
hurdle to users. It is there to serve as a guide.

The draft is available for review/feedback/comment here
.
Here's the TL;DR --

   - use a meaningful title or subject line
   - explain the problem you're trying to solve
   - provide background info + workarounds you've already tried
   - list software versions: C*, driver, Java, etc
   - provide full error message + full stack trace
   - provide configuration details
   - include table schema + full CQL query
   - include minimal code which reproduces the issue

I'm proposing to publish the document as a sub-page of the Community
 section of the website. I
plan to send periodic notifications to the user ML and the ASF Slack
channels to let users know of its existence.

We're looking forward to your feedback. Cheers!

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

[Erick Ramirez]

I wanted to bring this up again from Benjamin's original thread
. I agree
with Melissa and I really think there's a lot of value in creating a
company page on LinkedIn in addition to the "C* Community" group. There is
a bigger potential for us from a marketing perspective to promote Cassandra
to a wider audience with a company page. For what it's worth, Apache Pulsar
 already does this. Off the
top of my head, here are some notable points:

LinkedIn company page:

   - ✅ users can "follow" the page and see posts in their feed
   - ✅ users can @-tag Cassandra in their own posts
   - ✅ reach a wider network on LinkedIn
   - ✅ promote new contributors publicly

LinkedIn group:

   - ✅ great for building a community
   - ✅ deeper discussion on topics
   -  users need to join the group
   -  posts are only visible to members

Is there an appetite from the project to pursue this? Cheers!

On Thu, 10 Mar 2022 at 06:06, Melissa Logan  wrote:

> I agree there should be an official LinkedIn page for the project hosted
> by the community. It's an easy way for people to stay current.
>
> If the goal of the new LinkedIn page is to publicly and broadly share what
> the Cassandra community is doing, one solution would be to change the new
> Cassandra page from a "group" page to a "company" page.
>
> Company pages show all posts publicly by default, and admins don't have to
> manage requests to join. Anyone can "follow" the page and see/share the
> posts -- while only allowing community admins to publish. This would also
> require less care and feeding from community admins. (What I don't know if
> it's easy to "convert" a group page to company or if it requires starting
> from scratch.)
>
> Then, admins of the existing "group" page could repost any/all items from
> the community page to keep people informed.
>
> This solution could help both pages achieve their goals of spreading the
> word about Cassandra.
>
> --
> Melissa Logan (she/her)
> Principal, Constantia.io
> LinkedIn  | Twitter
> 
>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Erick Ramirez]

Congratulations Aleksandr and welcome aboard! 

On Thu, 17 Mar 2022 at 00:15, Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Aleksandr Sorokoumov has
> accepted
> the invitation to become committer.
>
> Thanks a lot, Aleksandr , for everything you have done for the project.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members
>

Re: Using labels on pull requests in GitHub

[Erick Ramirez]

Sounds good to me. Thanks for doing all this work, Stefan. 

Re: Using labels on pull requests in GitHub

[Erick Ramirez]

I confess, I'm guilty as charged. I use the git CLI for everything else but
use the merge button on the web UI for convenience. 

Re: Using labels on pull requests in GitHub

[Erick Ramirez]

+1 it's a great idea. I have to admit that I don't go through the PRs and I
only pay attention to tickets so if doc PRs are "orphans" (don't have
associated tickets), I don't ever work on them. I'll aim to do this when I
have bandwidth. Cheers! 

On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Hello,
>
> Is somebody fundamentally opposing the idea of applying labels to pull
> requests when applicable? I went through the pull requests and it
> would be nice to have some basic filters, like "show me all pull
> requests related to documentation" would be labeled as "docs", then
> PRs fixing some tests would be "tests" and so on. We may further
> narrow it down for subsystems etc.
>
> I do not mind applying myself in this to tag the PRs as they come if
> people do not tag it themselves in order to have at least some basic
> "filterability". As I went through PRs closing already committed ones,
> I noticed there are a lot of PRs related to documentation which just
> tend to be completely forgotten in the long run.
>
> Does this make sense to people?
>
> Regards
>
> Stefan
>

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[Erick Ramirez]

Looks good to me! 

On Wed, 16 Mar 2022 at 08:17, Chris Thornett  wrote:

> As requested, I'm posting content contributions for community review on
> the ML for those that might not spot them on Slack.
>
> We're currently mid-review for our first contributor Q which is with
> Lorina Poland:
>
> https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
> Please add edits or suggests as comments.
>
> Thanks!
> --
>
> Chris Thornett
> senior content strategist, Constantia.io
> ch...@constantia.io
>

Re: CFP details

[Erick Ramirez]

Thanks, Rags. But if this is for ApacheCon then we're not quite there yet.
The Cassandra track has to be accepted first before we can send out a call
for papers so stay tuned for details. Cheers!

On Wed, 16 Mar 2022 at 01:36, Raghavan "Rags" N. Srinivas 
wrote:

> Hi all:
>
> I would like to make a submission and help out with this effort.
>
> How do we get this started?
>
> Thanks!
>
> Rags
>

Re: New Apache Cassandra Group on LinkedIn

[Erick Ramirez]

I really like Melissa's idea of having a company instead for higher
visibility and members not having to join a group to see the activity. It
also makes it easy to tag the company in posts and get more engagement that
way. Cheers!

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Erick Ramirez]

Thanks everyone! I'm grateful for the support over the years. I keep saying
that it's a real honour to have the trust of the community on such an
important project. Cheers! 

>

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Erick Ramirez]

(moved dev@ to BCC)


> It looks like the otc_coalescing_strategy config key is no longer
> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
> anywhere in CHANGES.txt or NEWS.txt.
>

James, you're right -- it was removed by CASSANDRA-17132
 in 4.0.2 and 4.1.

I agree that the CHANGES.txt entry should be clearer and we'll improve it
plus add detailed info in NEWS.txt. I'll get this done soon in
CASSANDRA-17135 .
Thanks for the feedback. Cheers!

Re: CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs

[Erick Ramirez]

>
> Does this issue exist on the packaged Apache Cassandra 40X ?
>

Yes, it does. Cheers!

Re: Is Cassandra going to be a part of GSoC 2022?

[Erick Ramirez]

Welcome! Yes, it is. Details in these threads --
https://lists.apache.org/thread/58v2bvfzwtfgqdx90qmm4tmyoqzsgtn4 and
https://lists.apache.org/thread/rht6py71z1f8cxjzpo22bhgzl3f60kdp. Cheers!

Re: Permission to create a CEP for pluggable SSTable formats

[Erick Ramirez]

Noting here that I responded on the #cassandra-dev channel so someone could
grant Jacek edit access to the cwiki. Cheers!

Re: Welcome Adam Holmberg as Cassandra committer

[Erick Ramirez]

Fantastic! Congratulations, Adam! 

Re: Welcome Jon Meredith as Cassandra committer

[Erick Ramirez]

Fantastic news. Congratulations, Jon!

Re: Number of DCs in Cassandra

[Erick Ramirez]

Noting here that the same question was asked and answered in the users@ ML.
Cheers!

Re: Additions to Cassandra ecosystem page?

[Erick Ramirez]

>
> And I'm thinking of anyone that has to update this list and reason through
> all of the complex rulesets of why or why not, It's really not fair to
> them.

My proposal is that we completely drop the Cassandra Cloud Offereing
> section.
> Given that criteria, Professional Support and Education might be on the
> chopping
> block as well.
>

+1 would definitely make my life easier when I'm reviewing/pushing updates
to the site. 

Re: [DISCUSS] Jira state for second reviewer

[Erick Ramirez]

+1 sounds good. I recall seeing the conversation in #cassandra-dev --
weren't you also going to add a tag so it's easy to pick the tickets that
need a second reviewer? Cheers!

Re: Additions to Cassandra ecosystem page?

[Erick Ramirez]

I'm a huge +1 to the sentiments here.

I have to confess that I've been responsible for publishing the updates for
several months now with Mick's mentoring. I publish the content I was
requested to push to the site but as far as review is concerned, the only
review I do is mostly around grammar and formatting and make sure that the
updates render correctly on the site.

It would be ideal if there was a charter from the community I could refer
to so it wouldn't seem like I'm unilaterally rejecting some entries but not
others. I'm glad we've got this thread because I could use it to support
what I do on the site. Cheers!

Re: Materialized Views during node replace

[Erick Ramirez]

I can't recall if view builds affect the bootstrap but index builds
definitely do. It's a bit late now but you could've run nodetool
compactionstats to see what tasks were running at the time and those need
to complete before the bootstrap is considered complete for the node to go
into UP/NORMAL status. Cheers!

Re: Changelog blog (May 2021) is ready for community review

[Erick Ramirez]

>
> How do I unsubscribe from this mailing list?
>

You need to email dev-unsubscr...@cassandra.apache.org. Cheers!

Re: Welcome Caleb Rackliffe as Cassandra committer

[Erick Ramirez]

Fantastic news. Congratulations, Caleb!

Re: [DISCUSS] CASSANDRA-16666 - Make SSLContext creation pluggable/extensible

[Erick Ramirez]

Welcome, Maulin! And thanks for being part of the Cassandra community. 

On Thu, 13 May 2021 at 10:15, Maulin Vasavada 
wrote:

> Hi
>
> I just created the CASSANDRA-1 JIRA ticket. Please let me know if the
> discussion around that should happen here or on the jira ticket.
>
> I've contributed to Apache Kafka in the past but they have a little
> different process for certain contributions by following KIP route.
>
> Looking forward to making a valuable contribution to the Cassandra stack.
>
> Thanks
> Maulin
>

Re: Switching the website to a temporary static html version of the new design

[Erick Ramirez]

>
> FTR i'm +1 to make the switch (early next week).
>
> Generally, this would make me uneasy that a transition like this is at
> the mercy of resources that are being provided outside of the
> community's control. But here I am confident that what is left to do
> on the antora version will be completed. And in the unthinkable and
> improbable situation where it doesn't we can always roll back to the
> current website.
>

I'm a +1 to the switch. As a risk mitigator, I was hoping we could preserve
the sub-URIs so the switch doesn't impact current users:
- make sure /doc/3.11/ (and other supported versions) still works
- rename /doc/latest/ to /doc/4.0/ but pointing to the existing version of
the site
just to be sure we have a workaround in place. Cheers!

Re: [DISCUSS] Releases after 4.0

[Erick Ramirez]

+1 excellent proposal. It makes it easier for the community to understand
and plan ahead.

I wanted to suggest an addendum that a review of 4.0/3.x support be done in
(say) April 2022 in case of delays with 5.x [and beyond]. Thoughts?

On Tue, 30 Mar 2021 at 01:41, Joseph Lynch  wrote:

> I am slightly concerned about removing support for critical bug fixes
> in 3.0 on a short time-frame (<1 year). I know of at least a few major
> installations, including ours, who are just now able to finish
> upgrades to 3.0 in production due to the number of correctness and
> performance bugs introduced in that release which have only been
> debugged and fixed in the past ~2 years.
>
> I like the idea of the 3-year support cycles, but I think since
> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> to, we should reset the clock somewhat. What about the following
> assuming an April 2021 4.0 cut:
>
> 4.0: Fully supported until April 2023 and high severity bugs until
> April 2024 (2 year full, 1 year bugfix)
> 3.11: Fully supported until April 2022 and high severity bugs until
> April 2023 (1 year full, 1 year bugfix).
> 3.0: Supported for high severity correctness/performance bugs until
> April 2022 (1 year bugfix)
> 2.2+2.1: EOL immediately.
>
> Then going forward we could have this nice pattern when we cut the
> yearly release:
> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> Y(n-1): Fully supported for 1 more year and supported for high
> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> bugfix)
>
> What do you think?
> -Joey
>
> On Mon, Mar 29, 2021 at 9:39 AM Benjamin Lerer
>  wrote:
> >
> > Thanks to everybody and sorry for not finalizing that email thread
> sooner.
> >
> > For the release cadence the agreement is:* one release every year +
> > periodic trunc snapshot*
> > For the number of releases being supported the agreement is 3.  *Every
> > incoming release should be supported for 3 years.*
> >
> > We did not reach a clear agreement on several points :
> > * The naming of versions: semver versus another approach and the name of
> > snapshot versions
> > * How long will we support 3.11. Taking into account that it has been
> > released 4 years ago does it make sense to support it for the next 3
> years?
> >
> > I am planning to open some follow up discussions for those points in the
> > coming weeks.
> >
> > When there is an agreement we should document the changes on the webpage
> > > and also highlight it as part of the 4.0 release material as it's an
> > > important change to the release cycle and LTS support.
> > >
> >
> > It is a valid point. Do you mind if I update the documentation when we
> have
> > clarified the version names and that we have a more precise idea of when
> > 4.0 GA will be released? That will allow us to make a clear message on
> when
> > to expect the next supported version.
> >
> > On Mon, Feb 8, 2021 at 10:05 PM Paulo Motta 
> > wrote:
> >
> > > +1 to the yearly release cadence + periodic trunk snapshots + support
> to 3
> > > previous release branches.. I think this will give some nice
> predictability
> > > to the project.
> > >
> > > When there is an agreement we should document the changes on the
> webpage
> > > and also highlight it as part of the 4.0 release material as it's an
> > > important change to the release cycle and LTS support.
> > >
> > > Em sex., 5 de fev. de 2021 às 18:08, Brandon Williams <
> dri...@gmail.com>
> > > escreveu:
> > >
> > > > Perhaps on my third try...  keep three branches total, including
> 3.11:
> > > > 3.11, 4, next. Support for 3.11 begins ending after next+1, is what
> > > > I'm trying to convey.
> > > >
> > > > On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams 
> > > wrote:
> > > > >
> > > > > Err, to be clear: keep 3.11 until we have 3 other branches.
> > > > >
> > > > > On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams 
> > > > wrote:
> > > > > >
> > > > > > I'm +1 on 3 branches, and thus ~3 years of support.  So in the
> > > > > > transition, would we aim to keep 3.11 until after 4.0 and a
> successor
> > > > > > are released?
> > > > > >
> > > > > > On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer
> > > > > >  wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Are we also trying to reach a consensus here that a release
> > > branch
> > > > should
> > > > > > > > be supported for ~3 years (i.e. that we are aiming to limit
> > > > ourselves to 3
> > > > > > > > release branches plus trunk)?
> > > > > > >
> > > > > > >
> > > > > > > 3 release branches make sense to me +1
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever <
> m...@apache.org>
> > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > > I believe that there is an appetite for the bleeding edge
> > > > snapshots where
> > > > > > > > > we do not guarantee stability and that the semver
> discussion is

Re: Welcome Berenguer Blasi as Cassandra committer

[Erick Ramirez]

Congratulations, Berenguer! Thanks for all the work you've done. 


On Thu, 25 Mar 2021 at 21:10, Benjamin Lerer  wrote:

>  The PMC's members are pleased to announce that Berenguer Blasi has
> accepted the invitation to become committer today.
>
> Thanks a lot,  Berenguer,  for all the work you have done!
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members
>

CASSANDRA-16496 Community blog post for March 2021

[Erick Ramirez]

FYI Changelog #5 put together by Chris Thornett & co at Constantia.io is
ready to be staged for final review.

For reference, I've submitted PR #38 --
https://github.com/apache/cassandra-website/pull/38. Cheers!

Re: Project website analytics

[Erick Ramirez]

Thanks Stefan, Instaclustr and everyone involved!

Re: New Cassandra website for review

[Erick Ramirez]

Fantastic! Can't wait for it to go live.


On Sat, 27 Feb 2021 at 08: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 who
> contributed to this effort.
>
> Note: There are a few updates to be made prior to launch, but we wanted to
> share to get initial input and signoff to begin the final port to Antora.
>
> To be completed:
>
>- *Homepage: *The logos are placeholders -- they're being updated and
>resized (pulled from case studies page).
>- *Docs* will be added once 4.0 documentation is complete. Design
>will match new site.
>- *Case Studies * logos are being updated and resized, so ignore broken
>links.
>
> If you have case studies or resources -- or community photos --
> please reply to me and we'll add.
>
> Site for review: https://cassandra.staged.apache.org/
>
> https://issues.apache.org/jira/browse/CASSANDRA-16115
>
> Melissa Logan
>

Re: Monthly community blog - thoughts?

[Erick Ramirez]

What a great idea! This is a good signal on how active the community is.

I'm happy to help with proof-reading/reviews.

P.S. The section on Harry contains HTML code. :)

Re: Supported upgrade path for 4.0

[Erick Ramirez]

>
> Perhaps if others want to explicitly encourage the 3.0->3.11->4.0 upgrade
> path, we can split our resources accordingly?
>

Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't
think that was required.

Re: Supported upgrade path for 4.0

[Erick Ramirez]

If a user asked me today, I would tell them to test the following paths
before attempting it in production:
- 2.1.x   --->   2.1.latest   --->   3.11.latest   --->   4.0
- 2.2.x   --->   2.2.latest   --->   3.11.latest   --->   4.0
- 3.0.x   --->   3.0.latest   --->   4.0
- 3.x --->   3.11.latest  --->   4.0

The upgrade paths from 2.1/2.2/3.0/3.x to 3.11 are well-established and
known today although the procedure isn't documented on the Apache website.
I'd be happy to get drafts in if there are no objections. Cheers!

Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

[Erick Ramirez]

Very well said, Patrick!

I'm not part of the inner circle of contributors so I'm a bit of an
outsider. But as an advocate for Cassandra and the community, I'm
optimistic that we will collectively get past this bump on the road, get
4.0 GA in 2020 and do bigger things in 2021. Cheers!

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Erick Ramirez]

>
>  and it appears to be required on "Submit Patch" - the problem is that
> nobody really fills it out very well.  Being mandatory is insufficient.
>

+1 I agree. Wherever this ends up in the workflow, I'd like to suggest that
a reviewer verify that doc updates are *not* required as part of the "exit"
criteria. Thoughts?

Re: [Discussion] Windows support

[Erick Ramirez]

>
> My point is, for educational purposes there are plenty of other ways of
> running small dev clusters that are probably more realistic for most uses
> cases.
> I’d be for removing windows support, but I suspect my use case is one of
> the more minor ones.
>

Not minor at all. Thanks for that insight, Andy.

I field a lot of questions daily from Windows users and it's a huge drain
because I mostly work/build/test on Ubuntu. I have a Windows 10 Surface and
I can say that I waste so much time trying to replicate what mistake users
made on their PCs so I can help them get past it. But most of the work ends
up being spent on troubleshooting their PCs and not C* so I'm all for
dropping it since it causes too much friction with user adoption. Cheers!

Re: Local getting started tool

[Erick Ramirez]

>
> ...  However, there is a community page that has things like books
> & publications.  I think it could be helpful to add a 3rd party projects
> section to that page, as there's a number of useful utilities like reaper,
> tlp-stress, the various K8 operators, instaclustr's sstable tools, etc.
>

Brilliant idea, Jon. Making the tools and operators from Instaclustr,
Orange and TLP easily located by users is a good thing. :)

Re: Staging website at cassandra.staged.apache.org

[Erick Ramirez]

There's instructions on https://github.com/apache/cassandra-website which I
found out from Mick earlier this week. Cheers!

Re: [VOTE] Release Apache Cassandra 4.0-alpha4

[Erick Ramirez]

>
> > All java8 UTs, jvmdtests and dtests pass
> >
> https://circleci.com/workflow-run/d7b3f62d-c9ad-43d6-9152-2655e27feccb?signup-404=true
>
>
> Is anyone else able to see this^ circleci page?
> For me, it never loads, and isn't the first time I've been unable to
> see others' circleci results.
>

All that shows up for me is:

Workflows  >>  null  >>  null  >> null
0 jobs in this workflow


and a spinning widget.

Re: Keeping test-only changes out of CHANGES.txt

[Erick Ramirez]

>
> In a conversation with Mick we discussed keeping doc changes out as well.
> Anyone object to eliding documentation changes from CHANGES.txt?
>

+1 It will just get too noisy otherwise.

Re: [Discuss] num_tokens default in Cassandra 4.0

[Erick Ramirez]

+1 on 8 tokens. I'd personally like us to be able to move this along pretty
quickly as it's confusing for users looking for direction. Cheers!

On Tue, 18 Feb 2020, 9:14 am Jeremy Hanna, 
wrote:

> I just wanted to close the loop on this if possible.  After some discussion
> in slack about various topics, I would like to see if people are okay with
> num_tokens=8 by default (as it's not much different operationally than
> 16).  Joey brought up a few small changes that I can put on the ticket.  It
> also requires some documentation for things like decommission order and
> skew.
>
> Are people okay with this change moving forward like this?  If so, I'll
> comment on the ticket and we can move forward.
>
> Thanks,
>
> Jeremy
>

Re: [RELEASE] Apache Cassandra 4.0-alpha3 released

[Erick Ramirez]

Congratulations! 

For those who may not be familiar with the behind-the-scenes, this is a
major milestone for the project and another step closer to the release of
Apache Cassandra 4.0. I'm so excited about this news and you should be
too! 