[DISCUSS] Next release cut

Hi everybody, I believe that we never really clarified when the next release should happen. We agreed on a yearly frequency but did not go down on the details. It might be worth it to clarify them so that we are sure that everybody is on the same line. We cut 4.0 in May and released it in July.

Re: [DISCUSS] Next release cut

> We cut 4.0 in May and released it in July. It is difficult to plan for a release date so we should probably agree on the cut date. One year after 4.0 that would make us cut the new branch in May. This makes sense to me. The time between each rc1 cut is the only thing we control. We want the

Cassandra project biweekly status update 2021-12-14

Happy Tuesday Morning and Afternoon, which is almost Monday! Benjamin took the time to put together a roadmap (Awesome!) for the next Cassandra release - check that out here: https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap [New contributors getting started] We have a seasonally

RE: Recent log4j vulnerability

Any thoughts what the logback folks have been filed here? https://jira.qos.ch/browse/LOGBACK-1591 Thanks! -Original Message- From: Brandon Williams Sent: Sonntag, 12. Dezember 2021 18:56 To: dev@cassandra.apache.org Subject: Recent log4j vulnerability I replied to a user- post about

Re: Recent log4j vulnerability

The POC seems to require the attacker be able to upload a file that overwrites the configuration, with hot reloading enabled. We do have hot reloading enabled but there's no inherent way to overwrite the config. That said with logback currently at 1.2.3 (in trunk), perhaps we should consider an

Re: [DISCUSS] Releasable trunk and quality

Does somebody else use the git workflow we do as of now in Apache universe? Are not we quite unique? While I do share the same opinion Mick has in his last response, I also see the disadvantage in having the commit history polluted by merges. I am genuinely curious if there is any other Apache

Re: [DISCUSSION] Next release roadmap

Hi, FYI I am planning to put together all we discussed under sstable encryption thread into a kind-of CEP to distil everything said. I hope I'll put it together in the foreseeable future before taking a longer break till February. I am not sure if that is enough time to implement it if we

Re: [DISCUSS] Releasable trunk and quality

> > > > Merge commits aren’t that useful > > > I keep coming back to this. Arguably the only benefit they offer now is > procedurally forcing us to not miss a bugfix on a branch, but given how > much we amend many things presently anyway that dilutes that benefit. > Doesn't this come down to

Re: [DISCUSS] Releasable trunk and quality

> > I like a change originating from just one commit, and having tracking > visible across the branches. This gives you immediate information about > where and how the change was applied without having to go to the jira > ticket (and relying on it being accurate) I have the exact opposite

Re: [DISCUSS] Next release cut

+1 to cut 4.1 in May. It would be great to attain the yearly cut cadence if possible. Em ter., 14 de dez. de 2021 às 09:45, Mick Semb Wever escreveu: > > We cut 4.0 in May and released it in July. It is difficult to plan for a > release date so we should probably agree on the cut date. One year

Re: [DISCUSSION] Next release roadmap

Thanks Benjamin!I see that the Roadmap doc on Confluence contains several features that are large in scope but do not have a published CEP or discussion on the mailing list.Because users will treat the roadmap doc as indicative of the project’s direction and intent, can these items be moved to a

RE: Recent log4j vulnerability

Would 3.11 be considered as well? This would also then keep (stupid/static) sec scans silent in regard to https://nvd.nist.gov/vuln/detail/CVE-2017-5929 Thanks -Original Message- From: J. D. Jordan Sent: Dienstag, 14. Dezember 2021 16:27 To: dev@cassandra.apache.org Subject: Re: Recent

Re: Recent log4j vulnerability

Doesn’t hurt to upgrade. But no exploit there as far as I can see? If someone can update your config files to point them to JNDI, you have worse problems than that. Like they can probably update your config files to just completely open up JMX access or what ever also. > On Dec 14, 2021, at

Re: [DISCUSS] Releasable trunk and quality

> > Merge commits aren’t that useful > I keep coming back to this. Arguably the only benefit they offer now is procedurally forcing us to not miss a bugfix on a branch, but given how much we amend many things presently anyway that dilutes that benefit. Having 1/3rd of your commit history be

Re: [DISCUSSION] Next release roadmap

Sure :-) I will make a separate section. Le mar. 14 déc. 2021 à 17:30, C. Scott Andreas a écrit : > Thanks Benjamin! > > I see that the Roadmap doc on Confluence contains several features that > are large in scope but do not have a published CEP or discussion on the > mailing list. > > Because

Re: [DISCUSS] Releasable trunk and quality

Yeah, I positively dislike merge commits, both from a patch preparation perspective and when trying to piece together a class’ history. It can actively obfuscate the impact to the branch being looked at, as well as make it much harder to skim the git log. I’d vote to modify our merge strategy