[DISCUSS] Next release cut
Hi everybody, I believe that we never really clarified when the next release should happen. We agreed on a yearly frequency but did not go down on the details. It might be worth it to clarify them so that we are sure that everybody is on the same line. We cut 4.0 in May and released it in July. It is difficult to plan for a release date so we should probably agree on the cut date. One year after 4.0 that would make us cut the new branch in May. Does it match your expectations or are there any concerns?
Re: [DISCUSS] Next release cut
> We cut 4.0 in May and released it in July. It is difficult to plan for a release date so we should probably agree on the cut date. One year after 4.0 that would make us cut the new branch in May. This makes sense to me. The time between each rc1 cut is the only thing we control. We want the rc1 cut to GA published time frame to be minimised (that is the goal of stable-trunk) but that it is a variable, and not something we want to put pressure on or compromise. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Next release cut
+1 to cut 4.1 in May. It would be great to attain the yearly cut cadence if possible. Em ter., 14 de dez. de 2021 às 09:45, Mick Semb Wever escreveu: > > We cut 4.0 in May and released it in July. It is difficult to plan for a > release date so we should probably agree on the cut date. One year after > 4.0 that would make us cut the new branch in May. > > > This makes sense to me. The time between each rc1 cut is the only > thing we control. We want the rc1 cut to GA published time frame to be > minimised (that is the goal of stable-trunk) but that it is a > variable, and not something we want to put pressure on or compromise. > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Releasable trunk and quality
> > Merge commits aren’t that useful > I keep coming back to this. Arguably the only benefit they offer now is procedurally forcing us to not miss a bugfix on a branch, but given how much we amend many things presently anyway that dilutes that benefit. Having 1/3rd of your commit history be noise and/or things masking changes does more harm than good IMO. On Mon, Dec 13, 2021 at 9:51 AM bened...@apache.org wrote: > > It makes sense that such bug tickets are incentivised to be minimal, and > if there is a smarter way (improvement) in trunk that is a separate > follow-up ticket and patch > > Are you proposing separating the work entirely, so that we don’t merge up > to trunk at all, or do a no-op merge? Often things are done differently in > trunk (and intervening branches) for a combination of reasons, including > that the landscape has changed so that the earlier approach is > inapplicable. Either way, what you are proposing sounds like introducing > unnecessary additional work? > > > and that we have a more concise git history (one ~third the merge > commits). > > Don’t we get a more concise history with the cherry-pick approach, since > we don’t have any of the merge commits from each prior branch? Today, a > merge commit from 2.2 will accumulate four merge commits on the way to > trunk. > > My view: > > * Merge commits aren’t that useful > * It is a bad idea to have a different CI pipeline for multi-version > development > * It is particularly not worth countenancing solely to retain the > limited utility of merge commits > > > > From: Mick Semb Wever > Date: Sunday, 12 December 2021 at 11:47 > To: dev@cassandra.apache.org > Subject: Re: [DISCUSS] Releasable trunk and quality > > I find it cleaner that work is found associated to one sha on the hardest > > > branch, and we treat (or should be) CI holistically across branches. > > > > If we -s ours and amend merge commits on things that straddle stuff like > > 8099, MS rewrite, Simulator, guardrails, etc, then we have multiple SHA > > where the impl for a thing took place and N of them (N being count of > newer > > branches than oldest where it applies) where they're hidden inside a > merge > > commit right? > > > > > That patches can be significantly different across branches is inavertible. > One original commit versus individual commits on each branch is a trade-off > between cleaner git history and github fancies with more direct commits. > Taking it further, patches to release branches should be as minimal as > possible. It makes sense that such bug tickets are incentivised to be > minimal, and if there is a smarter way (improvement) in trunk that is a > separate follow-up ticket and patch. > > So… I am willing to say (for now) that I like it that merge shas have the > connection to the original singular shas on the hardest branch, and that we > have a more concise git history (one ~third the merge commits). > > > > > Also, nothing's keeping us from treating CI holistically and pushing > > --atomic across multiple branches even if we don't have merge commits. > > That's just a procedural question we could agree on and adhere to. > > > > > Sure, but atomic is not the same: it's manual adherence and there's no > history/record of it. >
Cassandra project biweekly status update 2021-12-14
Happy Tuesday Morning and Afternoon, which is almost Monday! Benjamin took the time to put together a roadmap (Awesome!) for the next Cassandra release - check that out here: https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap [New contributors getting started] We have a seasonally calibrated set of new tickets to get started on - the Advent Calender! https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20labels%20%3D%20AdventCalendar2021%20. If you're new to the project, these are hand-curated tickets for you to dive into, and you can reach out in the #cassandra-dev channel on the-asf.slack.com asking for assistance from any of the 13 designated cassandra mentors to help you out! We have two other options for getting started if none of the above catch your fancy: Failing tests, or starter tickets we label "lhf" (low hanging fruit). Query for failing tests: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252 Query for unassigned starter tickets: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2160 We're holding steady at 22 JIRA tickets that are unassigned test failures. For unassigned lhf, we have 12 on the patch release (4.0.2) and 17 on the minor release (4.1.0), some of which are likely overlapping with the selected tickets from the Advent calendar above. Feel free to self-select from any of the above lists or reach out on slack if you want some guidance on where to get involved. No time like the present! [Dev list discussions in the past 14 days] https://lists.apache.org/list?dev@cassandra.apache.org:lte=2w: A highlight from the dev list in the past couple weeks and to reiterate here: Cassandra as of CASSANDRA-5883 uses logback for logging and is not vulnerable to the recently disclosed log4j vulnerability. To everyone who maintains other systems as well as Cassandra and is working through this unprecedented vulnerability, thank you for everything you do in working to keep everyone's information safe and secure. Claude Warren has an open question about building secondary indexes; anyone with expertise in that area with a few spare cycles, please reach out. https://lists.apache.org/thread/bo83pxzfy4m9h45m242b38o20c4fdsyz A discussion indicated consensus on backporting some changes to the 4.0 line for major improvements to behavior under contention when inserting on collections. Benjamin is carrying the torch on reviewing and porting these changes to 4.0. https://lists.apache.org/thread/f3dl7rfc2kv9f5r9pxzyz6zojsss81b9. While the changes are fairly extensive, this is in a well exercised area of the codebase and is expected to be a fairly safe, and needed, change on the 4.0 line. The last thing that comes to mind - I'd love to get more feedback on the topic of keeping a releasable trunk and our quality on the project. A lot of valuable things have come out of the discussion thus far and I'm working on a PR for those (script to simplify various circle CI operations and config changes, changes to web site around testing documentation, changes to wiki for build lead role), however the implications of our merge strategy discussion on our CI integration proved to be a point without a clear initial consensus. Curious to hear what other people think: https://lists.apache.org/thread/8xt4tqb3w4j3jyxj859o3vs8f5xjgqg8 [Tickets Closed in the past 14 days] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2175 For 4.0.2, test fixes and doc changes. Low drama, nothing major here. On 4.1.0, the ticket count closed is misleading (as is so often the case). Yifan introduced a new mechanism to CDC that'll allow for rolling the hard-links based on hitting cap rather than pushing exceptions back to the client if you hit saturation on CDC segments. Benedict merged in the CEP-10 Simulator changes so we can expect to see some interesting things showing up in the not-so-distant future regarding correctness on our system from the new testing paradigms this enables. Another big merge in the past two weeks was Guardrails for CEP-3 that Andres got in. There's a lot of movement on guardrail related tickets as well going on actively now; exciting to see this make it into the project. Last on this list - we've had repeated LEAK messages show up on resources, often from histograms being fragile and prone to overflow, that should hopefully be plugged by CASSANDRA-17174. The consequences of these LEAK messages are far lower than our historical resource leakage before Stefania and Benedict introduced these mechanisms as they're appropriately harvested on GC, but there is the possibility that resource handles will be held for extended durations in edge conditions if you see the LEAK DETECTED message show up in your logs. It's worth noting: any time you grab handles to resources that will eventually be cleaned up by a Transactional like LifecycleTransaction or any other non-try-wit
RE: Recent log4j vulnerability
Any thoughts what the logback folks have been filed here? https://jira.qos.ch/browse/LOGBACK-1591 Thanks! -Original Message- From: Brandon Williams Sent: Sonntag, 12. Dezember 2021 18:56 To: dev@cassandra.apache.org Subject: Recent log4j vulnerability I replied to a user- post about this, but thought it was worth repeating it here. In https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-5883&data=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7C8016a1aeed8c4589cbe408d9bd9a0920%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637749291586596208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0klDN4WmFkt876OCsXL%2FX%2FUXa%2FrsxmwCKFgmnP4Lctw%3D&reserved=0 you can see where Apache Cassandra never chose to use log4j2 (preferring logback instead), and thus is not, and has never been, vulnerable to this RCE. Kind Regards, Brandon - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org This email may contain confidential information. If it appears this message was sent to you by mistake, please let us know of the error. In this case, we also ask that you do not further forward the content and delete it. Thank you for your cooperation and understanding. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Recent log4j vulnerability
The POC seems to require the attacker be able to upload a file that overwrites the configuration, with hot reloading enabled. We do have hot reloading enabled but there's no inherent way to overwrite the config. That said with logback currently at 1.2.3 (in trunk), perhaps we should consider an upgrade for safety. On Tue, Dec 14, 2021 at 8:50 AM Steinmaurer, Thomas wrote: > > Any thoughts what the logback folks have been filed here? > https://jira.qos.ch/browse/LOGBACK-1591 > > Thanks! > > -Original Message- > From: Brandon Williams > Sent: Sonntag, 12. Dezember 2021 18:56 > To: dev@cassandra.apache.org > Subject: Recent log4j vulnerability > > I replied to a user- post about this, but thought it was worth repeating it > here. > > In > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-5883&data=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7C8016a1aeed8c4589cbe408d9bd9a0920%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637749291586596208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0klDN4WmFkt876OCsXL%2FX%2FUXa%2FrsxmwCKFgmnP4Lctw%3D&reserved=0 > you can see where Apache Cassandra never chose to use log4j2 (preferring > logback instead), and thus is not, and has never been, vulnerable to this RCE. > > Kind Regards, > Brandon > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > This email may contain confidential information. If it appears this message > was sent to you by mistake, please let us know of the error. In this case, we > also ask that you do not further forward the content and delete it. Thank you > for your cooperation and understanding. Dynatrace Austria GmbH (registration > number FN 91482h) is a company registered in Linz whose registered office is > at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20. > > - > 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: Recent log4j vulnerability
Doesn’t hurt to upgrade. But no exploit there as far as I can see? If someone can update your config files to point them to JNDI, you have worse problems than that. Like they can probably update your config files to just completely open up JMX access or what ever also. > On Dec 14, 2021, at 9:17 AM, Brandon Williams wrote: > > The POC seems to require the attacker be able to upload a file that > overwrites the configuration, with hot reloading enabled. We do have > hot reloading enabled but there's no inherent way to overwrite the > config. > > That said with logback currently at 1.2.3 (in trunk), perhaps we > should consider an upgrade for safety. > >> On Tue, Dec 14, 2021 at 8:50 AM Steinmaurer, Thomas >> wrote: >> >> Any thoughts what the logback folks have been filed here? >> https://jira.qos.ch/browse/LOGBACK-1591 >> >> Thanks! >> >> -Original Message- >> From: Brandon Williams >> Sent: Sonntag, 12. Dezember 2021 18:56 >> To: dev@cassandra.apache.org >> Subject: Recent log4j vulnerability >> >> I replied to a user- post about this, but thought it was worth repeating it >> here. >> >> In >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-5883&data=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7C8016a1aeed8c4589cbe408d9bd9a0920%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637749291586596208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0klDN4WmFkt876OCsXL%2FX%2FUXa%2FrsxmwCKFgmnP4Lctw%3D&reserved=0 >> you can see where Apache Cassandra never chose to use log4j2 (preferring >> logback instead), and thus is not, and has never been, vulnerable to this >> RCE. >> >> Kind Regards, >> Brandon >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> This email may contain confidential information. If it appears this message >> was sent to you by mistake, please let us know of the error. In this case, >> we also ask that you do not further forward the content and delete it. Thank >> you for your cooperation and understanding. Dynatrace Austria GmbH >> (registration number FN 91482h) is a company registered in Linz whose >> registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20. >> >> - >> 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: Recent log4j vulnerability
Would 3.11 be considered as well? This would also then keep (stupid/static) sec scans silent in regard to https://nvd.nist.gov/vuln/detail/CVE-2017-5929 Thanks -Original Message- From: J. D. Jordan Sent: Dienstag, 14. Dezember 2021 16:27 To: dev@cassandra.apache.org Subject: Re: Recent log4j vulnerability Doesn’t hurt to upgrade. But no exploit there as far as I can see? If someone can update your config files to point them to JNDI, you have worse problems than that. Like they can probably update your config files to just completely open up JMX access or what ever also. > On Dec 14, 2021, at 9:17 AM, Brandon Williams wrote: > > The POC seems to require the attacker be able to upload a file that > overwrites the configuration, with hot reloading enabled. We do have > hot reloading enabled but there's no inherent way to overwrite the > config. > > That said with logback currently at 1.2.3 (in trunk), perhaps we > should consider an upgrade for safety. > >> On Tue, Dec 14, 2021 at 8:50 AM Steinmaurer, Thomas >> wrote: >> >> Any thoughts what the logback folks have been filed here? >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjir >> a.qos.ch%2Fbrowse%2FLOGBACK-1591&data=04%7C01%7Cthomas.steinmaure >> r%40dynatrace.com%7C3c8fc229b1ae41d67d3908d9bf177d1a%7C70ebe3a35b3043 >> 5d9d677716d74ca190%7C1%7C0%7C637750929883113638%7CUnknown%7CTWFpbGZsb >> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D >> %7C3000&sdata=Y2uKdA2lBJui3eOgv6NxDsA4P3knHmQnKDQfHbJXjPY%3D& >> reserved=0 >> >> Thanks! >> >> -Original Message- >> From: Brandon Williams >> Sent: Sonntag, 12. Dezember 2021 18:56 >> To: dev@cassandra.apache.org >> Subject: Recent log4j vulnerability >> >> I replied to a user- post about this, but thought it was worth repeating it >> here. >> >> In >> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-5883&data=04%7C01%7Cthomas.steinmaurer%40dynatrace.com%7C3c8fc229b1ae41d67d3908d9bf177d1a%7C70ebe3a35b30435d9d677716d74ca190%7C1%7C0%7C637750929883113638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xNXgCyJwyqNmNQ375upcg5JK4cv%2F6up25btbVyqxqp8%3D&reserved=0 >> you can see where Apache Cassandra never chose to use log4j2 (preferring >> logback instead), and thus is not, and has never been, vulnerable to this >> RCE. >> >> Kind Regards, >> Brandon >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> This email may contain confidential information. If it appears this message >> was sent to you by mistake, please let us know of the error. In this case, >> we also ask that you do not further forward the content and delete it. Thank >> you for your cooperation and understanding. Dynatrace Austria GmbH >> (registration number FN 91482h) is a company registered in Linz whose >> registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20. >> >> - >> 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 This email may contain confidential information. If it appears this message was sent to you by mistake, please let us know of the error. In this case, we also ask that you do not further forward the content and delete it. Thank you for your cooperation and understanding. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSSION] Next release roadmap
Thanks Benjamin!I see that the Roadmap doc on Confluence contains several features that are large in scope but do not have a published CEP or discussion on the mailing list.Because users will treat the roadmap doc as indicative of the project’s direction and intent, can these items be moved to a section indicating that there is interest or that they are potential features pending proposal and discussion?I don't think it's a good idea to list features that haven't been discussed on a user-visible roadmap page, but wouldn't object to the idea of them being in a separate section.– ScottOn Dec 13, 2021, at 6:42 AM, Benjamin Lerer wrote:I finally wrote down the roadmap on the wiki, and updated it to reflect thecurrent situation (https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap)Sorry for the delay.Le lun. 24 mai 2021 à 19:44, Ekaterina Dimitrova aécrit :Thanks Paulo!The patch is available on github. It depends only on our availability andpriorities. I see Benedict mentioned on the ticket that probably 90% of thepatch covers already the idea of his proposal. I will be happy to finishthe work or if I am not available, when the time for it comes to handoverit to someone else.I can’t find the related ticket now but one of the jvm prerequisites weneeded is solved - to be able to load custom types.On Wed, 19 May 2021 at 5:04, Benjamin Lerer wrote:> Thanks Paulo. That one definitely fell through the cracks.>> I have been pretty busy lately but as soon as I have a bit of time I will> create a roadmap page to> summarize everything that was proposed so far. Including MakingSSLContext> creation pluggable proposed by Maulin and the JUnit 5 migration proposal> from Aleksei.>> Le mer. 19 mai 2021 à 01:48, Paulo Motta a> écrit :>> > I would love to see Ekaterina's work from CASSANDRA-15234 tostandardize> > configuration be resumed in the next releases.> >> > Thought it would be worth mentioning since we had quite a productive> > discussion before putting it on hold to focus on 4.0, so it would be> great> > to have that conversation resumed.> >> > Em seg., 26 de abr. de 2021 às 14:16, Benedict Elliott Smith <> > bened...@apache.org> escreveu:> >> > > I think my earlier response vanished into the moderator queue. Just a> few> > > comments:> > >> > > 1) The Paxos latency (and correctness) improvements I think shouldland> > in> > > 4.0.x, as we have introduced a fairly significant regression and this> > work> > > mostly resolves outstanding issues with LWTs today.> > > 2) If we aim to deliver multi-partition LWTs in 4.x/5.0, we maylikely> > > want to pair this with work to further reduce latency beyond theabove> > > work, as contention will become a more significant problem. Should Ibe> > > involved in delivering multi-partition LWTs I will also be aiming to> > > deliver even lower latencies for the release they land in.> > > 3) To support all of the above work, I also aim to deliver aSimulator> > > facility for deterministically executing cluster workloads under> > > adversarial scheduling (i.e. that intercepts all message and thread> > events> > > and evaluates them sequentially, in pseudorandom order), alongside> > > linearizability verification built upon this. This work will include> (or> > > have as a prerequisite) significant clean-ups to internalfunctionality> > > like executors, use of futures and other concurrency primitives, and> > > mocking out of time and the filesystem.> > >> > >> > > On 23/04/2021, 14:46, "Benjamin Lerer" wrote:> > >> > > Hi everybody,> > >> > > Thanks for all the responses. I went through the emails and> > aggregated> > > the> > > proposals to give us an idea on where we stand at this point.> > >> > > I only included the improvements in the list and left on the side> the> > > bug> > > fixes.> > > Regarding bug fixes, I wonder if we should not have discussions> every> > > month> > > to discuss what are the important issues that should be fixed in> > > priority.> > > I feel that we sometimes tend to forget old issues even if theyare> > > more> > > important than some new ones.> > >> > > Do not hesitate to tell me if I missed something ormisinterpreted> > some> > > proposal.> > >> > > *Query side improvements:*> > >> > > * Storage Attached Index or SAI. The CEP can be found at> > >> > >> >>https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-7%3A+Storage+Attached+Index> > > * Add support for OR predicates in the CQL where clause> > > * Allow to aggregate by time intervals (CASSANDRA-11871) and> allow> > > UDFs> > > in GROUP BY clause> > > * Ability to read the TTL and WRITE TIME of an element in a> > > collection> > > (CASSANDRA-8877)> > > * Multi-Partition LWTs> > > * Materialized views hardening: Addressing the different> > Materialized> > > Views issues (see CASSANDRA-15921 and [1] for some of the work> > > involved)> > >> > > *Security improvements:*> > >> > > * SSTa
Re: [DISCUSSION] Next release roadmap
Sure :-) I will make a separate section. Le mar. 14 déc. 2021 à 17:30, C. Scott Andreas a écrit : > Thanks Benjamin! > > I see that the Roadmap doc on Confluence contains several features that > are large in scope but do not have a published CEP or discussion on the > mailing list. > > Because users will treat the roadmap doc as indicative of the project’s > direction and intent, can these items be moved to a section indicating that > there is interest or that they are potential features pending proposal and > discussion? > > I don't think it's a good idea to list features that haven't been > discussed on a user-visible roadmap page, but wouldn't object to the idea > of them being in a separate section. > > – Scott > > On Dec 13, 2021, at 6:42 AM, Benjamin Lerer wrote: > > > I finally wrote down the roadmap on the wiki, and updated it to reflect the > current situation ( > https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap) > Sorry for the delay. > > Le lun. 24 mai 2021 à 19:44, Ekaterina Dimitrova a > écrit : > > Thanks Paulo! > > The patch is available on github. It depends only on our availability and > priorities. I see Benedict mentioned on the ticket that probably 90% of the > patch covers already the idea of his proposal. I will be happy to finish > the work or if I am not available, when the time for it comes to handover > it to someone else. > > I can’t find the related ticket now but one of the jvm prerequisites we > needed is solved - to be able to load custom types. > > > > On Wed, 19 May 2021 at 5:04, Benjamin Lerer wrote: > > > Thanks Paulo. That one definitely fell through the cracks. > > > > I have been pretty busy lately but as soon as I have a bit of time I will > > create a roadmap page to > > summarize everything that was proposed so far. Including Making > SSLContext > > creation pluggable proposed by Maulin and the JUnit 5 migration proposal > > from Aleksei. > > > > Le mer. 19 mai 2021 à 01:48, Paulo Motta a > > écrit : > > > > > I would love to see Ekaterina's work from CASSANDRA-15234 to > standardize > > > configuration be resumed in the next releases. > > > > > > Thought it would be worth mentioning since we had quite a productive > > > discussion before putting it on hold to focus on 4.0, so it would be > > great > > > to have that conversation resumed. > > > > > > Em seg., 26 de abr. de 2021 às 14:16, Benedict Elliott Smith < > > > bened...@apache.org> escreveu: > > > > > > > I think my earlier response vanished into the moderator queue. Just a > > few > > > > comments: > > > > > > > > 1) The Paxos latency (and correctness) improvements I think should > land > > > in > > > > 4.0.x, as we have introduced a fairly significant regression and this > > > work > > > > mostly resolves outstanding issues with LWTs today. > > > > 2) If we aim to deliver multi-partition LWTs in 4.x/5.0, we may > likely > > > > want to pair this with work to further reduce latency beyond the > above > > > > work, as contention will become a more significant problem. Should I > be > > > > involved in delivering multi-partition LWTs I will also be aiming to > > > > deliver even lower latencies for the release they land in. > > > > 3) To support all of the above work, I also aim to deliver a > Simulator > > > > facility for deterministically executing cluster workloads under > > > > adversarial scheduling (i.e. that intercepts all message and thread > > > events > > > > and evaluates them sequentially, in pseudorandom order), alongside > > > > linearizability verification built upon this. This work will include > > (or > > > > have as a prerequisite) significant clean-ups to internal > functionality > > > > like executors, use of futures and other concurrency primitives, and > > > > mocking out of time and the filesystem. > > > > > > > > > > > > On 23/04/2021, 14:46, "Benjamin Lerer" wrote: > > > > > > > > Hi everybody, > > > > > > > > Thanks for all the responses. I went through the emails and > > > aggregated > > > > the > > > > proposals to give us an idea on where we stand at this point. > > > > > > > > I only included the improvements in the list and left on the side > > the > > > > bug > > > > fixes. > > > > Regarding bug fixes, I wonder if we should not have discussions > > every > > > > month > > > > to discuss what are the important issues that should be fixed in > > > > priority. > > > > I feel that we sometimes tend to forget old issues even if they > are > > > > more > > > > important than some new ones. > > > > > > > > Do not hesitate to tell me if I missed something or > misinterpreted > > > some > > > > proposal. > > > > > > > > *Query side improvements:* > > > > > > > > * Storage Attached Index or SAI. The CEP can be found at > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-7%3A+Storage+Attached+Index > > > > * Add support for OR predicates in the CQL where clause > > > > * Allow to aggregate by time intervals (CASSANDRA-11871) and >
Re: [DISCUSSION] Next release roadmap
Hi, FYI I am planning to put together all we discussed under sstable encryption thread into a kind-of CEP to distil everything said. I hope I'll put it together in the foreseeable future before taking a longer break till February. I am not sure if that is enough time to implement it if we eventually vote on that (which is rather hypothetical at this point) but I would appreciate having something solid to elaborate on. Regards On Tue, 14 Dec 2021 at 17:41, Benjamin Lerer wrote: > > Sure :-) > > I will make a separate section. > > Le mar. 14 déc. 2021 à 17:30, C. Scott Andreas a > écrit : > > > Thanks Benjamin! > > > > I see that the Roadmap doc on Confluence contains several features that > > are large in scope but do not have a published CEP or discussion on the > > mailing list. > > > > Because users will treat the roadmap doc as indicative of the project’s > > direction and intent, can these items be moved to a section indicating that > > there is interest or that they are potential features pending proposal and > > discussion? > > > > I don't think it's a good idea to list features that haven't been > > discussed on a user-visible roadmap page, but wouldn't object to the idea > > of them being in a separate section. > > > > – Scott > > > > On Dec 13, 2021, at 6:42 AM, Benjamin Lerer wrote: > > > > > > I finally wrote down the roadmap on the wiki, and updated it to reflect the > > current situation ( > > https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap) > > Sorry for the delay. > > > > Le lun. 24 mai 2021 à 19:44, Ekaterina Dimitrova a > > écrit : > > > > Thanks Paulo! > > > > The patch is available on github. It depends only on our availability and > > priorities. I see Benedict mentioned on the ticket that probably 90% of the > > patch covers already the idea of his proposal. I will be happy to finish > > the work or if I am not available, when the time for it comes to handover > > it to someone else. > > > > I can’t find the related ticket now but one of the jvm prerequisites we > > needed is solved - to be able to load custom types. > > > > > > > > On Wed, 19 May 2021 at 5:04, Benjamin Lerer wrote: > > > > > Thanks Paulo. That one definitely fell through the cracks. > > > > > > I have been pretty busy lately but as soon as I have a bit of time I will > > > create a roadmap page to > > > summarize everything that was proposed so far. Including Making > > SSLContext > > > creation pluggable proposed by Maulin and the JUnit 5 migration proposal > > > from Aleksei. > > > > > > Le mer. 19 mai 2021 à 01:48, Paulo Motta a > > > écrit : > > > > > > > I would love to see Ekaterina's work from CASSANDRA-15234 to > > standardize > > > > configuration be resumed in the next releases. > > > > > > > > Thought it would be worth mentioning since we had quite a productive > > > > discussion before putting it on hold to focus on 4.0, so it would be > > > great > > > > to have that conversation resumed. > > > > > > > > Em seg., 26 de abr. de 2021 às 14:16, Benedict Elliott Smith < > > > > bened...@apache.org> escreveu: > > > > > > > > > I think my earlier response vanished into the moderator queue. Just a > > > few > > > > > comments: > > > > > > > > > > 1) The Paxos latency (and correctness) improvements I think should > > land > > > > in > > > > > 4.0.x, as we have introduced a fairly significant regression and this > > > > work > > > > > mostly resolves outstanding issues with LWTs today. > > > > > 2) If we aim to deliver multi-partition LWTs in 4.x/5.0, we may > > likely > > > > > want to pair this with work to further reduce latency beyond the > > above > > > > > work, as contention will become a more significant problem. Should I > > be > > > > > involved in delivering multi-partition LWTs I will also be aiming to > > > > > deliver even lower latencies for the release they land in. > > > > > 3) To support all of the above work, I also aim to deliver a > > Simulator > > > > > facility for deterministically executing cluster workloads under > > > > > adversarial scheduling (i.e. that intercepts all message and thread > > > > events > > > > > and evaluates them sequentially, in pseudorandom order), alongside > > > > > linearizability verification built upon this. This work will include > > > (or > > > > > have as a prerequisite) significant clean-ups to internal > > functionality > > > > > like executors, use of futures and other concurrency primitives, and > > > > > mocking out of time and the filesystem. > > > > > > > > > > > > > > > On 23/04/2021, 14:46, "Benjamin Lerer" wrote: > > > > > > > > > > Hi everybody, > > > > > > > > > > Thanks for all the responses. I went through the emails and > > > > aggregated > > > > > the > > > > > proposals to give us an idea on where we stand at this point. > > > > > > > > > > I only included the improvements in the list and left on the side > > > the > > > > > bug > > > > > fixes. > > > > > Regarding bug fixes, I wonder if we should not have discussions
Re: [DISCUSS] Releasable trunk and quality
> > > > Merge commits aren’t that useful > > > I keep coming back to this. Arguably the only benefit they offer now is > procedurally forcing us to not miss a bugfix on a branch, but given how > much we amend many things presently anyway that dilutes that benefit. > Doesn't this come down to how you read git history, and for example appreciating a change-centric view over branch isolated development? I like a change originating from just one commit, and having tracking visible across the branches. This gives you immediate information about where and how the change was applied without having to go to the jira ticket (and relying on it being accurate). Connecting commits on different branches that are developed separately (no merge tracking) is more complicated. So yeah, I see value in those merge commits. I'm not against trying something new, just would appreciate a bit more exposure to it before making a project wide change. Hence, let's not rush it and just start first with trunk.
Re: [DISCUSS] Releasable trunk and quality
Does somebody else use the git workflow we do as of now in Apache universe? Are not we quite unique? While I do share the same opinion Mick has in his last response, I also see the disadvantage in having the commit history polluted by merges. I am genuinely curious if there is any other Apache project out there doing things same we do (or did in the past) and who changed that in one way or the other, plus reasons behind it. On Tue, 14 Dec 2021 at 19:27, Mick Semb Wever wrote: > > > > > > > > Merge commits aren’t that useful > > > > > I keep coming back to this. Arguably the only benefit they offer now is > > procedurally forcing us to not miss a bugfix on a branch, but given how > > much we amend many things presently anyway that dilutes that benefit. > > > > > Doesn't this come down to how you read git history, and for example > appreciating a change-centric view over branch isolated development? > I like a change originating from just one commit, and having tracking > visible across the branches. This gives you immediate information about > where and how the change was applied without having to go to the jira > ticket (and relying on it being accurate). Connecting commits on different > branches that are developed separately (no merge tracking) is more > complicated. So yeah, I see value in those merge commits. I'm not against > trying something new, just would appreciate a bit more exposure to it > before making a project wide change. Hence, let's not rush it and just > start first with trunk. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Releasable trunk and quality
> > I like a change originating from just one commit, and having tracking > visible across the branches. This gives you immediate information about > where and how the change was applied without having to go to the jira > ticket (and relying on it being accurate) I have the exact opposite experience right now (though this may be a shortcoming of my env / workflow). When I'm showing annotations in intellij and I see walls of merge commits as commit messages and have to bounce over to a terminal or open the git panel to figure out what actual commit on a different branch contains the minimal commit message pointing to the JIRA to go to the PR and actually finally find out _why_ we did a thing, then dig around to see if we changed the impl inside a merge commit SHA from the original base impl... Well, that is not my favorite. :D All ears on if there's a cleaner way to do the archaeology here. On Tue, Dec 14, 2021 at 1:34 PM Stefan Miklosovic < stefan.mikloso...@instaclustr.com> wrote: > Does somebody else use the git workflow we do as of now in Apache > universe? Are not we quite unique? While I do share the same opinion > Mick has in his last response, I also see the disadvantage in having > the commit history polluted by merges. I am genuinely curious if there > is any other Apache project out there doing things same we do (or did > in the past) and who changed that in one way or the other, plus > reasons behind it. > > On Tue, 14 Dec 2021 at 19:27, Mick Semb Wever wrote: > > > > > > > > > > > > Merge commits aren’t that useful > > > > > > > I keep coming back to this. Arguably the only benefit they offer now is > > > procedurally forcing us to not miss a bugfix on a branch, but given how > > > much we amend many things presently anyway that dilutes that benefit. > > > > > > > > > Doesn't this come down to how you read git history, and for example > > appreciating a change-centric view over branch isolated development? > > I like a change originating from just one commit, and having tracking > > visible across the branches. This gives you immediate information about > > where and how the change was applied without having to go to the jira > > ticket (and relying on it being accurate). Connecting commits on > different > > branches that are developed separately (no merge tracking) is more > > complicated. So yeah, I see value in those merge commits. I'm not against > > trying something new, just would appreciate a bit more exposure to it > > before making a project wide change. Hence, let's not rush it and just > > start first with trunk. > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Releasable trunk and quality
Yeah, I positively dislike merge commits, both from a patch preparation perspective and when trying to piece together a class’ history. It can actively obfuscate the impact to the branch being looked at, as well as make it much harder to skim the git log. I’d vote to modify our merge strategy irregardless of the benefits to CI. The more I think on it, the more I am anyway strongly -1 on having some bifurcated commit process. We should decide on a uniform commit process for the whole project, for all patches, whatever that may be. From: Joshua McKenzie Date: Tuesday, 14 December 2021 at 18:53 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] Releasable trunk and quality > > I like a change originating from just one commit, and having tracking > visible across the branches. This gives you immediate information about > where and how the change was applied without having to go to the jira > ticket (and relying on it being accurate) I have the exact opposite experience right now (though this may be a shortcoming of my env / workflow). When I'm showing annotations in intellij and I see walls of merge commits as commit messages and have to bounce over to a terminal or open the git panel to figure out what actual commit on a different branch contains the minimal commit message pointing to the JIRA to go to the PR and actually finally find out _why_ we did a thing, then dig around to see if we changed the impl inside a merge commit SHA from the original base impl... Well, that is not my favorite. :D All ears on if there's a cleaner way to do the archaeology here. On Tue, Dec 14, 2021 at 1:34 PM Stefan Miklosovic < stefan.mikloso...@instaclustr.com> wrote: > Does somebody else use the git workflow we do as of now in Apache > universe? Are not we quite unique? While I do share the same opinion > Mick has in his last response, I also see the disadvantage in having > the commit history polluted by merges. I am genuinely curious if there > is any other Apache project out there doing things same we do (or did > in the past) and who changed that in one way or the other, plus > reasons behind it. > > On Tue, 14 Dec 2021 at 19:27, Mick Semb Wever wrote: > > > > > > > > > > > > Merge commits aren’t that useful > > > > > > > I keep coming back to this. Arguably the only benefit they offer now is > > > procedurally forcing us to not miss a bugfix on a branch, but given how > > > much we amend many things presently anyway that dilutes that benefit. > > > > > > > > > Doesn't this come down to how you read git history, and for example > > appreciating a change-centric view over branch isolated development? > > I like a change originating from just one commit, and having tracking > > visible across the branches. This gives you immediate information about > > where and how the change was applied without having to go to the jira > > ticket (and relying on it being accurate). Connecting commits on > different > > branches that are developed separately (no merge tracking) is more > > complicated. So yeah, I see value in those merge commits. I'm not against > > trying something new, just would appreciate a bit more exposure to it > > before making a project wide change. Hence, let's not rush it and just > > start first with trunk. > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
