>
> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it
> will signal to the community that we’re prioritizing stability and it could
> be a good opportunity to get people to test the beta or RC before we stamp
> it as production ready.
>
I agree with Paulo's comment
czw.,
Hello everyone :
What is the final conclusion of this discuss ?
As https://issues.apache.org/jira/browse/CASSANDRA-18934 has been created ,
and we know that for system table of different c* version , the schema info
may be different as we may
add or delete column or modify the table properties in
There will be a Cassandra track at Community Over Code Europe 2024
(formerly known as Apachecon EU) that will happen on Bratislava, Slovakia
on 3 Jun 2024.
If you have any talks proposals about using, deploying or modifying Apache
Cassandra please make a submission before 12 Jan 2024 to speak at
> if any contributor has an opinion which is not technically refuted it
will usually be backed by a PMC via a binding -1
clarifying a bit my personal view: if any contributor has an opinion
against a proposal (in this case this release proposal) that is not refuted
it will usually be backed by a
To me, the goal of a beta is to find unknown bugs. If no new bugs are found
during a beta release, then it can be automatically promoted to RC via
re-tagging. Likewise, if no new bugs are found during a RC after X time,
then it can be promoted to final.
If we end up not releasing a final 5.0
Jenkins Trunk is also not running post commit at the moment - pending
https://issues.apache.org/jira/browse/CASSANDRA-19083
On Wed, 29 Nov 2023 at 3:38, Mick Semb Wever wrote:
>
> For broader awareness.
>
> The debranch job on ci-cassandra.a.o: that used for pre-commit testing; is
> currently
On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko
wrote:
> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
> but I’m not sure there is significant value to be had from it. Merge the
> fixes for outstanding issues listed above, then cut beta1.
>
Agree with Aleksey. -1
> Even though my opinion doesn't really count here, I do feel compelled to
> mention that:
>
Aaron (and anybody who takes the time to follow this list, really), your
opinion matters, that's why we discuss it here.
Hi everyone,
We are a couple of weeks away from Cassandra Summit. People get busy and
forget to register or miss that there is even a summit happening. Let's
make sure everyone who wants to go gets a chance!
- If you are going, get on the social media of your choice and let
everyone know you'll
Tomorrow (Thursday, Nov. 30) please join the Cassandra community for talks
from:
- mondayDB - Crafting a Database from Scratch with Liran Brimer
- The State of the Cassandra Development Community with Josh McKenzie,
Cassandra PMC Chair
How to join:
Thanks, Mick
It seems that no one had objections to your suggestion so I will move
forward with that:
“I suggest, for expediency, to
- put a nice failure message in Sjk.java (e.g. "JDK required for this
nodetool command"),
- add a comment in cassandra.yaml in front of audit_logging_options
> So in the context of this thread, if I want to try out SAI for example, I
don't care as much about consistency edge cases around coordinators or
replicas or read repair.
That would apply to 19018, not 19011, which is a critical functionality
issue.
On Wed, Nov 29, 2023 at 12:49 PM Jeremy Hanna
I want to just follow up with functional versus production-worthy. If I'm a
user interested in C* 5 and want to try it out as betas come out, I'm looking
more for something functional and not perfect. So in the context of this
thread, if I want to try out SAI for example, I don't care as much
Even though my opinion doesn't really count here, I do feel compelled to
mention that:
- No one expects a "beta" release to be perfect, but it does signal that
it is "close" to being ready.
- An "alpha" release is in fact a LOT scarier than a "beta" release.
>From a user perspective, if I was
+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 unblock RPM builds for trunk, which means no
> custom jars. We will have at least one more Harry release with outstanding
> features to
+1
On Wed, Nov 29, 2023, at 7:03 AM, Brandon Williams wrote:
> +1
>
> Kind Regards,
> Brandon
>
> On Wed, Nov 29, 2023 at 5:15 AM Alex Petrov wrote:
> >
> > Even though we would like to bring harry in-tree, this is not an immediate
> > priority. Meanwhile, we need to unblock RPM builds for
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!
>> On 29/11/23 2:24, guo Maxwell wrote:
>>
>> Congrats!
>>
>> Jacek Lewandowski 于2023年11月29日周三 06:16写道：
>>
+1
> On 29 Nov 2023, at 07:23, Marcus Eriksson wrote:
>
> +1!
>
> /Marcus
>
> On Fri, Nov 24, 2023 at 04:43:36PM +0100, Alex Petrov wrote:
>> Hi everyone,
>>
>> With TCM landed, there will be way more Harry tests in-tree: we are using it
>> for many coordination tests, and there's now a
+1
Kind Regards,
Brandon
On Wed, Nov 29, 2023 at 5:15 AM Alex Petrov wrote:
>
> Even though we would like to bring harry in-tree, this is not an immediate
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no
> custom jars. We will have at least one more Harry release
+1
> On 29 Nov 2023, at 11:35, Sam Tunnicliffe wrote:
>
> +1
>
>> On 29 Nov 2023, at 11:14, Alex Petrov wrote:
>>
>> Even though we would like to bring harry in-tree, this is not an immediate
>> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no
>> custom jars. We
-1 on cutting a beta1 in this state. An alpha2 would be acceptable now, but I’m
not sure there is significant value to be had from it. Merge the fixes for
outstanding issues listed above, then cut beta1.
With TCM and Accord pushed into 5.1, SAI is the headliner user-visible feature.
It is what
Congratulations!!! Well deserved!
Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi a
écrit :
> Welcome!
> On 29/11/23 2:24, guo Maxwell wrote:
>
> Congrats!
>
> Jacek Lewandowski 于2023年11月29日周三 06:16写道：
>
>> Congrats!!!
>>
>> wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky napisał:
>>
>>>
+1
> On 29 Nov 2023, at 11:14, Alex Petrov wrote:
>
> Even though we would like to bring harry in-tree, this is not an immediate
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no
> custom jars. We will have at least one more Harry release with outstanding
>
+1
On Wed, Nov 29, 2023 at 12:14:29PM +0100, Alex Petrov wrote:
> Even though we would like to bring harry in-tree, this is not an immediate
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no
> custom jars. We will have at least one more Harry release with
+1, we definitely need to start releasing jars, and preferrably doing it with
some reasonable cadence / on demand.
There is a slight problem with the fact we can not cut releases without votes,
which, combined with the fact that we need sha-stable snapshots, makes it
tricky. Best way to do
Even though we would like to bring harry in-tree, this is not an immediate
priority. Meanwhile, we need to unblock RPM builds for trunk, which means no
custom jars. We will have at least one more Harry release with outstanding
features to avoid any blocking.
Proposing the test build of
Raising for broader awareness, the project plans to announce a Catalyst
program in the next few days. For further details please
see CASSANDRA-19054.
If you have any questions or concerns please raise them.
>
> If you checked SHAs I suspect we would skip 90% of the dtests-jar builds
> in CI?
>
Yes. The repeated building in each stage and split/container is nuts.
This can be solved in various ways, e.g. stashes, published snapshots, …
I think the stashing approach is simplest here, at the build
For broader awareness.
The debranch job on ci-cassandra.a.o: that used for pre-commit testing; is
currently not available for patches against 5.0 and trunk.
Restoring it is part of CASSANDRA-18594. This was a priority up until
recently, eta now is early January.
Those that do not have circleci
If you checked SHAs I suspect we would skip 90% of the dtests-jar builds
in CI?
On 29/11/23 9:26, Mick Semb Wever wrote:
On Tue, 28 Nov 2023 at 20:06, Abe Ratnofsky wrote:
Hey folks - wanted to raise a separate thread to discuss
publishing of dtest-shaded JARs on release.
On Tue, 28 Nov 2023 at 20:06, Abe Ratnofsky wrote:
> Hey folks - wanted to raise a separate thread to discuss publishing of
> dtest-shaded JARs on release.
>
> Currently, adjacent projects that want to use the jvm-dtest framework need
> to build the shaded JARs themselves. This is a decent
31 matches
Mail list logo
