Re: [VOTE] Release Apache Cassandra 5.0-beta1

2023-11-30 Thread German Eichberger via dev
I don't think outside people will know the distinction between alpha and beta - for them anything which isn't GA doesn't get deployed (and even then they might wait another year or two). People following this mailing list would lilkey know that 5.0-beta-1 is pretty close to 5.0-alpha-3 -- so

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Alex Petrov
I will try to resopnd, but please keep in mind that all these terms are somewhat contextual. I think long and burn tests are somewhat synonymous. But most long/burn tests that we have in-tree aren't actually that long. They are just long compared to the unit tests. I personally would call the

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Benedict
I don’t know - I’m not sure what fuzz test means in this context. It’s a newer concept that I didn’t introduce.On 30 Nov 2023, at 20:06, Jacek Lewandowski wrote:How those burn tests then compare to the fuzz tests? (the new ones)czw., 30 lis 2023, 20:22 użytkownik Benedict

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Jacek Lewandowski
How those burn tests then compare to the fuzz tests? (the new ones) czw., 30 lis 2023, 20:22 użytkownik Benedict napisał: > By “could run indefinitely” I don’t mean by default they run forever. > There will be parameters that change how much work is done for a given run, > but just running

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Benedict
By “could run indefinitely” I don’t mean by default they run forever. There will be parameters that change how much work is done for a given run, but just running repeatedly (each time with a different generated seeds) is the expected usage. Until you run out of compute or patience.I agree they

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Josh McKenzie
> that may be long-running and that could be run indefinitely Perfect. That was the distinction I wasn't aware of. Also means having the burn target as part of regular CI runs is probably a mistake, yes? i.e. if someone adds a burn tests that runs indefinitely, are there any guardrails or

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Benedict
A burn test is a randomised test targeting broad coverage of a single system, subsystem or utility, that may be long-running and that could be run indefinitely, each run providing incrementally more assurance of quality of the system.A long test is a unit test that sometimes takes a long time to

Re: Removal of deprecations added in Cassandra 3.x

2023-11-30 Thread Josh McKenzie
> Personally, I think the removal of the deprecated code which was marked like > that in 3.x is quite safe to do in 5.x but I have to ask broader audience to > have a consensus. Safe for us, sure. Safe for our users, not so much. No amount of including it in release notes guarantees they'll see

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Josh McKenzie
Strongly agree. I started working on a declarative refactor out of our CI configuration so circle, ASFCI, and other systems could inherit from it (for instance, see pre-commit pipeline declaration here

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

2023-11-30 Thread Patrick McFadin
Congratulations and welcome, Francisco! On Thu, Nov 30, 2023 at 2:45 AM Maxim Muzafarov wrote: > My congratulations, Francisco! :-) > > On Wed, 29 Nov 2023 at 13:30, Andrés de la Peña > wrote: > > > > Congrats Francisco! > > > > On Wed, 29 Nov 2023 at 11:37, Benjamin Lerer wrote: > >> > >>

Re: Removal of deprecations added in Cassandra 3.x

2023-11-30 Thread Mick Semb Wever
> > Personally, I think the removal of the deprecated code which was marked > like that in 3.x is quite safe to do in 5.x but I have to ask broader > audience to have a consensus. Strawman: Evaluate the cost and risk to us by having to keep the code. Weigh that against the effort it takes for

Re: [VOTE] Release Harry 0.0.2

2023-11-30 Thread Alex Petrov
With 7 +1s (5 of which PMC), the vote passes. Thanks everyone! On Wed, Nov 29, 2023, at 6:40 PM, Francisco Guerrero wrote: > +1 > > On 2023/11/29 11:14:29 Alex Petrov wrote: > > Even though we would like to bring harry in-tree, this is not an immediate > > priority. Meanwhile, we need to

Re: Removal of deprecations added in Cassandra 3.x

2023-11-30 Thread Miklosovic, Stefan via dev
Hi, I want to refresh this thread. I know people are busy with 5.0 etc. but I would really like to have this resolved. This might be removed in trunk (1). JMX methods / beans to remove are (2) Mick had a point in (1) that even it is possible to remove it all, do we really want to? We should

Re: [VOTE] Release Apache Cassandra 5.0-beta1

2023-11-30 Thread Maxim Muzafarov
I'm gonna take a moment to outline the question. Here we have a point in time where a time-driven release process clashes with the alpha/beta release naming convention: we want to have a beta ready _before_ the Summit. Here's the Cassandra release lifecycle document [1] that I found (still under

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

2023-11-30 Thread Maxim Muzafarov
My congratulations, Francisco! :-) On Wed, 29 Nov 2023 at 13:30, Andrés de la Peña wrote: > > Congrats Francisco! > > On Wed, 29 Nov 2023 at 11:37, Benjamin Lerer wrote: >> >> Congratulations!!! Well deserved! >> >> Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi a >> écrit : >>> >>> Welcome!

Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

2023-11-30 Thread Jacek Lewandowski
Hi, I'm getting a bit lost - what are the exact differences between those test scenarios? What are the criteria for qualifying a test to be part of a certain scenario? I'm working a little bit with tests and build scripts and the number of different configurations for which we have a separate