Re: [DISCUSSION] CASSANDRA-19001 - JRE vs JDK runtime
> jdk. attach is needed for nodetool sjk hh. When someone tries to use > that command, they get an error that JDK is expected. There isn't > anything to do about that here. Given we have functionality that depends on a JDK, and all our testing is done with a JDK, I'm in favour of printing a warning that JDK is recommended, from 5.0 onwards. And before 5.0 just leaving things in the state they are in. This is a problem with the dockerhub images, and our debian and redhat packages. 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 stating compatibility with JRE is unknown (referencing the jira issue), and - add the jdk add-opens and add-exports only when jdk is detected (javac is on path). And, is debugging info is of concern here ? i.e. if debug info is only in the JDK's jvm and it is valuable to us (over any perf diff), then we have reason to recommend the jdk.
Re: Switching the website to a temporary static html version of the new design
> tl;dr Can we switch the website over to a temporary static-html > version of the new design, while work on the final antora generated > version continues? done. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Switching the website to a temporary static html version of the new design
> is this version of the web page already "analytics friendly"? In the > context of https://plausible.cassandra.apache.org/cassandra.apache.org It is! it is still getting hacked in, but it will soon be formally part of the design and website generation. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Switching the website to a temporary static html version of the new design
> As a risk mitigator, I was hoping we could preserve > the sub-URIs so the switch doesn't impact current users: > - make sure /doc/3.11/ (and other supported versions) still works > - rename /doc/latest/ to /doc/4.0/ but pointing to the existing version of > the site just to be sure we have a workaround in place. Cheers! > That for mentioning that. It's been re-added. https://cassandra.staged.apache.org/doc/3.11/ And '/doc/4.0/' will get added soon! - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)
> The vote will be open for 72 hours (longer if needed). 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 and no -1's. +1 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: building trunk, and switching branches, with lib/ removed from trunk, and offline mode…
> Actually, I am not completely sure if Maven wrapper will play nicely > with Ant stuff of yours as maybe it indeed looks for "mvn" on path and > wrapper is invoked differently so it does not have to necessarily see > it. I ll check it and let you know. I misunderstood you Stefan. If you would like to contribute a patch that replaces the three invocations of "`mvn` on the path", with a calls to `./.build/mvnw …` that would be appreciated, and indeed it would strength the build for machines that don't have maven installed. https://github.com/apache/cassandra/blob/trunk/.build/build-resolver.xml#L137-L160 regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Cassandra 4.0 Status 2021-02-25
> * We’re within line-of-sight to closing out beta scope. Any work people can > do on remaining blockers will accelerate the project toward RC. So, last call for last minute concerns, the plan is to cut 4.0-rc1 once - those beta tickets are resolved, - the gremlins around v5 native protocol (+python driver frames) are fixed, and - we see one clean CI run Which looks like it might happen next week. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Releases after 4.0
> I believe that there is an appetite for the bleeding edge snapshots where > we do not guarantee stability and that the semver discussion is not > finished yet but I would like us to let those discussions go for some > follow up threads. > My goal with this thread was to reach an agreement on a release cadence for > the version we will officially support after 4.0. > > My impression is that most people agree with *one release every year* so I > would like to propose it as our future release cadence. > +1 to branching off one release branch a year. Are we also trying to reach a consensus here that a release branch should be supported for ~3 years (i.e. that we are aiming to limit ourselves to 3 release branches plus trunk)? +1 to flexible dates. +1 to non-GA non-branched releases along the way. Jeremiah, I have nothing to add to your post. I think you did a fantastic job of combining how semver would work in combination Benedict's focus on cadence and reducing the community burden. It also helped highlight the different discussions to be had, that should be had separately. Thanks Benjamin for bringing it back to what was your original questions (sorry for the derail): > 1) What release cadence do we want to use for major/minor versions? > 2) How do we plan to ensure the quality of the releases? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Upgrade chronicle-queue version from 4 to 5
> An entry in NEWS.txt will be added. I've skipped the NEWS.txt entry, as we don't do alpha|beta upgrade sections. I should have checked that earlier. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Upgrade chronicle-queue version from 4 to 5
> I would like to request an exception to the Beta release to get the > upgrade in place and to support arm64. Does anyone have any objection > or concern to the upgrade? An entry in NEWS.txt will be added. Thanks Jeff, Marcus, Brandon. I will merge CASSANDRA-16384 and CASSANDRA-16392 today. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Removal of third-party plug-ins doc page
> Should this page be removed from at least the Cassandra 4.0 documentation? > Neither seems to have been updated beyond C* 3.0. Good idea Lorina. Do please remove it. We have now https://cassandra.apache.org/third-party/ anyway. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Upgrade chronicle-queue version from 4 to 5
> Do you happen to know if there is any documentation impact to the change? Not that I can see. Neither of these page make reference about the minimal chronicle-queue versions required - https://cassandra.apache.org/doc/latest/new/auditlogging.html - https://cassandra.apache.org/doc/latest/new/fqllogging.html - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 4.0-beta4
> The vote will be open for 72 hours (longer if needed). 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 and no -1's. The vote has passed with 3 binding and 3 non-binding +1s. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
Done. Thanks! On 2020/12/17 10:57:35, Benjamin Lerer wrote: > Thanks Mick for raising that problem. Effectively, I got confused along the > way. > > +1 > > On Thu, Dec 17, 2020 at 11:56 AM Sam Tunnicliffe wrote: > > > > > > > > On 17 Dec 2020, at 10:54, Michael Semb Wever wrote: > > > > > > > > >> I propose to: > > >> > > >> - update the documentation to clarify the meaning of the fix version > > as > > >> 'The version in which the item must be fixed' (e.g 4.0-beta if the > > ticket > > >> must be fixed in a beta release) > > >> - create a 4.0-GA fix version and use it for the Quality testing > > tickets > > >> - Start a discussion beginning of January to discuss the scope of > > those > > >> tickets > > >> > > >> If you disagree on any of the points do not hesitate to raise your > > concerns > > > > > > > > > Even though we have gone ahead and created the `4.0-GA` label, and have > > already moved the Quality testing tickets to it, I do think we have made a > > small mistake here… > > > > > > What would the difference between `4.0-rc` and `4.0-GA` be? > > > > > > If `4.0-beta` is a "Placeholder for blockers to 4.0-rc1", > > > then `4.0-rc` would be a "Placeholder for blockers to 4.0.0", > > > so then what is `4.0-GA` ? > > > > > > This was half-documented in the fixVersion descriptions here > > > > > https://issues.apache.org/jira/projects/CASSANDRA?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page=unreleased > > > (`4.0-rc` did fail to have any useful description). > > > > > > Can I suggest we move all `4.0-GA` to `4.0-rc`, and delete `4.0-GA` ? > > > > > > > +1 > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
> I propose to: > >- update the documentation to clarify the meaning of the fix version as >'The version in which the item must be fixed' (e.g 4.0-beta if the ticket >must be fixed in a beta release) >- create a 4.0-GA fix version and use it for the Quality testing tickets >- Start a discussion beginning of January to discuss the scope of those >tickets > > If you disagree on any of the points do not hesitate to raise your concerns Even though we have gone ahead and created the `4.0-GA` label, and have already moved the Quality testing tickets to it, I do think we have made a small mistake here… What would the difference between `4.0-rc` and `4.0-GA` be? If `4.0-beta` is a "Placeholder for blockers to 4.0-rc1", then `4.0-rc` would be a "Placeholder for blockers to 4.0.0", so then what is `4.0-GA` ? This was half-documented in the fixVersion descriptions here https://issues.apache.org/jira/projects/CASSANDRA?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page=unreleased (`4.0-rc` did fail to have any useful description). Can I suggest we move all `4.0-GA` to `4.0-rc`, and delete `4.0-GA` ? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
> Do we want them fixed before we release 4.0-RC or are they part of the > testing of the RC release? We are so unbearably close, it would be nice to see the beta tickets narrowed (again) to just the most critical issues. Tickets about creating new tests, and bugs edge-case, or not severe or have an easy-enough workaround, don't need to block a RC release IMHO. Just like they don't block a patch release when there's other stuff that's important to roll out. The testing epics tickets too i would think can continue to roll on during RC. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance
> Benedict suggested that Sylvain and I made the choice. Sylvain did not want > to make the final call. > I chose correctness. If it is a problem and people prefer to vote. It is > perfectly fine for me too :-) +1 Appreciate it having been raised for exposure and discussion Benjamin, and happy to leave the final say to those carrying the work on, especially in this case :-) - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance
> Regarding CASSANDRA-12126 and 4.0 we are facing several options and > Benedict, Sylvain and I wanted to get the community feedback on them. > > We can: > >1. Try to use Benedict proposal for 4.0 if the community has the >appetite for it. The main issue there is some potential extra delay for 4.0 >2. Do nothing for 4.0. Meaning do not commit the current patch. We have >lived a long time with that issue and we can probably wait a bit more for a >proper solution. >3. Commit the patch as such, fixing the correctness but introducing >potentially some performance issue until we release a better solution. >4. Changing the patch to default to the current behavior but allowing >people to enable the new one if the correctness is a problem for them. > If these options are for 4.0, is it then (4) that it is getting applied to 3.0 and 3.11 ? If that is the case then I would vote on also applying (4) to 4.0, given we are now in front of beta4. Please let's not further delay 4.0. Post 4.0, if (1) is as described "a parallel implementation of the same underlying Paxos algorithm" can it also pluggable (either opt-in or opt-out)? And would/could EPaxos become pluggable too in a similar manner (if it eventuates)? I'm in favour on providing more pluggable interfaces into C*, along with the code quality improvements that's going to have to be accompanied with. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 3.0.22
On 2020/08/31 17:13:17, Mick Semb Wever wrote: > > > > This vote has passed, after 72 hours, with three binding +67s, and no > > -1s. > > > > > *7* binding +1s (ok, third time lucky…) This vote has passed, after 72 hours, with eight binding +1s, and no -1s. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 4.0-beta2
On 2020/08/31 17:07:19, Mick Semb Wever wrote: > > > > > > The vote will be open for 72 hours (longer if needed). 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 and no -1's. > > > > > This vote has passed, after 72 hours, with three binding +7s, one > non-binding +1 and no -1s. Let me try that again! :-) This vote has passed, after 72 hours, with eight binding +1s, one non-binding +1, and no -1s. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 3.11.8
On 2020/08/31 16:59:18, Mick Semb Wever wrote: > > > > > > The vote will be open for 72 hours (longer if needed). 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 and no -1's. > > > > > This vote has passed, after 72 hours, with three binding +7s, one > non-binding +1, and no -1s. Let me try that again! :-) This vote has passed, after 72 hours, with eight binding +1s, one non-binding +1, and no -1s. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 2.2.18
On 2020/08/31 16:57:32, Mick Semb Wever wrote: > > > > The vote will be open for 72 hours (longer if needed). 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 and no -1's. > > > > > This vote has passed, after 72 hours, with three binding +7s, and no -1s. Let me try that again! :-) This vote has passed, after 72 hours, with eight binding +1s, and no -1s. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 2.1.22
> > The vote will be open for 72 hours (longer if needed). 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 and no -1's. > > > > > This vote has passed, after 72 hours, with three binding +6s, and no -1s. Let me try that again! (just keep laughing Jeff) :-) This vote has passed, after 72 hours, with seven binding +1s, and no -1s. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Feedback request on minor JMX interface incompatibility for CASSANDRA-15937
> I think the pragmatic thing to do is fix it now, and I'd strongly > prefer to do that but wanted to check if there are any objections or > things I hadn't considered? +1 Thanks for giving this visibility and demonstrating we are serious about the beta test cycle. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Updating the C* website design
> See that here: > https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing > > This outline is not complete, just my initial scribblings. Certainly > collaboration would be welcome. This is awesome Lorina. It would also be great to see all non-versioned docs moved out of the cassandra repository and into the cassandra-website repository (where they become easier to update). - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Updating the companies listed on the home page as C* users
On 2020/07/15 21:58:52, Lorina Poland wrote: > While creating a third-party page (CASSANDRA-15940), I decided to check the > links in the Proven block on the home page Closing the loop on this… completed and the website updated under CASSANDRA-15964. Thanks Lorina! - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Builds email notifications
After breaking the builds on 3.11 (a clumsy oversight, mea culpa, and a big thanks to Paulo and Robert for fixing it so quickly), it's been kinda bugging me that we don't send out build failure email notifications. Jenkins does have this functionality: with "E-mail Notification" configuration under the "Post-build Actions" section. Emails are sent when a build fails, becomes unstable or returns to stable, to a specified ML and the authors of the breakage. Is there any objection if I configure this for our `cassandra-*-artifacts` builds? And if I create a builds@ ML where these get cc'd? (It would be nice to add the configuration to the `cassandra-*-test` builds as well, but none of them are green. Maybe if they get green…?) regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
