Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

> The lower the bar to participation on this stuff the better, as it isn’t > deeply technical and we have lots of lurkers here that have relevant > experience and knowledge that can chime in with valuable feedback if given > the chance Good point. Separate thread for API Revisions is the lowest

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Following on what Matt said: - Here is the link to the Cassandra repo with the bugfix of wait time from ms to ns: https://github.com/apache/cassandra/compare/trunk...marianne-manaog:cassandra:bugfix/wait-from-ms-to-ns - the Paxos configuration used is: paxos_contention_wait_randomizer: uni

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Me and Marianne are also still chasing a performance issue with Paxos v2 when compared with v1. We see way more contention on v2 for a LOCAL_SERIALIZABLE workload that writes/reads to only 100 partitions (v2 performs better for higher partition counts). We're still investigating what's going on. S

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

My view is simply that API discussion should be undertaken in a broader forum than Jira. The lower the bar to participation on this stuff the better, as it isn’t deeply technical and we have lots of lurkers here that have relevant experience and knowledge that can chime in with valuable feedback

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

> > Are you therefore asking why I do not monitor these topics and propose > DISCUSS threads based on activities others are undertaking? This doesn’t > seem like the right approach to me, but if we do not come to some policy > approach here, I will try to schedule some time each quarter to scan for

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

> CASSANDRA-18086 should probably be fixed and merged first, as Paxos v2 will > be unlikely to work well for users without it. Either that or we need to > update NEWS.txt to mention it. That's a really small one-liner - I'd be game for us getting that reviewed and merged and re-calling the vote

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

> can we add a label in Jira API or something like that and then Josh can > filter those in the bi-weekly report? > I do not personally think the project status thread is the right venue for > this, though a periodic dedicated “API Changes” thread might not be a bad > approach. My understandin

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

> > This doesn’t seem like the right approach to me, but if we do not come to > some policy approach here, I will try to schedule some time each quarter to > scan for topics I think should have had a DISCUSS thread, and open them up > for discussion. That after the fact review approach doesn't se

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

“ I do not personally think the project status thread is the right venue for this, though a periodic dedicated “API Changes” thread might not be a bad approach.” Just to clarify, I do not suggest to use the status mail to respond with concerns. But more like - having a link to the filter in the bi-

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Perhaps you misunderstand my concern? I think these decisions need broader input, not just my input. Are you therefore asking why I do not monitor these topics and propose DISCUSS threads based on activities others are undertaking? This doesn’t seem like the right approach to me, but if we do n

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Benedict, I am confused. If you are so much concerned about virtual tables or CQL why do you not track those components changes directly? People usually label them correctly I believe. Like that you would be able to provide feedback straight away rather than after the fact. It would be a win for e

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Quick idea - can we add a label in Jira API or something like that and then Josh can filter those in the bi-weekly report? In the meantime if there are big changes that people consider they need a DISCUSS thread for they can always open one? I will be happy to help with the mentioned filter/report.

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

I would be fine with a formal API change review period prior to release, but if we go that route people should expect to have to revisit work they completed a while back, and there should be no presumption that decisions taken without a DISCUSS thread should be preferred to alternative suggestio

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

It feels bit of overkill to me to require addition of any new virtual tables/JMX/configuration/knob to go through a discuss thread. If this would require 70 threads for the previous release I think this would easily become spammy and counter-productive. I think the burden should be on the maintain

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 On Mon, 5 Dec 2022 at 11:37, Benedict wrote: > -0 > > CASSANDRA-18086 should probably be fixed and merged first, as Paxos v2 > will be unlikely to work well for users without it. Either that or we need > to update NEWS.txt to mention it. > > On 5 Dec 2022, at 11:01, Aleksey Yeshchenko wrote:

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Indeed that contribution policy should be clearer and not be on a page titled code style, thanks for briging that up. If we consider all those things APIs, and additions are also considered changes that require a DISCUSS thread, it turns out that almost any not-bugfix ticket would require a mail l

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

-0 CASSANDRA-18086 should probably be fixed and merged first, as Paxos v2 will be unlikely to work well for users without it. Either that or we need to update NEWS.txt to mention it. > On 5 Dec 2022, at 11:01, Aleksey Yeshchenko wrote: > > +1 > >> On 5 Dec 2022, at 10:17, Benjamin Lerer w

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 Kind Regards, Brandon On Mon, Dec 5, 2022 at 3:33 AM Mick Semb Wever wrote: > > > Proposing the test build of Cassandra 4.1.0 GA for release. > > sha1: b807f97b37933fac251020dbd949ee8ef245b158 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 > On 5 Dec 2022, at 10:17, Benjamin Lerer wrote: > > +1 > > Le lun. 5 déc. 2022 à 11:02, Berenguer Blasi > a écrit : >> +1 >> >> On 5/12/22 10:53, guo Maxwell wrote: >>> +1 >>> >>> Mick Semb Wever mailto:m...@apache.org>>于2022年12月5日 >>> 周一下午5:33写道：

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 Le lun. 5 déc. 2022 à 11:02, Berenguer Blasi a écrit : > +1 > On 5/12/22 10:53, guo Maxwell wrote: > > +1 > > Mick Semb Wever 于2022年12月5日 周一下午5:33写道： > >> >> Proposing the test build of Cassandra 4.1.0 GA for release. >> >> sha1: b807f97b37933fac251020dbd949ee8ef245b158 >> Git: >> https://git

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Thanks for opening this thread Josh, It seems perfectly normal to me that for important changes or questions we raise some discussion to the mailing list. My understanding of the current proposal implies that for the 4.1 release we should have had to raise over 70 discussion threads. We have a m

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 On 5/12/22 10:53, guo Maxwell wrote: +1 Mick Semb Wever 于2022年12月5日 周一下午5:33写道： Proposing the test build of Cassandra 4.1.0 GA for release. sha1: b807f97b37933fac251020dbd949ee8ef245b158 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 Mick Semb Wever 于2022年12月5日 周一下午5:33写道： > > Proposing the test build of Cassandra 4.1.0 GA for release. > > sha1: b807f97b37933fac251020dbd949ee8ef245b158 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative > Maven Artifacts: > https://repository

[VOTE] Release Apache Cassandra 4.1.0 GA

Proposing the test build of Cassandra 4.1.0 GA for release. sha1: b807f97b37933fac251020dbd949ee8ef245b158 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1281/org