Re: [VOTE] Release dtest-api 0.0.14
+1 On Tue, 16 May 2023 at 07:24, Alex Petrov wrote: > +1 > > On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote: > > +1 (nb) > > Doug Rohrer > > > On May 15, 2023, at 7:17 PM, Brandon Williams wrote: > > > > +1 > > > > Kind Regards, > > Brandon > > > >> On Mon, May 15, 2023 at 5:12 PM Dinesh Joshi wrote: > >> > >> Proposing the test build of in-jvm dtest API 0.0.14 for release. > >> > >> Repository: > >> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git > >> > >> Candidate SHA: > >> > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32 > >> tagged with 0.0.14 > >> > >> Artifacts: > >> > https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/ > >> > >> Key signature: 53371F9B1B425A336988B6A03B6042413D323470 > >> > >> Changes since last release: > >> > >> * CASSANDRA-18511: Add support for JMX in jvm-dtest > >> > >> The vote will be open for 24 hours. Everyone who has tested the build > >> is invited to vote. Votes by PMC members are considered binding. A > >> vote passes if there are at least three binding +1s. > >
Re: Cassandra 4.0-beta1 available on FreeBSD
Now updated to 4.0.8! 🎉 (yes, I know, 4.0.9 was released during the process…) Next step will be to upgrade to 4.1. cheers, Lapo On 2020-07-27 19:28, Ekaterina Dimitrova wrote: Thank you Angelo for supporting the project with this! Truly appreciate it! Best, Ekaterina On Mon, 27 Jul 2020 at 13:13, Angelo Polo wrote: Cassandra 4.0-beta1 is now available on FreeBSD. You can find information about the port here: https://www.freshports.org/databases/cassandra4/ The beta can be installed from an up-to-date ports tree under databases/cassandra4. Best, Angelo
Re: Cassandra 4.0-beta1 available on FreeBSD
Great stuff, Lapo! I was looking into FreeBSD ports few days ago to see what Cassandra version it supports as I have BSDs as a hobby ... Can't wait until I see 4.1! BTW I noticed there is quite a lot of patches to make Cassandra run on FreeBSD (1). Would you be maybe interesting in submitting patches for changes you did (when applicable) so you do not need to patch it yourself in your port? (1) https://cgit.freebsd.org/ports/tree/databases/cassandra4/files Regards From: Lapo Luchini Sent: Tuesday, May 16, 2023 13:05 To: dev@cassandra.apache.org Subject: Re: Cassandra 4.0-beta1 available on FreeBSD NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. Now updated to 4.0.8! 🎉 (yes, I know, 4.0.9 was released during the process…) Next step will be to upgrade to 4.1. cheers, Lapo On 2020-07-27 19:28, Ekaterina Dimitrova wrote: > Thank you Angelo for supporting the project with this! Truly appreciate it! > > Best, > Ekaterina > > On Mon, 27 Jul 2020 at 13:13, Angelo Polo wrote: > >> Cassandra 4.0-beta1 is now available on FreeBSD. >> >> You can find information about the port here: >> https://www.freshports.org/databases/cassandra4/ >> >> The beta can be installed from an up-to-date ports tree under >> databases/cassandra4. >> >> Best, >> Angelo
Re: [VOTE] Release dtest-api 0.0.14
+1 On Tue, May 16, 2023 at 3:39 AM Andrés de la Peña wrote: > +1 > > On Tue, 16 May 2023 at 07:24, Alex Petrov wrote: > >> +1 >> >> On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote: >> >> +1 (nb) >> >> Doug Rohrer >> >> > On May 15, 2023, at 7:17 PM, Brandon Williams wrote: >> > >> > +1 >> > >> > Kind Regards, >> > Brandon >> > >> >> On Mon, May 15, 2023 at 5:12 PM Dinesh Joshi >> wrote: >> >> >> >> Proposing the test build of in-jvm dtest API 0.0.14 for release. >> >> >> >> Repository: >> >> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git >> >> >> >> Candidate SHA: >> >> >> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32 >> >> tagged with 0.0.14 >> >> >> >> Artifacts: >> >> >> https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/ >> >> >> >> Key signature: 53371F9B1B425A336988B6A03B6042413D323470 >> >> >> >> Changes since last release: >> >> >> >> * CASSANDRA-18511: Add support for JMX in jvm-dtest >> >> >> >> The vote will be open for 24 hours. Everyone who has tested the build >> >> is invited to vote. Votes by PMC members are considered binding. A >> >> vote passes if there are at least three binding +1s. >> >>
Re: [DISCUSS] The future of CREATE INDEX
I might as well weigh in... [POLL] Centralize existing syntax or create new syntax? 1.) CREATE INDEX ... USING ... WITH OPTIONS... (I think the more important protection for users WRT local indexes should come in the form of a guardrail prohibiting scatter/gather queries against them.) [POLL] Should there be a default? (YES/NO) Yes [POLL] What do do with the default? 3.) and 4.) Allow both configuring a default and disabling the default concept entirely. (Both of these are creation-time items, just like the current guardrails we have around 2i creation and SASI disabling.) (No defaults should change, but administrators can lock this down/change the default index without much effort.) On Mon, May 15, 2023 at 10:52 PM guo Maxwell wrote: > [POLL] Centralize existing syntax or create new syntax? > > > 1.) CREATE INDEX ... USING WITH OPTIONS... > > and I think we should keep CREATE CUSTOM INDEX > > [POLL] Should there be a default? (YES/NO) > > > of course YES > > [POLL] What do do with the default? > > > 4.) YAML config/guardrail to require index type selection (not required by > default) > > > > Jonathan Ellis 于2023年5月16日周二 07:18写道: > >> On Fri, May 12, 2023 at 1:39 PM Caleb Rackliffe >> wrote: >> >>> [POLL] Centralize existing syntax or create new syntax? >>> >> >> 1 (Existing) >> >> [POLL] Should there be a default? (YES/NO) >>> >> >> YES >> >> >>> [POLL] What do do with the default? >>> >> >> 1 (Default SAI) >> >> > > > -- > you are the apple of my eye ! >
[DISCUSS] Bring cassandra-harry in tree as a submodule
Similar to what we've done with accord in https://issues.apache.org/jira/browse/CASSANDRA-18204, I'd like to discuss bringing cassandra-harry in-tree as a submodule. repo link: https://github.com/apache/cassandra-harry Given the value it's brought to the project's stabilization efforts and the movement of other things in the ecosystem to being more integrated (accord, build-scripts https://issues.apache.org/jira/browse/CASSANDRA-18133), I think having the testing framework better localized and integrated would be a net benefit for adoption, awareness, maintenance, and tighter workflows as we troubleshoot future failures it surfaces. I'd also like to see us get a Harry run integrated as part of our pre-commit CI (a 5 minute simple soak test for instance) and having that local in this fashion should make that a cleaner integration as well. Thoughts?
Re: [DISCUSS] Bring cassandra-harry in tree as a submodule
Just to make sure I'm understanding the details, this would mean apache/cassandra-harry maintains its status as a separate repository, apache/cassandra references it as a submodule, and clones and builds Harry locally, rather than pulling a released JAR. We can then reference Harry as a library without maintaining public artifacts for it. Is that in line with what you're thinking? > I'd also like to see us get a Harry run integrated as part of our pre-commit > CI I'm a strong supporter of this, of course. > On May 16, 2023, at 11:03 AM, Josh McKenzie wrote: > > Similar to what we've done with accord in > https://issues.apache.org/jira/browse/CASSANDRA-18204, I'd like to discuss > bringing cassandra-harry in-tree as a submodule. repo link: > https://github.com/apache/cassandra-harry > > Given the value it's brought to the project's stabilization efforts and the > movement of other things in the ecosystem to being more integrated (accord, > build-scripts https://issues.apache.org/jira/browse/CASSANDRA-18133), I think > having the testing framework better localized and integrated would be a net > benefit for adoption, awareness, maintenance, and tighter workflows as we > troubleshoot future failures it surfaces. > > I'd also like to see us get a Harry run integrated as part of our pre-commit > CI (a 5 minute simple soak test for instance) and having that local in this > fashion should make that a cleaner integration as well. > > Thoughts?
[DISCUSS] Feature branch version hygiene
Process question/discussion. Should tickets that are merged to CEP feature branches, like https://issues.apache.org/jira/browse/CASSANDRA-18204, have a fixver of 5.0 on them After merging to the feature branch? For the SAI CEP which is also using the feature branch method the "reviewed and merged to feature branch" tickets seem to be given a version of NA. Not sure that's the best “waiting for cep to merge” version either? But it seems better than putting 5.0 on them to me. Why I’m not keen on 5.0 is because if we cut the release today those tickets would not be there. What do other people think? Is there a better version designation we can use? On a different project I have in the past made a “version number” in JIRA for each long running feature branch. Tickets merged to the feature branch got the epic ticket number as their version, and then it got updated to the “real” version when the feature branch was merged to trunk. -Jeremiah
Re: [DISCUSS] Feature branch version hygiene
Copying my rely on the ticket… We have this discussion roughly once per major. If you look back through dev@ you'll find the last one a few years back. I don't recall NA ever being the approved approach, though. ".x" lines are target versions, whereas concrete versions are the ones a fix landed in. There's always ambiguity over the next release, as it's sort of both. But since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0, perhaps 5.0 is the correct label (and makes sense to me). I forget what we landed upon last time. Work that has actually landed should probably be labelled as 5.0-alpha1 > On 16 May 2023, at 21:02, J. D. Jordan wrote: > > > Process question/discussion. Should tickets that are merged to CEP feature > branches, like https://issues.apache.org/jira/browse/CASSANDRA-18204, have a > fixver of 5.0 on them After merging to the feature branch? > > For the SAI CEP which is also using the feature branch method the "reviewed > and merged to feature branch" tickets seem to be given a version of NA. > > Not sure that's the best “waiting for cep to merge” version either? But it > seems better than putting 5.0 on them to me. > > Why I’m not keen on 5.0 is because if we cut the release today those tickets > would not be there. > > What do other people think? Is there a better version designation we can use? > > On a different project I have in the past made a “version number” in JIRA for > each long running feature branch. Tickets merged to the feature branch got > the epic ticket number as their version, and then it got updated to the > “real” version when the feature branch was merged to trunk. > > -Jeremiah
Re: [DISCUSS] Feature branch version hygiene
I like the NA approach for sub-tasks that roll up to a parent/epic ticket. When that lands, it gets a real version, and any sub-task is assumed to also have that version. Not that it has to be called "NA", but there should be something to denote "inherits from parent". On Tue, May 16, 2023 at 3:04 PM Benedict wrote: > Copying my rely on the ticket… > > > We have this discussion roughly once per major. If you look back through > dev@ you'll find the last one a few years back. > > I don't recall NA ever being the approved approach, though. ".x" lines are > target versions, whereas concrete versions are the ones a fix landed in. > There's always ambiguity over the next release, as it's sort of both. But > since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0, > perhaps 5.0 is the correct label (and makes sense to me). I forget what we > landed upon last time. > > Work that has actually landed should probably be labelled as 5.0-alpha1 > > On 16 May 2023, at 21:02, J. D. Jordan wrote: > > > > Process question/discussion. Should tickets that are merged to CEP feature > branches, like https://issues.apache.org/jira/browse/CASSANDRA-18204, have > a fixver of 5.0 on them After merging to the feature branch? > > > For the SAI CEP which is also using the feature branch method the > "reviewed and merged to feature branch" tickets seem to be given a version > of NA. > > > Not sure that's the best “waiting for cep to merge” version either? But > it seems better than putting 5.0 on them to me. > > > Why I’m not keen on 5.0 is because if we cut the release today those > tickets would not be there. > > > What do other people think? Is there a better version designation we can > use? > > > On a different project I have in the past made a “version number” in JIRA > for each long running feature branch. Tickets merged to the feature branch > got the epic ticket number as their version, and then it got updated to the > “real” version when the feature branch was merged to trunk. > > > -Jeremiah > >
Re: [DISCUSS] Feature branch version hygiene
...but that and "What do we do with things that might be in 5.0 and might not?" are different questions. A version that denotes "next major release" until merged (at which point it could be given a real version) could be helpful... On Tue, May 16, 2023 at 3:28 PM Caleb Rackliffe wrote: > I like the NA approach for sub-tasks that roll up to a parent/epic ticket. > When that lands, it gets a real version, and any sub-task is assumed to > also have that version. > > Not that it has to be called "NA", but there should be something to denote > "inherits from parent". > > On Tue, May 16, 2023 at 3:04 PM Benedict wrote: > >> Copying my rely on the ticket… >> >> >> We have this discussion roughly once per major. If you look back through >> dev@ you'll find the last one a few years back. >> >> I don't recall NA ever being the approved approach, though. ".x" lines >> are target versions, whereas concrete versions are the ones a fix landed >> in. There's always ambiguity over the next release, as it's sort of both. >> But since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0, >> perhaps 5.0 is the correct label (and makes sense to me). I forget what we >> landed upon last time. >> >> Work that has actually landed should probably be labelled as 5.0-alpha1 >> >> On 16 May 2023, at 21:02, J. D. Jordan wrote: >> >> >> >> Process question/discussion. Should tickets that are merged to CEP >> feature branches, like >> https://issues.apache.org/jira/browse/CASSANDRA-18204, have a fixver of >> 5.0 on them After merging to the feature branch? >> >> >> For the SAI CEP which is also using the feature branch method the >> "reviewed and merged to feature branch" tickets seem to be given a version >> of NA. >> >> >> Not sure that's the best “waiting for cep to merge” version either? But >> it seems better than putting 5.0 on them to me. >> >> >> Why I’m not keen on 5.0 is because if we cut the release today those >> tickets would not be there. >> >> >> What do other people think? Is there a better version designation we can >> use? >> >> >> On a different project I have in the past made a “version number” in JIRA >> for each long running feature branch. Tickets merged to the feature branch >> got the epic ticket number as their version, and then it got updated to the >> “real” version when the feature branch was merged to trunk. >> >> >> -Jeremiah >> >>
Re: [DISCUSS] Feature branch version hygiene
I do not think we discussed it from feature branch perspective. (Happy to stand corrected but I did not find anything in @dev archive myself) But we do mark with 5.0 anything that lands in trunk. I think it might be a good idea anything that lands in a feature branch to have different fix version until the feature branch is merged. “ Why I’m not keen on 5.0 is because if we cut the release today those tickets would not be there.” I guess it can make it easier also from Release Management process as if I remember correctly there is a script that changes potentially all tickets resolved with major version (in this case 5.0) to 5.0-alpha or whatever we stop on to be the release version. Though NA can be confusing I guess. Shall we use something like 5.0-candidate, 6.0-candidate? This can be based on the confidence people have around a feature branch, where it can potentially land. I am curious how other projects do it too. I think it is a good call to decide on something and document it. I can imagine it will be also easier during release management. Thank you Jeremiah for raising the topic Best regards, Ekaterina On Tue, 16 May 2023 at 16:04, Benedict wrote: > Copying my rely on the ticket… > > > We have this discussion roughly once per major. If you look back through > dev@ you'll find the last one a few years back. > > I don't recall NA ever being the approved approach, though. ".x" lines are > target versions, whereas concrete versions are the ones a fix landed in. > There's always ambiguity over the next release, as it's sort of both. But > since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0, > perhaps 5.0 is the correct label (and makes sense to me). I forget what we > landed upon last time. > > Work that has actually landed should probably be labelled as 5.0-alpha1 > > On 16 May 2023, at 21:02, J. D. Jordan wrote: > > > > Process question/discussion. Should tickets that are merged to CEP feature > branches, like https://issues.apache.org/jira/browse/CASSANDRA-18204, have > a fixver of 5.0 on them After merging to the feature branch? > > > For the SAI CEP which is also using the feature branch method the > "reviewed and merged to feature branch" tickets seem to be given a version > of NA. > > > Not sure that's the best “waiting for cep to merge” version either? But > it seems better than putting 5.0 on them to me. > > > Why I’m not keen on 5.0 is because if we cut the release today those > tickets would not be there. > > > What do other people think? Is there a better version designation we can > use? > > > On a different project I have in the past made a “version number” in JIRA > for each long running feature branch. Tickets merged to the feature branch > got the epic ticket number as their version, and then it got updated to the > “real” version when the feature branch was merged to trunk. > > > -Jeremiah > >
Re: [DISCUSS] Bring cassandra-harry in tree as a submodule
I think it would be great to onboard Harry more officially into the project. However it would be nice to perhaps do some sanity checking outside of Apple folks to see how approachable it is. That is, can someone take it and just run it with the current readme without any additional context? I wonder if a mini-onboarding session would be good as a community session - go over Harry, how to run it, how to add a test? Would that be the right venue? I just would like to see how we can not only plug it in to regular CI but get everyone that wants to add a test be able to know how to get started with it. Jeremy > On May 16, 2023, at 1:34 PM, Abe Ratnofsky wrote: > > Just to make sure I'm understanding the details, this would mean > apache/cassandra-harry maintains its status as a separate repository, > apache/cassandra references it as a submodule, and clones and builds Harry > locally, rather than pulling a released JAR. We can then reference Harry as a > library without maintaining public artifacts for it. Is that in line with > what you're thinking? > > > I'd also like to see us get a Harry run integrated as part of our > > pre-commit CI > > I'm a strong supporter of this, of course. > >> On May 16, 2023, at 11:03 AM, Josh McKenzie wrote: >> >> Similar to what we've done with accord in >> https://issues.apache.org/jira/browse/CASSANDRA-18204, I'd like to discuss >> bringing cassandra-harry in-tree as a submodule. repo link: >> https://github.com/apache/cassandra-harry >> >> Given the value it's brought to the project's stabilization efforts and the >> movement of other things in the ecosystem to being more integrated (accord, >> build-scripts https://issues.apache.org/jira/browse/CASSANDRA-18133), I >> think having the testing framework better localized and integrated would be >> a net benefit for adoption, awareness, maintenance, and tighter workflows as >> we troubleshoot future failures it surfaces. >> >> I'd also like to see us get a Harry run integrated as part of our pre-commit >> CI (a 5 minute simple soak test for instance) and having that local in this >> fashion should make that a cleaner integration as well. >> >> Thoughts? >
Re: [VOTE] Release dtest-api 0.0.14
Vote passes with 7 +1s and no -1s. thanks everybody. On 5/15/23 15:12, Dinesh Joshi wrote: > Proposing the test build of in-jvm dtest API 0.0.14 for release. > > Repository: > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git > > Candidate SHA: > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32 > tagged with 0.0.14 > > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/ > > Key signature: 53371F9B1B425A336988B6A03B6042413D323470 > > Changes since last release: > > * CASSANDRA-18511: Add support for JMX in jvm-dtest > > The vote will be open for 24 hours. Everyone who has tested the build > is invited to vote. Votes by PMC members are considered binding. A > vote passes if there are at least three binding +1s.