Re: [ANNOUNCE] Apache Cassandra 4.0.11 test artifact available

+1 Checked debian and boolean redhat installs Kind Regards, Brandon On Wed, Jul 12, 2023 at 3:08 PM Miklosovic, Stefan wrote: > > The test build of Cassandra 4.0.11 is available. > > sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5 > Git: https://github.com/apache/cassandra/tree/4.0.11-tentative

[ANNOUNCE] Apache Cassandra 4.0.11 test artifact available

The test build of Cassandra 4.0.11 is available. sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5 Git: https://github.com/apache/cassandra/tree/4.0.11-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1303/org/apache/cassandra/cassandra-all/4.0.11/ Th

Re: Changing the output of tooling between majors

Eric, I appreciate your feedback on this, especially more background about where you are comming from in the second paragraph. I think we are on the same page afterall. I definitely understand that people are depending on this output and we need to be careful. That is why I propose to change i

Re: Changing the output of tooling between majors

Agreed with Eric’s point here, yes.- ScottOn Jul 12, 2023, at 10:48 AM, Eric Evans wrote:On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan wrote:I agree with Jackson that having a different output format (JSON/YAML) in order to be able to change the default output

Re: Changing the output of tooling between majors

On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > I agree with Jackson that having a different output format (JSON/YAML) in > order to be able to change the default output resolves nothing in practice. > > As Jackson said, "operators who maintain these scr

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

> Revert for only trunk patches right? > I’d say we need to completely stabilize the environment, no noise before we > go into that direction. Hm. Is the concern multi-branch reverts w/merge commits being awful? Because I hear that. Starting trunk-only would be reasonable enough I think, especia

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

Revert for only trunk patches right? I’d say we need to completely stabilize the environment, no noise before we go into that direction. On Wed, 12 Jul 2023 at 8:55, Jacek Lewandowski wrote: > Would it be re-opening the ticket or creating a new ticket with "revert of > fix" ? > > > > śr., 12 lip

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

> Would it be re-opening the ticket or creating a new ticket with "revert of > fix" ? I have a weak preference for re-opening the original ticket and tracking the revert + fix there. Keeps the workflow in one place. "Downside" is having multiple commits with "CASSANDRA-XX" in the message but

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

I believe some tools can determine which tests make sense to multiplex, given that some exact lines of code were changed using code coverage analysis. After the initial run, we should have data from the coverage analysis, which would tell us which test classes are tainted - that is, they cover the

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

Would it be re-opening the ticket or creating a new ticket with "revert of fix" ? śr., 12 lip 2023 o 14:51 Ekaterina Dimitrova napisał(a): > jenkins_jira_integration > > script > updat

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

jenkins_jira_integration script updating the JIRA ticket with test results if you cause a regression + us building a muscle around reverting your commit if they break tests.“ I am not sure

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

(This response ended up being a bit longer than intended; sorry about that) > What is more common though is packaging errors, > cdc/compression/system_ks_directory targeted fixes, CI w/wo > upgrade tests, being less responsive post-commit as you already > moved on *Two that ***should ***be resolve

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

“ On our 4.0 release I remember a number of such failures but not recently. ” Based on all the 5.0 work I’d say we need as a minimum to build and start a node with all JDK versions pre-commit. On Wed, 12 Jul 2023 at 7:29, Jacek Lewandowski wrote: > Isn't novnodes a special case of vnodes with

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

Isn't novnodes a special case of vnodes with n=1 ? We should rather select a subset of tests for which it makes sense to run with different configurations. The set of configurations against which we run the tests currently is still only the subset of all possible cases. I could ask - why don't ru

Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of the release process

CEP is a great idea. The devil is in details and while this looks cool, it will definitely not hurt to have the nuances ironed out. From: Patrick McFadin Sent: Tuesday, July 11, 2023 2:24 To: dev@cassandra.apache.org; German Eichberger Subject: Re: CASSAN

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

I can certainly start a VOTE thread for the CQL syntax addition. There hasn't been any feedback that suggests that there is an unaddressed concern to the changes we are making. That said, I'm not sure if there was explicit decision that has resulted in an update to the project's governance to refl