Re: [VOTE] CEP-21 Transactional Cluster Metadata

[scott]

+1 nb

> On Feb 6, 2023, at 9:05 PM, Ariel Weisberg  wrote:
> 
> +1
> 
> On Mon, Feb 6, 2023, at 11:15 AM, Sam Tunnicliffe wrote:
>> Hi everyone,
>> 
>> I would like to start a vote on this CEP.
>> 
>> Proposal:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
>> 
>> Discussion:
>> https://lists.apache.org/thread/h25skwkbdztz9hj2pxtgh39rnjfzckk7
>> 
>> The vote will be open for 72 hours.
>> A vote passes if there are at least three binding +1s and no binding vetoes.
>> 
>> Thanks,
>> Sam

Re: [VOTE] Release Apache Cassandra 4.0.10

[scott]

+1nb

> On May 25, 2023, at 10:14 AM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
> On Thu, May 25, 2023 at 10:13 AM Mick Semb Wever  wrote:
>> 
>> Proposing the test build of Cassandra 4.0.10 for release.
>> 
>> sha1: da77d3f729160e84fbab37666de99550be794265
>> Git: https://github.com/apache/cassandra/tree/4.0.10-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1299/org/apache/cassandra/cassandra-all/4.0.10/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.10/
>> 
>> 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]: CHANGES.txt: 
>> https://github.com/apache/cassandra/blob/4.0.10-tentative/CHANGES.txt
>> [2]: NEWS.txt: 
>> https://github.com/apache/cassandra/blob/4.0.10-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.1.2

[scott]

+1nb

> On May 25, 2023, at 10:12 AM, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 4.1.2 for release.
> 
> sha1: c5c075f0080f3f499d2b01ffb155f89723076285
> Git: https://github.com/apache/cassandra/tree/4.1.2-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1302/org/apache/cassandra/cassandra-all/4.1.2/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.2/
> 
> 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]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/4.1.2-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.2-tentative/NEWS.txt

Re: Changing the output of tooling between majors

[scott]

OT, but would gladly +1(nb) a `nodetool --output-format=json` CEP. :)

[ Some discussion also in: 
https://issues.apache.org/jira/browse/CASSANDRA-12698 ]

> On Jul 8, 2023, at 11:26 AM, Josh McKenzie  wrote:
> 
>> I think they should not parse that output in the first place. Gradually 
>> introducing JSON / YAML output formats for nodetool is cool but I think it 
>> started to happen too late and people were already parsing the raw nodetool 
>> output and here we are.
> Yes And: as you say: "here we are".
> 
> I personally try and overcorrect on the side of "how do we make things easier 
> for our users" whenever I'm presented with the opportunity because we've 
> historically been so weak on the UX front as a project. Maintaining 
> compatibility with previous "API's" (as we've discussed on the ML in the 
> past; things that are publicly presented and consumable by automation) goes a 
> long way towards giving folks confidence in building an ecosystem around a 
> project. Not the most fun thing in the world to maintain, but IMO worth it in 
> the long run for the confidence it gives folks. Especially in the "long-lived 
> infra" space we're in.
> 
> On Sat, Jul 8, 2023, at 12:57 PM, Miklosovic, Stefan wrote:
>> If somebody understood my message as I am promoting the removal of all these 
>> commands for which we have other means of getting the output of, that is not 
>> the case at all. I do not want to remove any of them.. I am just elaborating 
>> on "parsing the output of nodetool and problems related to that if it is 
>> changed" in this particular case.
>> 
>> 
>> From: Miklosovic, Stefan > >
>> Sent: Saturday, July 8, 2023 17:43
>> To: dev
>> Subject: Re: Changing the output of tooling between majors
>> 
>> Thank you, Josh, for your insight.
>> 
>> I think they should not parse that output in the first place. Gradually 
>> introducing JSON / YAML output formats for nodetool is cool but I think it 
>> started to happen too late and people were already parsing the raw nodetool 
>> output and here we are.
>> 
>> I played with nodetool a little bit to see where we are with this, there is 
>> 135 commands in total. We can leave out all "set*" commands, we can not 
>> ignore "get*" because that is potential output to parse. People just don't 
>> parse the output of "set*" commands. That is 116 commands. We can also 
>> ignore all "disable*" and "enable" commands and we are on 98. Then there is 
>> the group of "invalidate*" commands, we can skip them too, we are on 90, 
>> minus help command, 89.
>> 
>> Now the commands which left can be categorized into two main groups: the 
>> commands which execute some action and commands which display some 
>> statistics or state about internals of a Cassandra node.
>> 
>> The first group, "action commands", are again not going to be parsed on the 
>> output. These are here (1) (I could make some mistakes here and there).
>> 
>> So, the commands we can potentially parse the output of are here (2), there 
>> is roughly 51 of them.
>> 
>> Some of these commands have their equivalent in system_views vtables, these 
>> are, if I havent forgotten something
>> 
>> clientstats (system_views.clients)
>> compactionhistory (system.compaction_history)
>> compactionstats (system_views.sstable_tasks)
>> gossipinfo (system_views.gossip_info)
>> listsnapshots (system_view.snapshots)
>> tpstats (system_view.thread_pools)
>> 
>> Some of them have already different format of the output supported (JSON or 
>> YAML), they are:
>> 
>> datapaths
>> tablestats
>> tpstats (has also cql table)
>> compactionhistory (has also cql table)
>> 
>> I would argue that some commands with prefix "status" and "get" can go away 
>> too because their value is visible in system_views.settings. Some of these 
>> settings will be even updateable after Maxim's work.
>> 
>> statusbackup incremental_backups
>> statushandoff hinted_handoff_enabled
>> getmaxhintwindow max_hint_window
>> getconcurrentcompactors concurrent_compactors
>> getconcurrentviewbuilders concurrent_materialized_view_builders
>> getdefaultrf default_keyspace_rf
>> gettimeout (this just reflects cassandra.yaml more or less)
>> 
>> Then there is the family of all "get throttle / threshold " etc like this, I 
>> am lazy to go through them but they are somehow retrievable from CQL 
>> system_views.settings too.
>> 
>> getbatchlogreplaythrottle
>> getcolumnindexsize
>> getcompactionthreshold
>> getcompactionthroughput
>> getinterdcstreamthroughput
>> getsnapshotthrottle
>> getstreamthroughput
>> 
>> There are commands which just return an integer or there is nothing to 
>> change about their output / it is just not necessary like:
>> 
>> gettraceprobability
>> getsstables
>> 
>> So commands which do not have their output equivalent in some cql table or 
>> for which there is not JSON / YAML format available are
>> 
>> describecluster
>> describering
>> failuredetector

Re: [VOTE] Release Apache Cassandra 5.0-rc1 (take2)

[scott]

Agreed, I can attest to the importance of this issue as well.

The bug is query- and data-dependent, but is such that previously-correct 
latency metrics that may ordinarily report latency in the 1ms range can 
incorrectly report latency as 70ms or higher due to measurement error. Users 
would observe alarmingly high latency stats following upgrade to a build 
including this bug, though they are not reflective of the actual query 
execution latency.

This should be a quick patch to apply and re-vote on with a fresh build 
prepared.

– Scott

> On Jul 5, 2024, at 10:34 AM, Sam Tunnicliffe  wrote:
> 
> -1 
> 
> I'm afraid we have found an issue with coordinator level latency metrics 
> being artificially inflated for certain types of queries. 
> Unfortunately this is a new regression, introduced by CASSANDRA-19534, so we 
> shouldn't knowingly include it in the release.
> The good news is that only a subset of queries are affected and we have a 
> patch ready, so hopefully it won't delay things too much. 
> Further details in CASSANDRA-19755
> 
>> On 2 Jul 2024, at 12:19, Mick Semb Wever  wrote:
>> 
>> 
>> Proposing the test build of Cassandra 5.0-rc1 for release.
>> 
>> sha1: 01eea8a0d74deaede236edb25335fa470502106e
>> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1337/org/apache/cassandra/cassandra-all/5.0-rc1/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/5.0-rc1/
>> 
>> 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]: CHANGES.txt: 
>> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/CHANGES.txt
>> [2]: NEWS.txt: 
>> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt
> 

Re: Welcome Sumanth Pasupuleti as Apache Cassandra Committer

[scott]

Congratulations, Sumanth!

> On Nov 5, 2021, at 11:17 AM, Oleksandr Petrov  
> wrote:
> 
> The PMC members are pleased to announce that Sumanth Pasupuleti has
> recently accepted the invitation to become committer.
> 
> Sumanth, thank you for all your contributions to the project over the years.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

[scott]

Same reaction here - great to have traction on this ticket. Shylaja, thanks for 
your work on this and to Stefan as well! It would be wonderful to have the 
feature complete.

One thing I’d mention is that a lot’s changed about the project’s testing 
strategy since the original patch was written. I see that the 2016 version adds 
a couple round-trip unit tests with a small amount of static data. It would be 
good to see randomized tests fleshed out that exercise more of the read/write 
path; or which add variants of existing read/write path tests that enable 
encryption.

– Scott

> On Nov 13, 2021, at 7:53 AM, Brandon Williams  wrote:
> 
> We already have a ticket and this predated CEPs, and being an
> obviously good improvement to have that many have been asking for for
> some time now, I don't see the need for a CEP here.
> 
> On Sat, Nov 13, 2021 at 5:01 AM Stefan Miklosovic
>  wrote:
>> 
>> Hi list,
>> 
>> an engineer from Intel - Shylaja Kokoori (who is watching this list
>> closely) has retrofitted the original code from CASSANDRA-9633 work in
>> times of 3.4 to the current trunk with my help here and there, mostly
>> cosmetic.
>> 
>> I would like to know if there is a general consensus about me going to
>> create a CEP for this feature or what is your perception on this. I
>> know we have it a little bit backwards here as we should first discuss
>> and then code but I am super glad that we have some POC we can
>> elaborate further on and CEP would just cement  and summarise the
>> approach / other implementation aspects of this feature.
>> 
>> I think that having 9633 merged will fill quite a big operational gap
>> when it comes to security. There are a lot of enterprises who desire
>> this feature so much. I can not remember when I last saw a ticket with
>> 50 watchers which was inactive for such a long time.
>> 
>> Regards
>> 
>> -
>> 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: [DISCUSSION] Cassandra's code style and source code analysis

[scott]

For me, the strongest arguments in favor of adopting a modern build tool like 
Maven or Gradle are their ecosystems - both explicit (in terms of plugins), and 
implicit (in terms of nearly all build tooling supporting both of them, but not 
ant).

Investment in Ant - and in tooling that integrates with Ant - fell off years 
ago. This makes integrating build-phase aspects of Cassandra with other tooling 
a very frustrating task that users of most build tools get for free. Many tools 
built in the last several years don’t support it, or do so only as an 
afterthought.

Two recent examples that have caused pain for me, which I suspect are felt by 
many:

– Integration with internal build systems at many companies that develop 
Cassandra. Because ant has fallen into disuse, this integration is heavily 
manual instead of automatic and free. It usually requires forking the project’s 
build.xml, developing custom tooling around it, or creating a mock Gradle build 
that wraps ant lifecycle tasks (which also requires overriding ant tasks whose 
names clash).

– Security toolchain integration. Many users and developers of Cassandra also 
integrate with security tooling at their respective companies. Because Ant has 
fallen into disuse, most tooling commonly used by security organizations 
doesn’t support it. SBOMs are a good example, as their introduction postdates 
ant’s decline. Maven plugins exist to generate them in CycloneDX and SPDX 
format, but no such plugins exist for ant. Cassandra users and developers who 
need them must manually write shims to produce SBOMs that users of modern build 
tools get for free.

These might not be use cases anticipated by the project, but they represent 
work I suspect a large number of contributors to the project are required to 
perform to make Cassandra usable for them.

The ecosystem point means that the fix for this has to be external to the 
project if the project continues to use Ant: lots of one-off scripts and shims 
unsuitable for contribution with sole maintainers at their respective companies 
to provide functionality that users of modern build tools get for free. It also 
demands continuous, incremental work to adapt to changes in security and build 
tooling in use at many companies that don’t need to be made for projects using 
well-supported tools like Maven or Gradle.

– Scott

> On Nov 25, 2022, at 4:56 AM, Benedict  wrote:
> 
> I think modules are already fairly well supported - we in effect already have 
> several? FQL, Simulator and others I think.
> 
> I can anyway say with absolute certainty that the main impediment to 
> modularising is not build tooling, it’s the difficulty of the task, the cost 
> to the project of undertaking it, and therefore its relative payoff versus 
> other things that could be undertaken by the folk with the relevant expertise 
> to do it.
> 
> I’ve also been around long enough to see enough efforts to broaden 
> contributions fail to have an impact, that basing costly decisions on this 
> kind of reasoning doesn’t resonate. The main impediments to contributions are 
> the complexity of the codebase (and problem domain) and our limited capacity 
> to respond promptly to high quality contributions. Until we fix those 
> fundamental issues, this kind of rearranging of chairs seems more like a 
> branding exercise to ourselves than to anyone else.
> 
> 
>> On 25 Nov 2022, at 10:22, Miklosovic, Stefan  
>> wrote:
>> 
>> I agree with what you wrote. How I understand it is that migrating to 
>> Maven/Gradle makes the project more "attractive" for newcomers. If a project 
>> is built on "that old un-cool Ant", it might be a little bit off-putting and 
>> questionable if we are "stuck in the past on build systems and not 
>> progressing".
>> 
>> So in that sense I agree this is more "marketing" rather than technological 
>> question but on the other hand, does not Maven/Gradle allow us to modularize 
>> the project better? Maybe we would like to modularize but nobody is up to 
>> that because build system makes it impossible or at least quite inconvenient 
>> to do so. Do you really think there are not any significant benefits to 
>> switch even if it "just works" now?
>> 
>> 
>> From: Benedict 
>> Sent: Friday, November 25, 2022 11:07
>> To: dev@cassandra.apache.org
>> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>> 
>> 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.
>> 
>> 
>> 
>> 
>> There’s always a handful of people asking for it, but notably few if any of 
&g

Re: [DISCUSS] Donating easy-cass-stress to the project

[scott]

Supportive and would welcome the contribution as well. Jon, thanks for your 
willingness to offer this work to the Foundation.

Also supportive of considering easy-cass-stress the successor to 
cassandra-stress.

I’m fine with a directional goal of deprecating and removing cassandra-stress, 
but would like to make sure we have a successor to compaction-stress before 
doing so. I very rarely use cassandra-stress, but compaction-stress is helpful 
for generating a large corpus of SSTables and allowing compaction to churn 
through them. This is great for benching changes to the read path, compaction 
strategies, and for evaluation of hardware/VM/IO performance.

https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java

Apologies if this exists in easy-cass-stress today - I may have missed it. Our 
own documentation even lacks a mention of compaction-stress. :)

– Scott

> On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič  wrote:
> 
> * easy-cass-stress, sorry. Everything else holds. 
> 
> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič  <mailto:smikloso...@apache.org>> wrote:
>> What does "replacing" actually mean? If this tool is added to a separate 
>> repository, you mean  like it would be put there under the "easy-cass-lab" 
>> name and all source code of cassandra-stress in the Cassandra repository 
>> would be removed? Are we going to deprecate what we have first or it is 
>> going to be a big bang? 
>> 
>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think 
>> that "easy-cass-lab" should be the name of a repo we are going to use.  For 
>> a custom tool living outside of Cassandra until now, sure, but the official 
>> stress tool should not be called "easy-cass-lab". People would be like ... 
>> what? IMHO we should rename it to cassandra-stress. 
>> 
>> On Sun, Oct 13, 2024 at 8:33 PM Brad > <mailto:bscho...@gmail.com>> wrote:
>>> I'm +1 on replacing the existing cassandra-stress.  My team did some work 
>>> last Summer to remove Thrift related CLI args, but arg parsing alone is a 
>>> 5K line mess. It's certainly not being well-maintained and could use a 
>>> replacement.
>>> 
>>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie >> <mailto:jmcken...@apache.org>> wrote:
>>>> Unsolicited .02:
>>>>> - If this will eventually replace the in-tree cassandra-stress, does it 
>>>>> warrant a CEP ?  (i'm ok with skipping, though that step might have 
>>>>> encouraged the questions above)
>>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>>> 
>>>> Given the current tool is unmaintained and doesn't (to my knowledge) have 
>>>> a workflow-based usage paradigm that could be easily extended, seems like 
>>>> a clear win.
>>>> 
>>>> 
>>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>>>>  reply below.
>>>>>  
>>>>> I’m terms of next steps: Mick what do we need to do next? Figure out the 
>>>>> answers to your questions re: getting contributor sign off?
>>>>> 
>>>>> 
>>>>> 
>>>>> The process of donation is as follows… (feel free to correct me, or add 
>>>>> anything)
>>>>> 
>>>>> 
>>>>> 1. General pre-agreement from the PMC that we'll take this project in, 
>>>>> and how it will fit in.  
>>>>> 
>>>>> Some questions I (personally) have are,
>>>>> - Is the PMC ok with accepting a kotlin repository into the main part of 
>>>>> the project ? (I assume so, kotlin == java, just asking the question.  
>>>>> this was asked before, maybe i missed any response)  
>>>>> - Who are the initial three PMC members that are volunteering to be 
>>>>> active ? (Jon, Jordan, and ?) 
>>>>> - How will the activity in this repository maintain visibility to the 
>>>>> rest of the project ? (see recent discussions wrt sidecar's activity 
>>>>> silo-ing)
>>>>> - Is the repo intending to adopt general project practices ? (e.g. 
>>>>> release formalities, "patch by ; reviewed by for " commit messages, etc 
>>>>> etc etc.  if not, what is planned…)
>>>>> - If this will eventually replace the in-tree cassandra-stress, does it 
>>>>> warrant a CEP ?  (i'm ok with skipping, though that step might have 
>>&g

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[scott]

+1

> On Mar 9, 2025, at 7:50 AM, Jeremiah Jordan  wrote:
> 
> +1
> 
> On Sun, Mar 9, 2025 at 8:03 AM Brandon Williams  > wrote:
>> +1
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever > > wrote:
>> >
>> > Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
>> > and its IP Clearance:
>> > https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>> >
>> > All consent from original authors of the donation, and tracking of
>> > collected CLAs, is found in:
>> >  - https://github.com/riptano/ccm/issues/773
>> >  - 
>> > https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
>> >
>> > These do not require acknowledgement before the vote.
>> >
>> > The code is prepared for donation at https://github.com/riptano/ccm
>> > (Only `master` and `cassandra-test` refs will be brought over.)
>> >
>> > Once this vote passes we will request ASF Infra to move the
>> > riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
>> > cassandra-test tag, with all its history, will be kept.  Because
>> > consent and CLAs were not received from all original authors the
>> > NOTICE file keeps additional reference to these earlier copyright
>> > authors.
>> >
>> > PMC members, please check carefully the IP Clearance requirements before 
>> > voting.
>> >
>> > The vote will be open for 72 hours (or longer). Votes by PMC members
>> > are considered binding. A vote passes if there are at least three
>> > binding +1s and no -1's.
>> >
>> > regards,
>> > Mick

Re: Hi-Rez of Apache Cassandra logo??

[Scott Andreas]

Hi Nate,

Here are vectorized versions of the logo reading "Apache Cassandra":
– http://paradoxica.net/img/cassandra/apache-cassandra.pdf
– http://paradoxica.net/img/cassandra/apache-cassandra.eps

This is not an official graphic, but for the sake of provenance:

– The image is sourced from: 
https://svn.apache.org/repos/asf/cassandra/logo/cassandra.svg
– I've replaced "cassandra" with "apache cassandra" set in Cronos Pro Bold 
Italic (which I believe is the original typeface).
– And exported as a vector PDF and EPS, which should be scalable to any size 
you need.

The above URLs are not permanent; since the list allows max-1MB attachments, 
I've uploaded them to a temporary location.

Happy to make changes or to share in another format if that works better.

– Scott


From: Nate McCall 
Sent: Thursday, May 17, 2018 9:45:18 PM
To: dev
Subject: Hi-Rez of Apache Cassandra logo??

I'm looking for a hi-rez source of 'the eye' with "Apache Cassandra"
(that last part is important) basically what we have on the website.
I'm gonna run off some laptop stickers on sticker mule.

Provided I can track that down, you can have one if you show up here:
https://www.meetup.com/Apache-Cassandra-Bay-Area/events/250901453/

Once I get this squared away, i'll create a template and share it
somewhere (maybe check it in?) so anyone can print "Apache Cassandra"
stuff provided they follow the merchandising guidelines:
https://www.apache.org/foundation/marks/merchandise

-
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: Rocksandra performance test result

[Scott Andreas]

Thanks for sharing, Jay.

Could you say a bit more about how you’ve approached shadowing traffic against 
an alternate cluster? (Asking not so much with regard to the Rocksandra test, 
but toward shadowing methodology in general).

– Scott

> On Jun 1, 2018, at 9:46 PM, Jay Zhuang  wrote:
> 
> We're shadowing some production traffics to a Rocksandra cluster (
> https://github.com/Instagram/cassandra/tree/rocks_3.0), the P99 latency is
> significantly improved (about 6x for read, 12x for write). Here are the
> test details:
> 
> https://docs.google.com/document/d/1cEM8ZqB5tOYVdsh1LpqSZ-eLasumWfzn_Tk_lDjxOTk/
> 
> Thanks,
> Jay

Re: Testing 4.0 Post-Freeze

[Scott Andreas]

Here’s why I really like this proposal:

– It focuses our thought and effort on what it’ll take for each of us to become 
confident in running Apache Cassandra 4.0 for our most critical applications 
*prior* to cutting the dot-zero release.
– It marks a commitment we can make to our user community: delivering 4.0’s 
featureset with safety and stability is our top priority.
– There are many different perspectives each contributor can bring: 
correctness, performance, durability, automation, documentation, operational 
safety, etc; and many ways to gain confidence in each – perf tests, profiling, 
shadow writes/traffic mirroring, diff tests, replay tests, fuzz tests, fault 
injection, chaos engineering, and so many others. By bringing diverse methods 
to bear on the same class of problem (quality), we’re more likely to identify 
issues that could impact our users and to ship a better release.
– It’s disciplined and courageous!

Here’s why I think this won’t discourage new contributors from joining – in 
fact, the opposite:

– It provides a very simple step that any contributor can take toward shipping 
4.0: running it.
– We raise spirits by delivering enhancements the community has been working on 
for two years rather than fracturing our attention.
– If members of the community are interested in post-4.0 work, they’re not 
blocked from making progress toward that – but it’s not the focus, and unlikely 
that review bandwidth would be available given that focus. I agree with Kurt’s 
note that nobody can be “forced" to do anything - but by committing to 
reserving trunk for stabilizing changes until the beta, we focus our effort on 
polishing and delivering the release.

On the last question:
> On another note, we are still planning on accepting/reviewing bug fixes for 
> previous versions as well correct?

I’d expect so – and to take it a step further, it’s likely that this rigor will 
result in us identifying serious issues that were not regressions in 4.0 
warranting backports. As with any investment in testing / validation, I’m 
hoping we do … but also hoping we don’t. :-)


> On Jul 3, 2018, at 7:21 PM, kurt greaves  wrote:
> 
> tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I
> can't really see how changing the branching strategy is going to have any
> impact at all.
> 
> I really don't think it's a big deal. People will work based on whatever
> priorities they've been assigned, regardless of what you do to the
> branching. That's essentially just red tape and adding unnecessary
> complexity to an already established process. Granted, you'll have to do
> one less merge, but it should be an effortless merge, and it saves there
> being any confusion about what people should do with features. If someone
> decided to commit a feature, they could, and we wouldn't have to be all
> over every ticket making sure people don't commit things that shouldn't be
> committed.
> 
> Cutting to the point, all we're really aiming for here is a commitment from
> the community to only dev on bugfixes, only review bugfixes, and
> testing/validation during the freeze period. That's not going to be
> enforced by a change in branching strategy, it's going to be enforced by
> the contributors themselves (and their respective priority-setters).
> The best we can do is encourage a commitment to testing and bugfixing for
> the freeze period. This is a volunteer based project after all, so we can't
> really force anyone to do anything. If contributors make proposals for
> features in the freeze period we can just tell them that there is a focus
> on 4.0 testing and it's unlikely to be reviewed until 4.0 is released at
> best.
> 
> On another note, we are still planning on accepting/reviewing bug fixes for
> previous versions as well correct?  Just to clarify because it doesn't seem
> to be mentioned here and we don't want people getting in arguments over
> reviewing patches that only affect older releases.
> 
> I think not having your patch reviewed for months is more
>> discouraging than following the community and helping with stability of
>> 4.0.
> 
> Patches not getting reviewed for months on end already occurs. Changing how
> we branch isn't going to change this or make anyone feel better about it.
> The best we can do is communicate why their patches aren't getting
> reviewed, and we should be doing this on individual feature tickets that
> get raised and on the ML.
> 
> On 4 July 2018 at 00:44, Mick Semb Wever  wrote:
> 
>>> 
>>> 
>>> We propose that between the September freeze date and beta, a new branch
>>> would not be created and trunk would only have bug fixes and performance
>>> improvements committed to it.
>>> 
>> 
>> 
>> +1, like really yes!! because it's a step towards a more stable-master
>> project.
>> 
>> If trunk is focused on stabilising (which ideally it shouldn't have to, if
>> stable-master were true) then new features remaining in their respective
>> branches shouldn't be a big co

Tracking Testing, Release Status, and Build Health

[Scott Andreas]

Hi everyone,

As September approaches, I’ve been thinking about how we might be able to share 
notes on testing and build health.

Some types of information I have in mind:

– Known issues with builds (e.g., master / nightlies) that impact the ability 
to test the project. These could include known-flaky tests, bugs impacting test 
automation, or specific features that aren’t functioning as designed. Some 
contributors may be prefer to waive specific types of testing to prevent their 
automation from failing; others may prefer to continue more exhaustive testing 
of builds known not to be impacted by an issue.
– Tracking high-priority bugs that are known blockers, either for test 
automation or suitability of a release for dev / QA environments.
– Pre-release checklists and outstanding to-do items that need to be completed 
prior to cutting a build which aren’t necessarily best represented by a JIRA 
ticket.
– Performance test status – the characteristics of tests performed, hardware 
configurations, and improvements / regressions identified over time.

Some of this information may change often as development and testing progress - 
as often as daily in some cases.

Here are a couple examples of similar work in other projects:

–
– Hadoop’s “Release Status” docs in Confluence: 
https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+2.8.0+Release

The Hadoop project uses these status docs to track release blockers, to-do 
items that need to be tracked ahead of release, and notes on scope as defined 
by the community.

– Hadoop’s “Road Map” docs in Confluence:
https://cwiki.apache.org/confluence/display/HADOOP/Roadmap

Similarly, the Hadoop project uses docs like this to track planned features for 
each release, and feature freeze, code freeze, and planned release dates. These 
are useful for organizing development and signposting what’s planned to the 
user community.

– “Are We Fast Yet”: A project from Mozilla tracking JS engine performance
https://arewefastyet.com

Perf testing of nightlies across a several platforms (and comparisons with 
other JavaScript engines), useful for identifying regressions quickly and 
tracking progress toward perf goals.
–

I’m curious on the dev community’s thoughts on how best to organize information 
like this. My thinking is that by having a space to share this, the community 
can be more informed on each others’ work toward testing, build health, and 
active projects.

The current Cassandra wiki (https://wiki.apache.org/cassandra) doesn’t appear 
too active and carries a warning. What do others think about filing an INFRA 
ticket to request a Confluence space at https://cwiki.apache.org for this type 
of information?

I’d be happy to help maintain information tracking build health, remaining 
to-do’s, known test automation blockers, flaky tests, etc. as well.

Cheers,

– Scott

Re: Apache Cassandra Blog is now live

[Scott Andreas]

Please feel free to file a ticket (label: Documentation and Website).

It looks like Jekyll, the static site generator used to build the website, has 
a plugin that generates Atom feeds if someone would like to work on adding one: 
https://github.com/jekyll/jekyll-feed


From: Jacques-Henri Berthemet 
Sent: Wednesday, August 8, 2018 1:32:23 AM
To: dev@cassandra.apache.org
Subject: RE: Apache Cassandra Blog is now live

It is possible to setup RSS on the blog? Should I create a Jira about that?

--
Jacques-Henri Berthemet

-Original Message-
From: Mick Semb Wever 
Sent: Wednesday, August 08, 2018 8:17 AM
To: dev@cassandra.apache.org
Subject: Re: Apache Cassandra Blog is now live


> We are also interested in contributing to the blog, what's the process?


Dikang,
it's part of the website,
https://svn.apache.org/repos/asf/cassandra/site/src/README

regards,
Mick

-
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: QA signup

[Scott Andreas]

Thanks for getting started with performance testing - this is exciting to hear!

Periodic SNAPSHOT builds sounds great. I'd feel much better about builds 
published as date- or SHA-stamped snapshots / nightlies rather than calling 
them alphas at this point, as everyone's testing work is beginning. Can someone 
offer details on what would need to be done to publish snapshots or nightlies 
in the context of Apache build infrastructure?

In looking at the Confluence space restrictions, it appears the main page is 
open for editing and I don't see restrictions on page creation; can you try to 
sign in, create one, and let me know if that doesn't work?

I'm planning to create a few more pages for a couple testing tracks in a few 
days, some of which are described here [1]. Eager to collaborate on these as 
well.

–––
[1] http://cassandra.apache.org/blog/2018/08/21/testing_apache_cassandra.html.


From: Joseph Lynch 
Sent: Friday, September 7, 2018 1:20:19 PM
To: dev@cassandra.apache.org
Subject: Re: QA signup

I don't think anyone has mentioned this yet but we probably want to
consider releasing 4.0 alpha jars to maven central soon so the open
source ecosystem can start testing a consistent Cassandra 4.0; for
example I had to hack 4.0 into Priam's build [1] by manually building
a jar and checking it in which is ... not particularly good or
reproducible for others. I'm not sure how hard it would be but
supporting periodic SNAPSHOT releases would also at least allow
building against trunk and would be great too. It also might be a good
idea to have a document (confluence page?) of breaking changes that
are most likely to require a change from users. For example the
SeedProvider interface change is probably going to break almost
everyone's deployment (but is easy to fix), and having a central list
of removed yaml options might be helpful past the NEWs file.

Regarding testing areas, we deployed trunk in the Netflix testing
environment on Wednesday with the aim to test the netty internode
messaging subsystem on 200+ node clusters. We are working with Jason,
Dinesh, and Jordan and have already found some interesting results and
would like to write them down as well as working on establishing good
baselines and testing methodology for stressing that subsystem. Is the
consensus here to create Jira epics tagged with 4.0 blocker for each
subsystem, or confluence pages (if confluence I think we need to give
people permissions to add pages?)?

Other areas we can help test and are looking for collaborators on are
audit/full query logging and we are potentially interested in helping
to test repair, but our internal implementation doesn't support
Cassandra 4.x ... we can re-work the CASSANDRA-14346 patch without too
much effort I think to thoroughly test full/incremental repair at any
scale cluster (or maybe Reaper folks can test repair).

[1] 
https://github.com/Netflix/Priam/pull/713/files#diff-3c33bef9f0334cf724470d50eae8dd8b

-Joey

On Fri, Sep 7, 2018 at 9:57 AM Jonathan Haddad  wrote:
>
> Really good idea JD. Keeping all the tests under an umbrella ticket for the
> feature with everything linked back makes a lot of sense.
>
> On Thu, Sep 6, 2018 at 11:09 PM J. D. Jordan 
> wrote:
>
> > I would suggest that JIRA’s tagged as 4.0 blockers be created for the list
> > once it is fleshed out.  Test plans and results could be posted to said
> > JIRAs, to be closed once a given test passes. Any bugs found can also then
> > be related back to such a ticket for tracking them as well.
> >
> > -Jeremiah
> >
> > > On Sep 6, 2018, at 12:27 PM, Jonathan Haddad  wrote:
> > >
> > > I completely agree with you, Sankalp.  I didn't want to dig too deep into
> > > the underlying testing methodology (and I still think we shouldn't just
> > > yet) but if the goal is to have confidence in the release, our QA process
> > > needs to be comprehensive.
> > >
> > > I believe that having focused teams for each component with a team leader
> > > with support from committers & contributors gives us the best shot at
> > > defining large scale functional tests that can be used to form both
> > > progress and bug reports.  (A person could / hopefully will be on more
> > than
> > > one team).  Coming up with those comprehensive tests will be the jobs of
> > > the teams, getting frequent bidirectional feedback on the dev ML.  Bugs
> > go
> > > in JIRA as per usual.
> > >
> > > Hopefully we can continue this process after the release, giving the
> > > project more structure, and folding more people in over time as
> > > contributors and ideally committers / PMC.
> > >
> > > Jon
> > >
> > >
> > >> On Thu, Sep 6, 2018 at 1:15 PM sankalp kohli 
> > wrote:
> > >>
> > >> Thanks for starting this Jon.
> > >> Instead of saying "I tested streaming", we should define what all was
> > >> tested like was all data transferred, what happened when stream failed,
> > >> etc.
> > >> Based on talking to a few users, looks like most 

Re: QA signup

[Scott Andreas]

@Mick, thanks for your reply re: publishing snapshots/nightlies. In terms of 
what’s needed to configure these, would it be automation around building 
release artifacts, publishing jars to the Maven snapshots repo, and to 
dist/dev/cassandra on dist.apache.org<http://dist.apache.org> for binary 
artifacts?

@Joey Thanks! Jason’s shown me what I was missing in Confluence. Can you try 
creating a page and letting me know if you’re able? Feel free to create any 
pages you think appropriate.

I’ve added permissions for the "cassandra-committers” group, and for the PMC 
members and committers who have accounts on 
cwiki.apache.org<http://cwiki.apache.org> [1]. For those who don’t have a cwiki 
account but would like write access, please sign up and send Jason or myself a 
message; we can enable write perms: 
https://cwiki.apache.org/confluence/signup.action

– Scott

–––

[1] PMC members and committers with write access added:
– Jake Luciani
– Jason Brown
– Jonathan Ellis
– Jake Farrell
– Jeff Jirsa
– Jun Rao
– Matthieu Riou
– Sylvain Lebresna
– Avinash Lakshman
– Johan Oskarsson
– Mick Semb Wever


On September 12, 2018 at 4:44:51 PM, Joseph Lynch 
(joe.e.ly...@gmail.com<mailto:joe.e.ly...@gmail.com>) wrote:

> In looking at the Confluence space restrictions, it appears the main page is 
> open for editing and I don't see restrictions on page creation; can you try 
> to sign in, create one, and let me know if that doesn't work?

I signed in and went to "Jira reports" and then tried to hit "Add Jira
Report" and it said "Sorry you don't have permission to create
content. Contact your space administrator to request access". Also if
I just go to the Cassandra space there is no "Create" button in the in
the top left where it normally is, all I see when logged on in the
Cassandra space is "Spaces" and "People".

> I'm planning to create a few more pages for a couple testing tracks in a few 
> days, some of which are described here [1]. Eager to collaborate on these as 
> well.

Please let me know if you create one for internode messaging, we have
(I think valuable) data/methods from last Wednesday we can share. I've
started leaving the results we have so far as well as the methodology
we used at https://issues.apache.org/jira/browse/CASSANDRA-14746 with
the label "4.0-QA" but I can copy and paste anywhere we decide to put
these things.

-Joey

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: QA signup

[Scott Andreas]

Got it, thanks!

On the target audience:

This would primarily be C* developers who are working on development, testing, 
and validation of the release. The performance testing exercise Joey, Vinay, 
Sumanth, Jason, Jordan, and Dinesh completed yesterday is a good example [1]. 
For developers building automation around testing and validation, it’d be great 
to have a common build to work from rather than each developer producing these 
builds themselves.

Some purposes that could serve:
– Ensuring we’re testing the same artifact. While a build produced from a given 
SHA should be ~identical, we can make stronger statements about particular 
build artifacts produced by common infrastructure than local builds produced by 
individual developers.
– Automation: the ability to automate test suite runs on publication of a new 
build (e.g., perf, replay, traffic shadowing, upgrade tests, etc).
– Faster dev/test/validation cycles. The perf tests in [1] identified two 
issues whose fixes will land in C-14503. Being able to pick up these fixes on 
commit via automation provides quicker feedback than waiting for a new build to 
be manually cut.
– Fewer developers experiencing blocked automation. In a case where a 
regression is identified in a build produced by a commit (e.g., a snapshot 
build is “DOA” for testing purposes), a quick fix could resolve the issue with 
a new testable artifact produced within a day.
– Better delineation between developer builds and those we recommend to the 
user community. Our ability to produce snapshot/nightly artifacts reduces 
pressure to cut an alpha for testing, reducing pressure to nominate 
community-facing releases in order to further the developer-focused goals above.

––
[1] 
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Performance+Testing


On September 18, 2018 at 5:47:18 PM, Mick Semb Wever 
(m...@apache.org<mailto:m...@apache.org>) wrote:

Scott,

> @Mick, thanks for your reply re: publishing snapshots/nightlies. In
> terms of what’s needed to configure these, would it be automation around
> building release artifacts, publishing jars to the Maven snapshots repo, …


Maven artefacts are deployed to the ASF snapshot repository in Nexus.
The short of it is to add credentials for `apache.snapshots.https` to 
~/.m2/settings.xml and run `ant publish`.

It looks like `ant publish` won't run when it's not a release, but otherwise 
the maven deploy properties in `build.xml` look correct for snapshots.

I haven't looked into how to automate this in Jenkins in regards to the 
settings.xml credentials and the gpg signing.

For info at: http://www.apache.org/dev/publishing-maven-artifacts.html

I question I have is who are we targeting with maven snapshots? Is this an 
audience that can easily enough be building the jars themselves to test during 
the feature freeze period?


> and to dist/dev/cassandra on dist.apache.org for binary artifacts?


This is a simpler task, just upload (`svn commit`) the nightly binaries to 
https://dist.apache.org/repos/dist/dev/cassandra/

See https://www.apache.org/legal/release-policy.html#host-rc

regards,
Mick

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Measuring Release Quality

[Scott Andreas]

Hi everyone,

Now that many teams have begun testing and validating Apache Cassandra 4.0, 
it’s useful to think about what “progress” looks like. While metrics alone may 
not tell us what “done” means, they do help us answer the question, “are we 
getting better or worse — and how quickly”?

A friend described to me a few attributes of metrics he considered useful, 
suggesting that good metrics are actionable, visible, predictive, and 
consequent:

– Actionable: We know what to do based on them – where to invest, what to fix, 
what’s fine, etc.
– Visible: Everyone who has a stake in a metric has full visibility into it and 
participates in its definition.
– Predictive: Good metrics enable forecasting of outcomes – e.g., “consistent 
performance test results against build abc predict an x% reduction in 99%ile 
read latency for this workload in prod".
– Consequent: We take actions based on them (e.g., not shipping if tests are 
failing).

Here are some notes in Confluence toward metrics that may be useful to track 
beginning in this phase of the development + release cycle. I’m interested in 
your thoughts on these. They’re also copied inline for easier reading in your 
mail client.

Link: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=93324430

Cheers,

– Scott

––

Measuring Release Quality:

[ This document is a draft + sketch of ideas. It is located in the "discussion" 
section of this wiki to indicate that it is an active draft – not a document 
that has been voted on, achieved consensus, or in any way official. ]

Introduction:

This document outlines a series of metrics that may be useful toward measuring 
release quality, and quantifying progress during the testing / validation phase 
of the Apache Cassandra 4.0 release cycle.

The goal of this document is to think through what we should consider measuring 
to quantify our progress testing and validating Apache Cassandra 4.0. This 
document explicitly does not discuss release criteria – though metrics may be a 
useful input to a discussion on that topic.


Metric: Build / Test Health (produced via CI, recorded in Confluence):

Bread-and-butter metrics intended to capture baseline build health, flakiness 
in the test suite, and presented as a time series to understand how they’ve 
changed from build to build and release to release:

Metrics:

– Pass / fail metrics for unit tests
– Pass / fail metrics for dtests
– Flakiness stats for unit and dtests


Metric: “Found Bug” Count by Methodology (sourced via JQL, reported in 
Confluence):

These are intended to help us understand the efficacy of each methodology being 
applied. We might consider annotating bugs found in JIRA with the methodology 
that produced them. This could be consumed as input in a JQL query and reported 
on the Confluence dev wiki.

As we reach a pareto-optimal level of investment in a methodology, we’d expect 
to see its found-bug rate taper. As we achieve higher quality across the board, 
we’d expect to see a tapering in found-bug counts across all methodologies. In 
the event that one or two approaches is an outlier, this could indicate the 
utility of doubling down on a particular form of testing.

We might consider reporting “Found By” counts for methodologies such as:

– Property-based / fuzz testing
– Replay testing
– Upgrade / Diff testing
– Performance testing
– Shadow traffic
– Unit/dtest coverage of new areas
– Source audit


Metric: “Found Bug” Count by Subsystem/Component (sourced via JQL, reported in 
Confluence):

Similar to “found by,” but “found where.” These metrics help us understand 
which components or subsystems of the database we’re finding issues in. In the 
event that a particular area stands out as “hot,” we’ll have the quantitative 
feedback we need to support investment there. Tracking these counts over time – 
and their first derivative – the rate – also helps us make statements regarding 
progress in various subsystems. Though we can’t prove a negative (“no bugs have 
been found, therefore there are no bugs”), we gain confidence as their rate 
decreases normalized to the effort we’re putting in.

We might consider reporting “Found In” counts for components as enumerated in 
JIRA, such as:
– Auth
– Build
– Compaction
– Compression
– Core
– CQL
– Distributed Metadata
– …and so on.


Metric: “Found Bug” Count by Severity (sourced via JQL, reported in Confluence)

Similar to “found by/where,” but “how bad”? These metrics help us understand 
the severity of the issues we encounter. As build quality improves, we would 
expect to see decreases in the severity of issues identified. A high rate of 
critical issues identified late in the release cycle would be cause for 
concern, though it may be expected at an earlier time.

These could roughly be sourced from the “Priority” field in JIRA:
– Trivial
– Minor
– Major
– Critical
– Blocker

While “priority” doesn’t map directly to “severity,” it may be a useful proxy. 
Altern

Re: QA signup

[Scott Andreas]

Mick – Got it, thanks and sorry to have misunderstood. No fault in your writing 
at all; that was my misreading.

Agreed with you and Kurt; I can’t think of a pressing need or immediate use for 
the Maven artifacts. As you mentioned, all of the examples I’d listed require 
binary artifacts only.

Re: Jon’s question:
> It seems to me that improving / simplifying the process of building the 
> packages might solve this problem better.

Agreed that making builds easy is important, and that manually-applied patches 
were involved in a couple cases I’d cited. My main motivation is toward making 
it easier for developers who’d like to produce fully-automated test pipelines 
to do so using common artifacts, rather than each replicating the 
build/packaging step for tarball artifacts themselves.

Publishing binary artifacts in a common location would enable developers to 
configure testing and benchmarking pipelines to pick up those artifacts on a 
daily basis without intervention. In the case of a build landing DOA due to an 
issue with a commit, it’d be enough for zero-touch automation to pick up a new 
build with the fix the following day and run an extended suite across a large 
number of machines and publish results, for example.


On September 19, 2018 at 8:17:05 PM, kurt greaves 
(k...@instaclustr.com) wrote:

It's pretty much only third party plugins. I need it for the LDAP
authenticator, and StratIO's lucene plugin will also need it. I know there
are users out there with their own custom plugins that would benefit from
it as well (and various other open source projects). It would make it
easier, however it certainly is feasible for these devs to just build the
jars themselves (and I've done this so far). If it's going to be easy I
think there's value in generating and hosting nightly jars, but if it's
difficult I can just write some docs for DIY.

On Thu, 20 Sep 2018 at 12:20, Mick Semb Wever  wrote:

> Sorry about the terrible english in my last email.
>
>
> > On the target audience:
> >
> > [snip]
> > For developers building automation around testing and
> > validation, it’d be great to have a common build to work from rather
> > than each developer producing these builds themselves.
>
>
> Sure. My question was only in context of maven artefacts.
> It seems to me all the use-cases you highlight would be for the binary
> artefacts.
>
> If that's the case we don't need to worry about publishing snapshots maven
> artefacts, and can just focus on uploading nightly builds to
> https://dist.apache.org/repos/dist/dev/cassandra/
>
> Or is there a use-case I'm missing that needs the maven artefacts?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Measuring Release Quality

[Scott Andreas]

Josh, thanks for reading and sharing feedback. Agreed with starting simple and 
measuring inputs that are high-signal; that’s a good place to begin.

To the challenge of building consensus, point taken + agreed. Perhaps the 
distinction is between producing something that’s “useful” vs. something that’s 
“authoritative” for decisionmaking purposes. My motivation is to work toward 
something “useful” (as measured by the value contributors find). I’d be happy 
to start putting some of these together as part of an experiment – and agreed 
on evaluating “value relative to cost” after we see how things play out.

To Benedict’s point on JIRA, agreed that plotting a value from messy input 
wouldn’t produce useful output. Some questions a small working group might take 
on toward better categorization might look like:

–––
– Revisiting the list of components: e.g., “Core” captures a lot right now.
– Revisiting which fields should be required when filing a ticket – and if 
there are any that should be removed from the form.
– Reviewing active labels: understanding what people have been trying to 
capture, and how they could be organized + documented better.
– Documenting “priority”: (e.g., a common standard we can point to, even if 
we’re pretty good now).
– Considering adding a "severity” field to capture the distinction between 
priority and severity.
–––

If there’s appetite for spending a little time on this, I’d put effort toward 
it if others are interested; is anyone?

Otherwise, I’m equally fine with an experiment to measure basics via the 
current structure as Josh mentioned, too.

– Scott


On September 20, 2018 at 8:22:55 AM, Benedict Elliott Smith 
(bened...@apache.org<mailto:bened...@apache.org>) wrote:

I think it would be great to start getting some high quality info out of JIRA, 
but I think we need to clean up and standardise how we use it to facilitate 
this.

Take the Component field as an example. This is the current list of options:

4.0
Auth
Build
Compaction
Configuration
Core
CQL
Distributed Metadata
Documentation and Website
Hints
Libraries
Lifecycle
Local Write-Read Paths
Materialized Views
Metrics
Observability
Packaging
Repair
SASI
Secondary Indexes
Streaming and Messaging
Stress
Testing
Tools

In some cases there's duplication (Metrics + Observability, Coordination 
(=“Storage Proxy, Hints, Batchlog, Counters…") + Hints, Local Write-Read Paths 
+ Core)
In others, there’s a lack of granularity (Streaming + Messaging, Core, 
Coordination, Distributed Metadata)
In others, there’s a lack of clarity (Core, Lifecycle, Coordination)
Others are probably missing entirely (Transient Replication, …?)

Labels are also used fairly haphazardly, and there’s no clear definition of 
“priority”

Perhaps we should form a working group to suggest a methodology for filling out 
JIRA, standardise the necessary components, labels etc, and put together a wiki 
page with step-by-step instructions on how to do it?


> On 20 Sep 2018, at 15:29, Joshua McKenzie  wrote:
>
> I've spent a good bit of time thinking about the above and bounced off both
> different ways to measure quality and progress as well as trying to
> influence community behavior on this topic. My advice: start small and
> simple (KISS, YAGNI, all that). Get metrics for pass/fail on
> utest/dtest/flakiness over time, perhaps also aggregate bug count by
> component over time. After spending a predetermined time doing that (a
> couple months?) as an experiment, we retrospect as a project and see if
> these efforts are adding value commensurate with the time investment
> required to perform the measurement and analysis.
>
> There's a lot of really good ideas in that linked wiki article / this email
> thread. The biggest challenge, and risk of failure, is in translating good
> ideas into action and selling project participants on the value of changing
> their behavior. The latter is where we've fallen short over the years;
> building consensus (especially regarding process /shudder) is Very Hard.
>
> Also - thanks for spearheading this discussion Scott. It's one we come back
> to with some regularity so there's real pain and opportunity here for the
> project imo.
>
> On Wed, Sep 19, 2018 at 9:32 PM Scott Andreas  wrote:
>
>> Hi everyone,
>>
>> Now that many teams have begun testing and validating Apache Cassandra
>> 4.0, it’s useful to think about what “progress” looks like. While metrics
>> alone may not tell us what “done” means, they do help us answer the
>> question, “are we getting better or worse — and how quickly”?
>>
>> A friend described to me a few attributes of metrics he considered useful,
>> suggesting that good metrics are actionable, visible, predictive, and
>> consequent:
>>
>> – Actionable: We know what to do based on them – where to invest

Re: 4.0 Testing Signup

[Scott Andreas]

Joey, thanks for starting this document!

I’ve updated it to add several leads/contributors, and will probably have a few 
minor updates to add soon.


On November 8, 2018 at 2:49:52 PM, Joseph Lynch 
(joe.e.ly...@gmail.com) wrote:

On Thu, Nov 8, 2018 at 1:42 PM kurt greaves  wrote:

> Been thinking about this for a while and agree it's how we should approach
> it. BIkeshedding but seems like a nice big table would be suitable here,
> and I think rather than a separate confluence page per component we just
> create separate JIRA tickets that detail what's being tested and the
> approach, and discussion can be kept in JIRA.
>
Can we let each component group figure out how they want to do project
management with the one caveat that they list the component on the page and
have a tracking ticket with the right label? I think that's the lightest
touch process that will work.


> I'm happy to volunteer for testing repair. I can also add lots of different
> components to the list if you're happy for me to attack the page.
>
Go for it! I just jotted down some seed topics to get it started. Please do
edit and refactor to make it better.

-Joey

Re: 4.0 Testing Signup

[Scott Andreas]

Tommy, thank you! I’ve added your name as a contributor toward upgrade testing.

Thanks also for all of the work you’ve done toward this already, filing 
CASSANDRA-{14820, 14836, 14841, 14842, 14848}. The testing you’ve done so far, 
patches contributed, and issues reported are all great finds.

To edit pages in the wiki space, you’ll need to create an account here: 
https://cwiki.apache.org/confluence/signup.action. After doing that, email me 
(or this list) and I’ll add edit permissions for the wiki space.

[ Also, an apology to Joey and Nate – I tweaked the title of the doc, but 
didn’t realize that would alter the permalink. ]


On November 8, 2018 at 11:34:06 PM, Tommy Stendahl 
(tommy.stend...@ericsson.com) wrote:

Hi,

I like to add myself as contributor under Cluster Upgrade but I could
not edit the page, could you please help.

I have already done some testing in this are lately and created a few
jiras, two remains open CASSANDRA-14842 and CASSANDRA-14848.

Thanks, Tommy

On 2018-11-08 23:30, Joseph Lynch wrote:
> On Thu, Nov 8, 2018 at 11:04 AM Romain Hardouin 
> wrote:
>
>> Hi,
>> I'm volunteer to be contributor on Metrics or Tooling component. Are we
>> supposed/allowed to edit Confluence page directly?Btw I think that tooling
>> should be split, maybe one ticket per tool?
>>
> Awesome! Yes feel free to add yourself as a contributor to whichever
> component you can contribute testing to (I think you need to make an Apache
> confluence account to do so), if it isn't working let me know and I'll add
> your contact information. Right now we don't have a shepherd for either
> component yet but I think it's pretty reasonable to have a tracking ticket
> that either has subtasks for each tool (e.g. CASSANDRA-14746) or just use
> linking (e.g. CASSANDRA-14697). Just try to describe in the tickets what
> kinds of tests you're running and make sure they're tagged with 4.0-QA
> label if possible.
>
> Thanks!
> - Joey
>

JIRA Reports in Confluence

[Scott Andreas]

Hi everyone,

I’ve created several new JIRA reports in Confluence organized under this 
top-level page:
https://cwiki.apache.org/confluence/display/CASSANDRA/Jira+reports

These pages report open issues by Component and fix version. My aims in 
creating them are to:

– Represent what’s currently screened into each upcoming release milestone.
– Break releases down by component to assess health/outstanding work in each.
– Make it easier to identify what’s scoped where (and to gauge release size).
– Create pages that can be used as queues for screening and for patches 
awaiting review.

They may also help structure discussions on release scope and what’s in / 
what’s out. I’ve refrained from updating the “fix version” field on tickets 
this weekend, but hope that these pages can become useful toward doing so as a 
dev community. Additional JIRA grooming is needed before these can support 
scope / timeline discussions on a per-release basis (esp. getting all active 
and planned testing work represented) – but representing the current state of 
things seemed like a prerequisite.

The current reports are:

– 4.0: Open Issues by Component
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0%3A+Open+Issues+by+Component

– 4.0.x: Open Issues by Component
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0.x%3A+Open+Issues+by+Component

– 4.x: Open Issues by Component
https://cwiki.apache.org/confluence/display/CASSANDRA/4.x%3A+Open+Issues+by+Component

– Open Issues by Component (Unscreened)
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97550493

– Patch Available
https://cwiki.apache.org/confluence/display/CASSANDRA/Patch+Available

If you’ve got cabin fever from poor air quality (or just really love screening 
bugs), I’d love help adding components to tickets on the "Open Issues by 
Component - Unscreened” page.

Cheers,

– Scott


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: JIRA Workflow Proposals

[Scott Andreas]

If I read Josh’s reply right, I think the suggestion is to periodically review 
active labels and promote those that are demonstrably useful to components (cf. 
folksonomy -> 
taxonomy<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I 
hadn’t read the reply as indicating that labels should be zero’d out 
periodically. In any case, I agree that reviewing active labels and 
re-evaluating our taxonomy from time to time sounds great; I don’t think I’d 
zero them, though.

Responding to a few comments:

–––

– To Joey’s question about issues languishing in Triage: I like the idea of an 
SLO for the “triage” state. I am happy to commit time and resources to triaging 
newly-reported issues, and to JIRA pruning/gardening in general. I spent part 
of the weekend before last adding components to a few hundred open issues and 
preparing the Confluence reports mentioned in the other thread. It was calming. 
We can also figure out how to rotate / share this responsibility.

– Labels discussion: If we adopt a more structured component hierarchy to treat 
as our primary method of organization, keep labels around for people to use as 
they’d like (e.g., for custom JQL queries useful to their workflows), and 
periodically promote those that are widely useful, I think that sounds like a 
fine outcome.

– On Sankalp’s question of issue reporter / new contributor burden: I actually 
think the pruning of fields on the “new issue form” makes reporting issues 
easier and ensures that information we need is captured. Having the triage step 
will also provide a nice task queue for screening bugs, and ensures a 
contributor’s taken a look + screened appropriately (rather than support 
requests immediately being marked “Critical/Blocker” and assigned a fix version 
by the reporter).

– On Sankalp’s question of the non-committer’s workflow during first pass of 
review, I think that’s covered here: 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow

–––

I also want to step back and thank Benedict and Kurt for all of their analysis 
and information architecture work behind this proposal. "Workflow and bug 
tracker hygiene” can be a thankless endeavor; I want to make sure this one’s 
not. Thank you both!

If we’re nearing consensus on “keeping labels, and considering them for 
promotion to components periodically,” are there other items we need to resolve 
before we generally feel good about the changes?

– Scott


On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
(bened...@apache.org<mailto:bened...@apache.org>) wrote:

Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
confused about your suggestion.

Are you suggesting we periodically clear any new labels, once we have 
replacements, and only leave the old ones that exist today and haven’t been 
categorised?


> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  wrote:
>
> Do we maintain a list of prior rejects? Revisit any that have increased in 
> usage since last?
>
> Probably we’re bike shedding this one thing too closely. I would be happy 
> with removing it, periodically cleaning it, or leaving it intact. Mining it 
> for schema changes, or telling people to ask.
>
> But I fear it will all begin to go to pot again after this effort wanes, and 
> my life has only one JIRA cleanup effort to call upon.
>
>
>> On 26 Nov 2018, at 18:24, Joshua McKenzie  wrote:
>>
>> I'm thinking something like "Every 6 months, we query on labels with count
>>> = 4 and consider promoting those. Anything < that only shows if people are
>> specifically looking for it."
>>
>> Taking count of occurrence of a label as a proxy for the potential value in
>> promoting it to something hardened isn't without flaws, but it's also not
>> awful IMO.
>>
>>
>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith 
>> wrote:
>>
>>>> Is there harm in leaving them in, aside from psychologically to all of us
>>>> knowing they're there? =/
>>>
>>> It would at least make it easier to triage the ‘new' ones and promote
>>> them. The pain of actually categorising the labels was high, and doing
>>> that every time would mean it never happens (though maybe there are ways to
>>> work around this). I also think there’s value in shedding noisy data, in
>>> an active process to promote good hygiene.
>>>
>>> But who said our state of mind isn’t also important :)
>>>
>>> This isn’t something I’ll fight hard for, though, I can see it’s at least
>>> partially a preference for cleanliness. Interested to see what others
>>> think.
>>>
>>>> On 26 Nov 2018, at 17:28, Joshua McKenzie  wrote:

Re: [VOTE] Change Jira Workflow

[Scott Andreas]

+1 non-binding

> On Dec 17, 2018, at 7:28 AM, Marcus Eriksson  wrote:
> 
> +1
> 
> On Mon, Dec 17, 2018 at 03:19:07PM +, Benedict Elliott Smith wrote:
>> I propose these changes 
>> *
>>  to the Jira Workflow for the project.  The vote will be open for 72 hours**.
>> 
>> I am, of course, +1.
>> 
>> * With the addendum of the mailing list discussion 
>> ;
>>  in case of any conflict arising from a mistake on my part in the wiki, the 
>> consensus reached by polling the mailing list will take precedence.
>> ** I won’t be around to close the vote, as I will be on vacation.  Everyone 
>> is welcome to ignore the result until I get back in a couple of weeks, or if 
>> anybody is eager feel free to close the vote and take some steps towards 
>> implementation.
> 
> -
> 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: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Scott Andreas]

Echoing Jon’s point here – 

JH: “My thinking is I'd like to be able to recommend 4.0.0 as a production ready
database for business critical cases”

I feel that this is a standard that is both appropriate and achievable, and one 
I’m legitimately excited about.

Re: the current state of the test plan wiki in Confluence, I owe another pass 
through. There has been a lot of progress here, but I’ve let perfect be the 
enemy of the good in getting updates out. I’ll complete that pass later this 
week.

Cheers,

— Scott

> On May 28, 2019, at 10:48 AM, Dinesh Joshi  wrote:
> 
> +1. Wiki could be useful to document what the overall plan. Jira to track 
> progress.
> 
> Dinesh
> 
>>> On May 28, 2019, at 10:20 AM, Joshua McKenzie  wrote:
>>> 
>>> 
>>> The unofficial rule is to not upgrade to prod till .10 is cut.
>> 
>> FWIW, I believe it's historically .6. Which is still not a great look for
>> the project.
>> 
>> There's a ton of work going into testing 4.0 already.
>> 
>> While I intuitively and anecdotally (from the people I've backchanneled
>> with) believe this to be true as well, the referenced wiki page[1] and
>> jql[2] doesn't look like it's an up to date reflection of the testing
>> efforts going on. Is there another place this information is stored /
>> queryable we can surface to people to keep us all coordinated?
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
>> [2]
>> https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA
>> 
>> On Tue, May 28, 2019 at 12:57 PM sankalp kohli 
>> wrote:
>> 
>>> Hi Jon,
>>>  When you say 4.0 release, how do u match it with 3.0 minor
>>> releases. The unofficial rule is to not upgrade to prod till .10 is cut.
>>> Also due to heavy investment in testing, I dont think it will take as long
>>> as 3.0 but want to know what is your thinking with this.
>>> 
>>> Thanks,
>>> Sankalp
>>> 
>>>> On Tue, May 28, 2019 at 9:40 AM Jon Haddad  wrote:
>>>> 
>>>> Sept is a pretty long ways off.  I think the ideal case is we can
>>> announce
>>>> 4.0 release at the summit.  I'm not putting this as a "do or die" date,
>>> and
>>>> I don't think we need to announce it or make promises.  Sticking with
>>> "when
>>>> it's ready" is the right approach, but we need a target, and this is imo
>>> a
>>>> good one.
>>>> 
>>>> This date also gives us a pretty good runway.  We could cut our first
>>>> alphas in mid June / early July, betas in August and release in Sept.
>>>> There's a ton of work going into testing 4.0 already.
>>>> Landing CASSANDRA-15066 will put us in a pretty good spot.  We've
>>> developed
>>>> tooling at TLP that will make it a lot easier to spin up dev clusters in
>>>> AWS as well as stress test them.  I've written about this a few times in
>>>> the past, and I'll have a few blog posts coming up that will help show
>>> this
>>>> in more details.
>>>> 
>>>> There's some other quality of life things we should try to hammer out
>>>> before then.  Updating our default JVM settings would be nice, for
>>>> example.  Improving documentation (the data modeling section in
>>>> particular), fixing the dynamic snitch issues [1], and some improvements
>>> to
>>>> virtual tables like exposing the sstable metadata [2], and exposing table
>>>> statistics [3] come to mind.  The dynamic snitch improvement will help
>>>> performance in a big way, and the virtual tables will go a long way to
>>>> helping with quality of life.  I showed a few folks virtual tables at the
>>>> Accelerate conference last week and the missing table statistics was a
>>> big
>>>> shock.  If we can get them in, it'll be a big help to operators.
>>>> 
>>>> [1] https://issues.apache.org/jira/browse/CASSANDRA-14459
>>>> [2] https://issues.apache.org/jira/browse/CASSANDRA-14630
>>>> [3] https://issues.apache.org/jira/browse/CASSANDRA-14572
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Mon, May 27, 2019 at 2:36 PM Nate McCall  wrote:
>>>>> 
>>>>> Hi Sumanth,
>>>>> Thank you so much for taking the time to put this to

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Scott Andreas]

Thanks for starting this discussion, Sumanth! Added a round of comments as well.

Summarizing my non-binding feedback: I feel that many of the items under 
"Alpha" and "Beta" should be achieved prior to the release of an alpha, 
especially those related to correctness/safety, scope lock, feature 
completeness, deprecation, and backwards compatibility. Establishing a higher 
standard for official project releases (even at the alpha and beta stage) will 
help us really polish the final build together.

Ideally, I feel that contributors should have completed extensive 
testing/validation to ensure that no critical or severe bugs exist prior to the 
release of an alpha (e.g., data loss, consistency violations, incorrect 
responses to queries, etc). Perhaps we can add a line to this effect. 

Ensuring that we've met that bar prior to alpha will help us focus the final 
stages of the release on gathering feedback from users + developers to validate 
tooling and automation; compatibility with less commonly-used client libraries, 
testing new features, evaluating performance and stability under their 
workloads, etc.

– Scott

On 6/11/19, 6:45 AM, "Sumanth Pasupuleti"  
wrote:

Thanks for the feedback on the product stages/ release life cycle document.
I have incorporated the suggestions and looking for any additional feedback
folks may have.

https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#

Thanks,
Sumanth

    On Tue, May 28, 2019 at 10:43 PM Scott Andreas  wrote:

> Echoing Jon’s point here –
>
> JH: “My thinking is I'd like to be able to recommend 4.0.0 as a production
> ready
> database for business critical cases”
>
> I feel that this is a standard that is both appropriate and achievable,
> and one I’m legitimately excited about.
>
> Re: the current state of the test plan wiki in Confluence, I owe another
> pass through. There has been a lot of progress here, but I’ve let perfect
> be the enemy of the good in getting updates out. I’ll complete that pass
> later this week.
>
> Cheers,
>
> — Scott
>
> > On May 28, 2019, at 10:48 AM, Dinesh Joshi  wrote:
> >
> > +1. Wiki could be useful to document what the overall plan. Jira to
> track progress.
> >
> > Dinesh
> >
> >>> On May 28, 2019, at 10:20 AM, Joshua McKenzie 
> wrote:
> >>>
> >>>
> >>> The unofficial rule is to not upgrade to prod till .10 is cut.
> >>
> >> FWIW, I believe it's historically .6. Which is still not a great look
> for
> >> the project.
> >>
> >> There's a ton of work going into testing 4.0 already.
> >>
> >> While I intuitively and anecdotally (from the people I've backchanneled
> >> with) believe this to be true as well, the referenced wiki page[1] and
> >> jql[2] doesn't look like it's an up to date reflection of the testing
> >> efforts going on. Is there another place this information is stored /
> >> queryable we can surface to people to keep us all coordinated?
> >>
> >> [1]
> >>
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
> >> [2]
> >>
> 
https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA
> >>
> >> On Tue, May 28, 2019 at 12:57 PM sankalp kohli 
> >> wrote:
> >>
> >>> Hi Jon,
> >>>  When you say 4.0 release, how do u match it with 3.0 minor
> >>> releases. The unofficial rule is to not upgrade to prod till .10 is
> cut.
> >>> Also due to heavy investment in testing, I dont think it will take as
> long
> >>> as 3.0 but want to know what is your thinking with this.
> >>>
> >>> Thanks,
> >>> Sankalp
> >>>
> >>>> On Tue, May 28, 2019 at 9:40 AM Jon Haddad  
wrote:
> >>>>
> >>>> Sept is a pretty long ways off.  I think the ideal case is we can
> >>> announce
> >>>> 4.0 release at the summit.  I'm not putting this as a "do or die"
> date,
> >>> and
> >>>> I don't think we need to announce it or make promises.  Sticking with
> >>> "when
> >>>> it's ready" is the right approach

Re: Apache Cassandra Virtual meetings

[Scott Andreas]

On the "virtual" side --

I've spent some time this week reviewing how the Kubernetes community conducts 
their weekly meetings. References are at the end of this message.

If we'd like to hold occasional virtual meetings among the dev and user 
community, here are some things that may help make them successful:

1. Agenda: Discussed and committed on the dev list in advance, published on 
Confluence, with speakers confirmed and topic durations assigned.
2. Video Call: To be dialed into by confirmed speakers, eliminating the need 
for heavy WebEx-style moderation, several minutes of "please mute, everyone 
mute...," or difficulty enforcing ASF code of conduct if someone joins an open 
call in bad faith. Google Meet appears to be free for up to 25 participating / 
presenting in a call.
3. Live stream / broadcast: Google Meet meetings can also be broadcast live to 
YouTube and recorded for non-participating attendees to watch (e.g., via 
EveryCord now that Hangouts on Air is discontinued). This would enable a model 
in which a smaller number of speakers could present, with anyone in the 
community able to join and watch live or at a later time.
4. Moderation: An emcee to introduce the agenda, hold speakers to time to 
ensure discussion on one item doesn't prevent the rest from being reached, and 
represent community Q&A.
5. Community Q&A: We could conduct Q&A with community members via ASF Slack 
during the call – e.g., a moderator reading questions shared via Slack, 
answered by presenters. Text-based Q&A also mitigates the risk of runaway "not 
really a question but more of a comment..." dialogue.
6. Notes: As others mentioned, notes should be prepared (live or after the 
fact) and archived on Confluence alongside the agenda.
7. Decisions: Happen on the dev list, though discussion and consensus-building 
may occur during calls like this.

Hosting / moderating calls like this takes planning and effort, but it seems 
very doable if others feel it would be valuable to our dev and user community. 
Happy to help if so.

– Scott

---

References:
[1] Meeting doc: 
https://github.com/kubernetes/community/blob/master/events/community-meeting.md
[2] Agenda: 
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit#heading=h.en8cy6hno0c6
[3] K8s Zoom Guidelines: 
https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md
[4] K8s Moderation Guidelines: 
https://github.com/kubernetes/community/blob/master/communication/moderation.md
[5] Example recorded meeting: https://www.youtube.com/watch?v=6uZScaWEb08

On 8/9/19, 10:27 AM, "sankalp kohli"  wrote:

@Dinesh/Nate: Yes we need to decide on the timing and we can always change
them as we go
@Joshua/Gary: We will publish notes on the mailing list. If we need to make
a decision, we will still need to get it voted on the ML. We should not
have a case where someone misses the boat because they could not attend one
of these. So ML is a big part of this.

Additional feedback welcome.

On Fri, Aug 9, 2019 at 6:28 AM Gary Dusbabek  wrote:

> Would publishing notes to the ML be sufficient? Apache board meetings work
> this way.
>
> Gary.
>
> On Wed, Aug 7, 2019 at 4:51 PM Nate McCall  wrote:
>
> > We can do the time mostly fair if we alternate back and forth between 
PST
> > morning and evening. This will at least let most folks attend every 
other
> > meeting.
> >
> > I agree with Josh's sentiment on the discussions. We can do it, we just
> > have to be aware of it and defer things to Jira and/or ML.
> >
> > On Thu, Aug 8, 2019 at 12:42 AM Joshua McKenzie 
> > wrote:
> >
> > > The one thing we need to keep in mind is the "If it didn't happen on a
> > > mailing list, it didn't happen <http://theapacheway.com/on-list/>"
> > > philosophy of apache projects. Shouldn't constrain us too much as the
> > > nuance is:
> > >
> > > *"Discussions and plan proposals often happen at events, in chats
> (Slack,
> > > IRC, IM, etc.) or other synchronous places. But all final decisions
> about
> > > executing on the plan, checking in the new code, or launching the
> website
> > > must be made by the community asyncrhonously on the mailing list."*
> > >
> > > So long as we keep that in mind (and maybe push it back to 8am PST
> since
> > > 9am can get pretty ugly for some of the more eastern european / asian
> > > countries), makes sense to me.
> > >
> > > On Tue, Aug 6, 2019 at 6:07 PM Dinesh Joshi  wrote:
> >

Re: Apache Cassandra Virtual meetings

[Scott Andreas]

Maybe not, but it seems important to be ready to. I’d anchored to the Google 
Meet limitation of 25 participants without an Enterprise account (which works 
in the «small-M presenters» × «large-N broadcast» model), but it’s likely that 
more than 25 would like to be able to follow.

Zoom allows up to 100 on a $15/mo plan that includes recordings, which could be 
a good fit and enables a lighter touch to moderation.

> On Aug 9, 2019, at 7:13 PM, Murukesh Mohanan  
> wrote:
> 
> Do we need to moderate heavily from the get-go, or should we implement all
> this after a couple of trial calls to see how bad things are?
> 
> On Sat, 10 Aug 2019, 08:27 Scott Andreas,  wrote:
> 
>> On the "virtual" side --
>> 
>> I've spent some time this week reviewing how the Kubernetes community
>> conducts their weekly meetings. References are at the end of this message.
>> 
>> If we'd like to hold occasional virtual meetings among the dev and user
>> community, here are some things that may help make them successful:
>> 
>> 1. Agenda: Discussed and committed on the dev list in advance, published
>> on Confluence, with speakers confirmed and topic durations assigned.
>> 2. Video Call: To be dialed into by confirmed speakers, eliminating the
>> need for heavy WebEx-style moderation, several minutes of "please mute,
>> everyone mute...," or difficulty enforcing ASF code of conduct if someone
>> joins an open call in bad faith. Google Meet appears to be free for up to
>> 25 participating / presenting in a call.
>> 3. Live stream / broadcast: Google Meet meetings can also be broadcast
>> live to YouTube and recorded for non-participating attendees to watch
>> (e.g., via EveryCord now that Hangouts on Air is discontinued). This would
>> enable a model in which a smaller number of speakers could present, with
>> anyone in the community able to join and watch live or at a later time.
>> 4. Moderation: An emcee to introduce the agenda, hold speakers to time to
>> ensure discussion on one item doesn't prevent the rest from being reached,
>> and represent community Q&A.
>> 5. Community Q&A: We could conduct Q&A with community members via ASF
>> Slack during the call – e.g., a moderator reading questions shared via
>> Slack, answered by presenters. Text-based Q&A also mitigates the risk of
>> runaway "not really a question but more of a comment..." dialogue.
>> 6. Notes: As others mentioned, notes should be prepared (live or after the
>> fact) and archived on Confluence alongside the agenda.
>> 7. Decisions: Happen on the dev list, though discussion and
>> consensus-building may occur during calls like this.
>> 
>> Hosting / moderating calls like this takes planning and effort, but it
>> seems very doable if others feel it would be valuable to our dev and user
>> community. Happy to help if so.
>> 
>> – Scott
>> 
>> ---
>> 
>> References:
>> [1] Meeting doc:
>> https://github.com/kubernetes/community/blob/master/events/community-meeting.md
>> [2] Agenda:
>> https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit#heading=h.en8cy6hno0c6
>> [3] K8s Zoom Guidelines:
>> https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md
>> [4] K8s Moderation Guidelines:
>> https://github.com/kubernetes/community/blob/master/communication/moderation.md
>> [5] Example recorded meeting: https://www.youtube.com/watch?v=6uZScaWEb08
>> 
>> On 8/9/19, 10:27 AM, "sankalp kohli"  wrote:
>> 
>>@Dinesh/Nate: Yes we need to decide on the timing and we can always
>> change
>>them as we go
>>@Joshua/Gary: We will publish notes on the mailing list. If we need to
>> make
>>a decision, we will still need to get it voted on the ML. We should not
>>have a case where someone misses the boat because they could not
>> attend one
>>of these. So ML is a big part of this.
>> 
>>Additional feedback welcome.
>> 
>>On Fri, Aug 9, 2019 at 6:28 AM Gary Dusbabek 
>> wrote:
>> 
>>> Would publishing notes to the ML be sufficient? Apache board
>> meetings work
>>> this way.
>>> 
>>> Gary.
>>> 
>>> On Wed, Aug 7, 2019 at 4:51 PM Nate McCall 
>> wrote:
>>> 
>>>> We can do the time mostly fair if we alternate back and forth
>> between PST
>>>> morning and evening. This will at least let most folks attend
>> every other
>>>> meeting.
>>>> 
>>>> I agree with 

Re: Stability of MaterializedView in 3.11.x | 4.0

[Scott Andreas]

Hi Pankaj,

There aren't plans to include substantial changes to the materialized views 
implementation in C* 4.0, and I'm not aware of project contributors who plan 
major work on MV's post-4.0 at present.

– Scott


From: Pankaj Gajjar 
Sent: Tuesday, September 3, 2019 5:47 AM
To: dev@cassandra.apache.org
Subject: Re: Stability of MaterializedView in 3.11.x | 4.0

Hi Team,

Thanks but this is not point, question again in mind, do we have any plan to 
fix this MVs issue into upcoming any Cassandra release ? 4.0 ? if yes then it 
would be great to wait.
Or is there any plugin or workaround to resolve this issue well on Cassandra 
setup ?


--
Regards
Pankaj G.

On 31/08/19, 00:33, "Jon Haddad"  wrote:

If you don't have any intent on running across multiple nodes, Cassandra is
probably the wrong DB for you.

Postgres will give you a better feature set for a single node.

On Fri, Aug 30, 2019 at 5:23 AM Pankaj Gajjar 

wrote:

> Understand it well, how about Cassandra running on single node, we don’t
> have cluster setup (3 nodes+ i.e).
>
> Does MVs perform well on single node machine ?
>
> Note: I know about HA, so lets keep it side for now and it's only possible
> when we have cluster setup.
>
> On 29/08/19, 06:21, "Dor Laor"  wrote:
>
> On Wed, Aug 28, 2019 at 5:43 PM Jon Haddad  wrote:
>
> > >  Arguably, the other alternative to server-side denormalization is
> to do
> > the denormalization client-side which comes with the same axes of
> costs and
> > complexity, just with more of each.
> >
> > That's not completely true.  You can write to any number of tables
> without
> > doing a read, and the cost of reading data off disk is significantly
> > greater than an insert alone.  You can crush a cluster with a write
> heavy
> > workload and MVs that would otherwise be completely fine to do all
> writes.
> >
> > The other issue with MVs is that you still need to understand
> fundamentals
> > of data modeling, that don't magically solve the problem of enormous
> > partitions.  One of the reasons I've had to un-MV a lot of clusters
> is
> > because people have put an MV on a table with a low-cardinality
> field and
> > found themselves with a 10GB partition nightmare, so they need to go
> back
> > and remodel the view as something more complex anyways.  In this
> case, the
> > MV was extremely high cost since now they've not only pushed out a
> poor
> > implementation to begin with but now have the cost of a migration as
> well
> > as a rewrite.
> >
>
> +1
>
> Moreover, the hard part is that an update for the base table means 
that
> the original data needs to be read and the database (or the poor
> developer
> who implements the denormalized model) needs to delete the data in the
> view
> and then to write the new ones. All need to be of course resilient to
> all
> types of
> errors and failures. Had it been simple, there was no need for a
> database
> MV..
>
>
> >
> >
> >
> > On Wed, Aug 28, 2019 at 9:58 AM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> > > >
> > > > so we need to start migration from MVs to manual query base
> table ?
> > >
> > >  Arguably, the other alternative to server-side denormalization is
> to do
> > > the denormalization client-side which comes with the same axes of
> costs
> > and
> > > complexity, just with more of each.
> > >
> > > Jeff's spot on when he discusses the risk appetite vs. mitigation
> aspect
> > of
> > > it. There's a reason banks do end-of-day close-out validation
> analysis
> > and
> > > have redundant systems for things like this.
> > >
> > > On Wed, Aug 28, 2019 at 11:49 AM Jon Haddad 
> wrote:
> > >
> > > > I've helped a lot of teams (a dozen to two dozen maybe) migrate
> away
> > from
> > > > MVs due to inconsistencies, issues with streaming (have you
> ad

Re: time for a release?

[Scott Andreas]

+1nb for me for the 3.x releases.

The user-facing issues resolved in 2.2 are slimmer and relatively minor (just 
15225, 15050, 15045, 15041), but if it makes sense to release all three 
together, sounds good to me.

– Scott

On 10/4/19, 11:00 AM, "Jon Haddad"  wrote:

It's been a while since we did a release and I think there's enough in here
to put one out.

2.2.15 changes:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%202.2.15%20and%20status%20%3D%20Resolved%20

3.0.19 changes:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.0.19%20and%20status%20%3D%20Resolved%20%20

3.11.5 changes:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.11.5%20and%20status%20%3D%20Resolved%20

Any reason not to put this up for a vote?  If I don't hear anything by
Monday I'll start a vote thread.

Jon

Re: [VOTE] Apache Cassandra Release Lifecycle

[Scott Andreas]

There are two main benefits to agreeing on this:

1. Providing clarity for contributors on release phases – i.e., what types of 
changes are expected to land or be deferred during a particular point in that 
cycle.

2. Providing semantic clarity to users of Cassandra in terms of what they can 
expect from a given release.

The second one is more important. The document stands as a commitment between 
the Cassandra project and its users regarding what can be expected from each 
type of release. It defines GA releases as "recommended for production 
deployment for all users," setting a standard of quality that we aim to uphold 
together and that users can depend on. Affirming what it means for a release to 
be EOL, deprecated, or in maintenance signals importance of upgrading to a GA 
version.

The prerelease phases set expectations for us as contributors to produce a more 
stable release: what type of testing/validation is needed at what time, at 
which point interfaces/protocols solidify, when a release is considered feature 
complete, etc.

Creating clarity for ourselves will help us build a better database, and 
creating clarity for our users will help give them the confidence to run it.

I want to thank Sumanth for his work on this document and to everyone else 
who's contributed.

I support it (+1 nb).

– Scott


From: Stefan Podkowinski 
Sent: Tuesday, October 1, 2019 1:43 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Apache Cassandra Release Lifecycle

What exactly will be the implication of the outcome of this vote, in
case the content is agreed upon? What's the proposal of the voting?

The document seems to be informative rather then formal. It's verbose on
definitions that should be commonly understood or can only broadly
defined (what is alpha/beta/RC, GA for production, etc.), while at the
same time is unclear and weasel-wordy on our actual commitment and rules.


On 30.09.19 20:51, sankalp kohli wrote:
> Hi,
>  We have discussed in the email thread[1] about Apache Cassandra Release
> Lifecycle. We came up with a doc[2] for it. Please vote on it if you agree
> with the content of the doc[2].
>
> Thanks,
> Sankalp
>
> [1]
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
>

-
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: [VOTE-2] Apache Cassandra Release Lifecycle

[Scott Andreas]

+1 nb


From: sankalp kohli 
Sent: Tuesday, October 8, 2019 11:00 AM
To: dev
Subject: [VOTE-2] Apache Cassandra Release Lifecycle

Hi,
We have discussed in the email thread[1] about Apache Cassandra Release
Lifecycle. We came up with a doc[2] for it. We have finalized the doc
here[3] Please vote on it if you agree with the content of the doc [3].

We did not proceed with the previous vote as we want to use confluence for
it. Here is the link for that[4]. It also mentions why we are doing this
vote.

Vote will remain open for 72 hours.

Thanks,
Sankalp

[1]
https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
[2]
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
[3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
Attachments area
[4]
https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE-2] Apache Cassandra Release Lifecycle

[Scott Andreas]

Re: "How can we decide that *all* new features are suppose to go into trunk 
only, if we don’t even have an idea about the upcoming release schedule?"

This is a great question. My understanding of the intent of the document is 
that new features are generally expected to land in trunk, with an exception 
process defined for feature backports. I think that's a reasonable expectation 
to start with. But I also agree with you that it's important we evolve a way to 
discuss and agree up on release scope - this was the focus of my slides at 
NGCC. I would love to discuss this on a separate thread.

Re: “Bug fix releases have associated new minor version.”
"Patchlevel version" might be more in keeping with our current convention.

Re: "We should give users a way to plan, by having EOL dates"
Incorporating EOL dates into our release management / planning is a great idea.

Would you be willing to rephrase your comments in the form of proposed edits to 
the document?

– Scott


From: Stefan Podkowinski 
Sent: Tuesday, October 8, 2019 1:22 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle

 From the document:

General Availability (GA): “A new branch is created for the release with
the new major version, limiting any new feature addition to the new
release branch, with new feature development will continue to happen
only on trunk.”
Maintenance: “Missing features from newer generation releases are
back-ported on per - PMC vote basis.”

We had a feature freeze before 4.0, which showed that people have
different views on what actually qualifies as a feature. It doesn’t work
without defining “feature” in more detail. Although I’d rather avoid to
have this in the document at all, since I don’t think this is getting us
anywhere, without having a clearer picture on the bigger context in
which release are going to happen in the future, starting with release
cadence and support periods. How can we decide that *all* new features
are suppose to go into trunk only, if we don’t even have an idea about
the upcoming release schedule?

“Bug fix releases have associated new minor version.”

So the next bug fix version will be 4.1? There will be no minor feature
releases like we did with 3.x.0/2.x.0?

Deprecated:
"Through a dev community voting process, EOL date is determined for this
release.”
“Users actively encouraged to move away from the offering.”

We should give users a way to plan, by having EOL dates that may be
months or years ahead in the future. We did this with 3.0 and 2.x, which
would be all “deprecated” a long time ago with the new proposal.

Deprecated: “Only security vulnerabilities and production-impacting bugs
without workarounds are addressed.”

Although devs will define their own definition of “production-impacting
bugs without workarounds” in any way they need, I don’t think we should
have this in the document. It’s okay to use EOLed releases and we should
not prevent users from contributing smaller fixes, performance
improvements and useful enhancements for minor feature releases.

On 08.10.19 20:00, sankalp kohli wrote:
> Hi,
>  We have discussed in the email thread[1] about Apache Cassandra Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].
>
> We did not proceed with the previous vote as we want to use confluence for
> it. Here is the link for that[4]. It also mentions why we are doing this
> vote.
>
> Vote will remain open for 72 hours.
>
> Thanks,
> Sankalp
>
> [1]
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Attachments area
> [4]
> https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> <https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#heading=h.633eppni91tw>
>

-
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: moving the site from SVN to git

[Scott Andreas]

Thanks, Jon!


From: Jon Haddad 
Sent: Thursday, October 17, 2019 7:07 AM
To: dev@cassandra.apache.org
Subject: Re: moving the site from SVN to git

The migration is finished.

I had to fix a few things along the way.  The docker containers didn't
build correctly (based on debian:latest rather than a fixed tag), and the
site had to be served out of the content directory rather than the publish
one we were using.

I'm going to address a couple things as follow ups.  We still point people
to IRC, I'll update that to slack.  Longer term I'll migrate it to Hugo,
which will make the entire process a lot easier.

Jon



On Wed, Oct 9, 2019 at 10:26 PM Jon Haddad  wrote:

> OK, I checked with INFRA on some details and will finish the migration
> tomorrow.
>
> On Thu, Oct 3, 2019 at 11:32 AM Jon Haddad  wrote:
>
>> Awesome, thanks Michael.
>>
>> We need to do a little bit of additional configuration to have it switch
>> over.  Specifically, we need to set up the .asf.yaml config to tell the
>> servers how the site should be published.  I can take care of it
>> tomorrow.
>>
>> Reference:
>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Publishingabranchtoyourprojectwebsite
>>
>> On Thu, Oct 3, 2019 at 10:57 AM Michael Shuler 
>> wrote:
>>
>>> committed! :)
>>>
>>> https://gitbox.apache.org/repos/asf?p=cassandra-website.git
>>>
>>> Michael
>>>
>>> On 10/3/19 12:22 PM, Jon Haddad wrote:
>>> > I think we can safely ignore them.  Thanks for figuring this out.
>>> >
>>> > On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler >> >
>>> > wrote:
>>> >
>>> >> I'm making progress through many periodic timeouts to svn.a.o and
>>> >> restarts, but it appears that svn2git is smart enough to pick up where
>>> >> it left off. The first commit captured at the svn path I'm specifying
>>> is
>>> >> when Cassandra was moved to a top level project at r922689
>>> (2010-03-13).
>>> >> I don't know the old incubator path, and it's probably OK to ignore
>>> the
>>> >> few older incubator commits? I imagine it would mean starting over the
>>> >> entire import to pull in those older incubator svn commits, then
>>> >> changing the url and somehow importing the newer path on top?
>>> >>
>>> >> I tried using a local path as the source to try to speed things up,
>>> >> after I got my first few timeouts, but that fails.
>>> >>
>>> >> Curious if anyone really cares if we lose a few early commits - if
>>> so, I
>>> >> can try to figure out the old path and start again.
>>> >>
>>> >> Michael
>>> >>
>>> >> On 10/3/19 11:14 AM, Jon Haddad wrote:
>>> >>> Thanks for taking a look, Michael.  Hopefully you have better luck
>>> than
>>> >> me
>>> >>> :)
>>> >>>
>>> >>> On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler <
>>> mich...@pbandjelly.org>
>>> >>> wrote:
>>> >>>
>>>  I cloned the empty cassandra-website git repo, and I'm running:
>>> 
>>>  svn2git http://svn.apache.org/repos/asf/cassandra/site
>>> --rootistrunk
>>>  --no-minimize-url
>>> 
>>>  ..to see what I get. An svn checkout of the above url says it's only
>>>  69M, so I suppose it's pulling all history of all time for all
>>> projects?
>>> 
>>>  I'll let this roll for a while I run an errand and report back!
>>> 
>>>  Michael
>>> 
>>>  On 10/2/19 9:30 PM, Jon Haddad wrote:
>>> > Daniel referred me to the GitBox self service system.
>>> >
>>> > I've attempted to port the site over using the tool Michael
>>> suggested,
>>>  but
>>> > after a couple hours it died with this message:
>>> >
>>> > command failed: r922600
>>> > git checkout -f master
>>> >
>>> > If either of you (Mick or Michael) want to give svn2git a shot
>>> maybe
>>>  you'll
>>> > get a different result.I think it may have been due to the
>>> large
>>> >> size
>>> > of the repo and the small drive on the VM I was using.  I can try
>>> it
>>>  again
>>> > tomorrow with more storage to see if I get a better result.  Mick
>>> if
>>> >> you
>>> > want to give it a shot in the meantime that would be appreciated.
>>> >
>>> > Jon
>>> >
>>> > On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad 
>>> wrote:
>>> >
>>> >> I created an INFRA ticket here:
>>> >> https://issues.apache.org/jira/browse/INFRA-19218.
>>> >>
>>> >> On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler <
>>> >> mich...@pbandjelly.org>
>>> >> wrote:
>>> >>
>>> >>> I see no good reason to trash history. There are tools to make
>>> moving
>>> >>> from svn to git (hopefully) painless. We used git-svn for the
>>> main c*
>>> >>> source to retain history of both, which this tool uses to do
>>> >> migrations
>>> >>> - https://github.com/nirvdrum/svn2git
>>> >>>
>>> >>> Michael
>>> >>>
>>> >>> On 9/25/19 12:57 AM, Mick Semb Wever wrote:
>>> 
>>> > Personally, no, I don't. 

Re: Can we kick off a release?

[Scott Andreas]

Yes, we should also make sure to include:

CASSANDRA-15363: Read repair in mixed mode between 2.1 and 3.0 on COMPACT 
STORAGE tables causes unreadable sstables after upgrade

This is currently r=2 and about ready to land.


From: beggles...@apple.com  on behalf of Blake Eggleston 

Sent: Wednesday, October 23, 2019 8:12 AM
To: dev@cassandra.apache.org
Subject: Re: Can we kick off a release?

Looks like 15193 has been committed. Are we waiting on anything else before 
cutting the next set of releases?

> On Oct 8, 2019, at 1:11 PM, Jon Haddad  wrote:
>
> I forgot to mention, we should also release alpha2 of 4.0.
>
>
> On Tue, Oct 8, 2019 at 1:04 PM Michael Shuler 
> wrote:
>
>> Thanks Sam, I'm following #15193 and should catch the status change there.
>>
>> Michael
>>
>> On Tue, Oct 8, 2019 at 6:17 AM Sam Tunnicliffe  wrote:
>>>
>>> CASSANDRA-15193 just got +1’d yesterday and would be good to include in
>> the 3.0 and 3.11 releases. If you don’t mind holding off while I add a
>> cqlsh test and merge it, that’d be good.
>>>
>>> Thanks,
>>> Sam
>>>
 On 7 Oct 2019, at 22:54, Michael Shuler 
>> wrote:

 Will do! I probably won't get this done this evening, so will send out
 the emails tomorrow.

 Thanks,
 Michael

 On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
>
> Michael,
>
> Would you mind kicking off builds and starting a vote thread for the
>> latest
> 2.2, 3.0 and 3.11 builds?
>
> Much appreciated,
> Jon

 -
 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
>>
>>


-
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: [VOTE] Release Apache Cassandra 3.0.19

[Scott Andreas]

+1 nb

— Scott

> On Oct 24, 2019, at 7:09 PM, Dinesh Joshi  wrote:
> 
> +1
> 
> Thanks, Michael!
> 
> Dinesh
> 
>> On Oct 24, 2019, at 10:25 AM, Michael Shuler  wrote:
>> 
>> I propose the following artifacts for release as 3.0.19.
>> 
>> sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1183/org/apache/cassandra/apache-cassandra/3.0.19/
>> Staging repository: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1183/
>> 
>> The Debian and RPM packages are available here: 
>> http://people.apache.org/~mshuler
>> 
>> The vote will be open for 72 hours (longer if needed).
>> 
>> [1]: CHANGES.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.19-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.19-tentative
>> 
>> -
>> 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: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

[Scott Andreas]

+1 nb

> On Nov 1, 2019, at 5:36 AM, Benedict Elliott Smith  
> wrote:
> 
> +1
> 
> On 01/11/2019, 12:33, "Mick Semb Wever"  wrote:
> 
>Please vote on accepting the Cassandra Enhancement Proposal (CEP) document 
> as a starting point and guide towards improving collaboration on, and success 
> of, new features and significant improvements. In combination with the 
> recently accepted Cassandra Release Lifecycle documentation this should help 
> us moving forward as a project and community.
> 
>https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 
> 
>Past discussions on the document/process have been touched on in a number 
> of threads in the dev ML.  The most recent thread was 
> https://lists.apache.org/thread.html/b5d1b1ca99324f84e4a40b9cba879e8f858f5f6e18447775fcf32155@%3Cdev.cassandra.apache.org%3E
> 
>regards,
>Mick
> 
>-
>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: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

[Scott Andreas]

Hi Michael,

Unfortunately not; ASF recorded the keynotes but video/streaming facilities 
weren't available for the individual tracks.

A copy of the slides are uploaded here:
https://github.com/ngcc/ngcc2019/blob/master/Committing%20to%20our%20Users%20-%20Product%20and%20Release%20Management%20in%20Apache%20Cassandra.pdf

I also have a version with messy presenters' notes. I'll clean these up and put 
them on Confluence. The outline and notes cover all of the presentation's 
content in detail so the delta between "being there" and "reading the notes" 
should be minimal.


From: Michael Shuler  on behalf of Michael Shuler 

Sent: Friday, November 1, 2019 9:09 AM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

+1

Scott, was your NGCC talk videoed and uploaded anywhere? I would love to
watch, since I missed the event.

Kind regards,
Michael

On 11/1/19 9:07 AM, Scott Andreas wrote:
> +1 nb
>
>> On Nov 1, 2019, at 5:36 AM, Benedict Elliott Smith  
>> wrote:
>>
>> +1
>>
>> On 01/11/2019, 12:33, "Mick Semb Wever"  wrote:
>>
>> Please vote on accepting the Cassandra Enhancement Proposal (CEP) 
>> document as a starting point and guide towards improving collaboration on, 
>> and success of, new features and significant improvements. In combination 
>> with the recently accepted Cassandra Release Lifecycle documentation this 
>> should help us moving forward as a project and community.
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>>
>> Past discussions on the document/process have been touched on in a 
>> number of threads in the dev ML.  The most recent thread was 
>> https://lists.apache.org/thread.html/b5d1b1ca99324f84e4a40b9cba879e8f858f5f6e18447775fcf32155@%3Cdev.cassandra.apache.org%3E
>>
>> regards,
>> Mick
>>
>> -
>> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Offering some project management services

[Scott Andreas]

Happy to add detail on the origin of this from my side –

At NGCC 2019 alongside ApacheCon in Las Vegas this year, I proposed the idea of 
periodic public video calls and an approach toward executing on the roles of 
product and release management as a community of volunteers. The thesis of the 
presentation was that "we can perform the functions of [product and release] 
management as volunteers and the project’s governance can help support it" 
(quoting my presenters' notes), attached.

The presentation also proposed periodic public video calls among contributors, 
and ideally among the user community:

–––
* Public video calls
– Moderated, published agenda, recorded, and hosts rotated.
– Emcee owns timekeeping and execution of meeting agenda.
– Low-fi: light on prep and production value.
– Could be applied either among contributors or Cassandra users.
–––

After the presentation, Patrick came up to me and generously offered to donate 
the use of a Zoom account to host such a call among contributors. A 
hypothetical agenda might look like covering the status of tickets screened to 
4.0, the status of test/qualification plans on Confluence, a quick check-in on 
the 3.0 and 3.11 branches, and recognizing recent contributions from community 
members (such as thanking folks like Mick for the work he's done on CI). 
Patrick and I would be thrilled to help organize this and think such calls 
would help us work better together as contributors if the PMC values that as a 
contribution.

So I may be responsible for this controversy – but I am proud to be if so.

I apologize if we've gone about this improperly, but if so it's only because 
learning the proper way is terribly difficult - even when in regular 
conversation with many members of the PMC and including on this very topic. If 
the PMC would like to discuss privately how community members can be chartered 
to lead initiatives like discussions on scope and release management and/or 
periodic community calls, it looks like several in this thread would be eager 
to contribute.

I believe that each contributor on this thread means well, and think it's 
essential we work toward every goal that's been stated in this thread.

Link to slides in case attachments are stripped by the mailing list: 
https://github.com/ngcc/ngcc2019/blob/master/Committing%20to%20our%20Users%20-%20Product%20and%20Release%20Management%20in%20Apache%20Cassandra.pdf

Cheers,

– Scott


From: Benedict Elliott Smith 
Sent: Friday, January 10, 2020 6:05 PM
To: dev@cassandra.apache.org
Subject: Re: Offering some project management services

To be clear, as it seems like I'm being very negative here, I'm really pleased 
to see DataStax suddenly increase their participation, even if currently it's 
limited to administrative activities.  But let's try really hard to do things 
in the right way.

https://www.apache.org/foundation/governance/pmcs.html#meetings

Community and meetings are explicitly within the intended purview of the PMC.  
The Cassandra PMC ordinarily implicitly devolves decision-making to the dev 
list, so a lack of formal role is no impediment to participation _here on the 
devlist_ but making decisions off-list amongst a cohort lacking _any_ formal 
members of the community is a particularly bad look IMO, and the kind of 
indifference to "The Apache Way" that lead to the fallout with DataStax many 
moons ago.

In this case, Patrick said "we've decided we're running a contributor meeting 
on this date" which starts to look like an attempt - however unintentional - to 
make decisions about community and collaboration _for_ the project.

Instead, IMO, presenting a clear proposal to the community about how this could 
happen, giving it due time to respond and consider (and probably mostly express 
gratitude!) is the right way to do it.  It might lead to tweaks, it might lead 
to minor preconditions about process, it might lead to nothing.  But that's how 
these kinds of things should happen, even ignoring the ASF stuff, if only out 
of politeness.


On 11/01/2020, 01:52, "J. D. Jordan"  wrote:

Isn’t doing such things the way people who are not writing code become part 
of a project?  By offering their time to do things that benefit the project?

Why does anyone “with a formal role” need to agree that Patrick is allowed 
to use his time to try and get some people together to discuss contributing?

-Jeremiah Jordan
Person with no formal role in the Apache Cassandra project.

> On Jan 10, 2020, at 7:44 PM, Benedict Elliott Smith  
wrote:
>
> This is also great.  But it's a bit of a weird look to have two people, 
neither of whom have formal roles on the project, making decisions like this 
without the involvement of the community.  I'm sure everyone will be 
supportive, but it would help to d

Re: Cassandra 4.0 Dev Work Status

[Scott Andreas]

I think the intent of the milestones is meant to indicate that contributors 
view completion of those items as exit criteria for alpha / beta / RC; not 
necessarily that all items will be completed in strict order.

In principle I'd interpret work targeting earlier milestones as higher 
priority, but am generally glad to see any contribution that helps us close 
items in any pre-release milestone. :-)


From: Mick Semb Wever 
Sent: Tuesday, January 14, 2020 10:27 AM
To: dev@cassandra.apache.org
Subject: Re: Cassandra 4.0 Dev Work Status



>- *Progress: *We've closed out 18 issues
>
> 
>in the past 4 weeks of a total of 115 tickets
> across
>4.0-alpha, 4.0-beta, and 4.0.
>


 shouldn't we only have issues closed in 4.0-alpha, given we are not yet at 
4.0-beta and 4.0 ?

-
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: Cassandra 4.0 Dev Work Status

[Scott Andreas]

Just realized I'd misunderstood Mick's original email, apologies.

I'd originally interpreted it as a question of prioritization, but the intent 
was to ensure that the Fix Version field reflects the release a given change is 
/included in/, not /originally targeted for/. Apologies for my misunderstanding.

Agreed yes; it'd make sense to update recently-committed items that have a 
future fix version to indicate they were resolved during alpha. I haven't seen 
fix version refer to specific alpha releases (given that there's just one at 
the moment), but agree that it would be useful to differentiate between which 
alpha/beta/RC build a given change lands in.

Thanks Mick!

– Scott


From: Mick Semb Wever 
Sent: Tuesday, January 14, 2020 12:44 PM
To: dev@cassandra.apache.org
Subject: Re: Cassandra 4.0 Dev Work Status


> I think the intent of the milestones is meant to indicate that
> contributors view completion of those items as exit criteria for alpha
> / beta / RC; not necessarily that all items will be completed in strict
> order.


Yeah, though there's a nuance here between the ticket milestone when it is open 
and the version it becomes available in.

That is milestones are indicated by the fixVersions field while a ticket is 
open, and with the ".x" suffixed versions.

And when the ticket gets resolved/closed the fixVersion is then updated to the 
exact version it becomes available in.

But given that we don't actually have those exact alpha1, alpha2, etc versions, 
maybe i missed a piece of info along the way, and this isn't true for the 
alpha/beta/RCs ?



-
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: Apache Cassandra Contributor Meeting

[Scott Andreas]

Thanks Jordan!

Added a couple more items as well:
– Call for volunteers to lead 4.0 quality tracks that need an owner
– 3.0 / 3.11 branch status


From: Jordan West 
Sent: Monday, January 20, 2020 7:27 PM
To: dev@cassandra.apache.org
Subject: Re: Apache Cassandra Contributor Meeting

Thanks Patrick. Looking forward to tomorrow’s meeting. I added an agenda
item around 4.0 — it’s not my intention to lead that section necessarily
but I think a check in / progress update / follow up on Josh’s email will
be good to cover.

Jordan

On Mon, Jan 13, 2020 at 6:11 PM Patrick McFadin  wrote:

> And I sent this without saying when. Let me save you a click on the
> confluence link.
>
> January 21, 1PM PST
>
> On Mon, Jan 13, 2020 at 5:28 PM Patrick McFadin 
> wrote:
>
> > Hi everyone,
> >
> > In order to catch up on what's happening here, here's the establishing
> > thread:
> >
> https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
> >
> > Key points that Scott Andreas proposed in the initial email was
> >
> > Motivation for such a meeting
> > 1. We currently have Slack, JIRA and emails however an agenda driven
> video
> > meeting can help facilitate alignment within the community.
> > 2. This will give an opportunity to the community to summarize past
> > progress and talk about future tasks.
> > 3. Agenda notes can serve as newsletters for the community.
> >
> > To that, I humbly offer my services as a community organizer to help with
> > the logistics and setup. I'm happy to say this is finally happening and I
> > apologize this has taken so long. I saw some of the examples mentioned in
> > the original thread for other open source projects and I "borrowed"
> heavily
> > from them.
> >
> > I created a page in the Cassandra Confluence page to hopefully centralize
> > both logistics and records of each call. You can fine it here:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting
> >
> > The meetings are on Zoom and set to be wide open. Anyone can join via
> > computer or phone. I'm using a tier that allows for 100 participants. If
> we
> > need more, I can change the type of meeting but it's more of a pain for
> > logistics. We can try this and see how it goes. Once the meeting starts
> > I'll hit record, I'll post the video on YouTube and add the link to the
> > notes. All meeting notes for each agenda items can live in the doc above
> > and remain as a permanent record. After the meeting, I'll send the notes
> > link to the dev list as a reminder that it happened to anyone subscribed.
> >
> > If you have agenda items, please edit the Confluence page and add your
> > name and what you would like discussed.
> >
> > My contribution here is as an organizer. Please feel free to email or
> > Slack if you need anything. Most important, a video meet is an alpha
> > product and we'll learn a lot from the first time trying. I'll try to
> keep
> > note of things to improve in the doc.
> >
> > See you there,
> >
> > Patrick
> >
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Apache Cassandra Contributor Meeting

[Scott Andreas]

Hi Laxmikant,

Thanks for reaching out. The meeting was recorded; I think the video is being 
prepared now. Patrick can probably share a link when ready + uploaded.

Draft notes from the meeting are available here and will be migrated to 
Confluence shortly (likely tomorrow): 
https://docs.google.com/document/d/1Us7y1zgntklNgqcNBAK8bGWDUSb5BhB5MprOSl3500w/edit

– Scott

> On Jan 21, 2020, at 9:20 PM, Laxmikant Upadhyay  
> wrote:
> 
> Please share the recording link if the meeting was recorded. Also could not
> find the MoM on shared confluence link.
> 
> regards,
> Laxmikant
> 
> On Tue, Jan 21, 2020 at 9:39 PM Scott Andreas  wrote:
> 
>> Thanks Jordan!
>> 
>> Added a couple more items as well:
>> – Call for volunteers to lead 4.0 quality tracks that need an owner
>> – 3.0 / 3.11 branch status
>> 
>> 
>> From: Jordan West 
>> Sent: Monday, January 20, 2020 7:27 PM
>> To: dev@cassandra.apache.org
>> Subject: Re: Apache Cassandra Contributor Meeting
>> 
>> Thanks Patrick. Looking forward to tomorrow’s meeting. I added an agenda
>> item around 4.0 — it’s not my intention to lead that section necessarily
>> but I think a check in / progress update / follow up on Josh’s email will
>> be good to cover.
>> 
>> Jordan
>> 
>> On Mon, Jan 13, 2020 at 6:11 PM Patrick McFadin 
>> wrote:
>> 
>>> And I sent this without saying when. Let me save you a click on the
>>> confluence link.
>>> 
>>> January 21, 1PM PST
>>> 
>>> On Mon, Jan 13, 2020 at 5:28 PM Patrick McFadin 
>>> wrote:
>>> 
>>>> Hi everyone,
>>>> 
>>>> In order to catch up on what's happening here, here's the establishing
>>>> thread:
>>>> 
>>> 
>> https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
>>>> 
>>>> Key points that Scott Andreas proposed in the initial email was
>>>> 
>>>> Motivation for such a meeting
>>>> 1. We currently have Slack, JIRA and emails however an agenda driven
>>> video
>>>> meeting can help facilitate alignment within the community.
>>>> 2. This will give an opportunity to the community to summarize past
>>>> progress and talk about future tasks.
>>>> 3. Agenda notes can serve as newsletters for the community.
>>>> 
>>>> To that, I humbly offer my services as a community organizer to help
>> with
>>>> the logistics and setup. I'm happy to say this is finally happening
>> and I
>>>> apologize this has taken so long. I saw some of the examples mentioned
>> in
>>>> the original thread for other open source projects and I "borrowed"
>>> heavily
>>>> from them.
>>>> 
>>>> I created a page in the Cassandra Confluence page to hopefully
>> centralize
>>>> both logistics and records of each call. You can fine it here:
>>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting
>>>> 
>>>> The meetings are on Zoom and set to be wide open. Anyone can join via
>>>> computer or phone. I'm using a tier that allows for 100 participants.
>> If
>>> we
>>>> need more, I can change the type of meeting but it's more of a pain for
>>>> logistics. We can try this and see how it goes. Once the meeting starts
>>>> I'll hit record, I'll post the video on YouTube and add the link to the
>>>> notes. All meeting notes for each agenda items can live in the doc
>> above
>>>> and remain as a permanent record. After the meeting, I'll send the
>> notes
>>>> link to the dev list as a reminder that it happened to anyone
>> subscribed.
>>>> 
>>>> If you have agenda items, please edit the Confluence page and add your
>>>> name and what you would like discussed.
>>>> 
>>>> My contribution here is as an organizer. Please feel free to email or
>>>> Slack if you need anything. Most important, a video meet is an alpha
>>>> product and we'll learn a lot from the first time trying. I'll try to
>>> keep
>>>> note of things to improve in the doc.
>>>> 
>>>> See you there,
>>>> 
>>>> Patrick
>>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
> 
> -- 
> 
> regards,
> Laxmikant Upadhyay


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Apache Cassandra Contributor Meeting

[Scott Andreas]

Patrick's added the recording and linked it via the wiki:
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting

Here's a direct link:
https://www.youtube.com/watch?v=DprX7Y5v30M&feature=emb_logo

Thanks, Patrick!

____
From: Scott Andreas 
Sent: Tuesday, January 21, 2020 9:58 PM
To: dev@cassandra.apache.org
Cc: Jordan West
Subject: Re: Apache Cassandra Contributor Meeting

Hi Laxmikant,

Thanks for reaching out. The meeting was recorded; I think the video is being 
prepared now. Patrick can probably share a link when ready + uploaded.

Draft notes from the meeting are available here and will be migrated to 
Confluence shortly (likely tomorrow): 
https://docs.google.com/document/d/1Us7y1zgntklNgqcNBAK8bGWDUSb5BhB5MprOSl3500w/edit

– Scott

> On Jan 21, 2020, at 9:20 PM, Laxmikant Upadhyay  
> wrote:
>
> Please share the recording link if the meeting was recorded. Also could not
> find the MoM on shared confluence link.
>
> regards,
> Laxmikant
>
> On Tue, Jan 21, 2020 at 9:39 PM Scott Andreas  wrote:
>
>> Thanks Jordan!
>>
>> Added a couple more items as well:
>> – Call for volunteers to lead 4.0 quality tracks that need an owner
>> – 3.0 / 3.11 branch status
>>
>> 
>> From: Jordan West 
>> Sent: Monday, January 20, 2020 7:27 PM
>> To: dev@cassandra.apache.org
>> Subject: Re: Apache Cassandra Contributor Meeting
>>
>> Thanks Patrick. Looking forward to tomorrow’s meeting. I added an agenda
>> item around 4.0 — it’s not my intention to lead that section necessarily
>> but I think a check in / progress update / follow up on Josh’s email will
>> be good to cover.
>>
>> Jordan
>>
>> On Mon, Jan 13, 2020 at 6:11 PM Patrick McFadin 
>> wrote:
>>
>>> And I sent this without saying when. Let me save you a click on the
>>> confluence link.
>>>
>>> January 21, 1PM PST
>>>
>>> On Mon, Jan 13, 2020 at 5:28 PM Patrick McFadin 
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> In order to catch up on what's happening here, here's the establishing
>>>> thread:
>>>>
>>>
>> https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
>>>>
>>>> Key points that Scott Andreas proposed in the initial email was
>>>>
>>>> Motivation for such a meeting
>>>> 1. We currently have Slack, JIRA and emails however an agenda driven
>>> video
>>>> meeting can help facilitate alignment within the community.
>>>> 2. This will give an opportunity to the community to summarize past
>>>> progress and talk about future tasks.
>>>> 3. Agenda notes can serve as newsletters for the community.
>>>>
>>>> To that, I humbly offer my services as a community organizer to help
>> with
>>>> the logistics and setup. I'm happy to say this is finally happening
>> and I
>>>> apologize this has taken so long. I saw some of the examples mentioned
>> in
>>>> the original thread for other open source projects and I "borrowed"
>>> heavily
>>>> from them.
>>>>
>>>> I created a page in the Cassandra Confluence page to hopefully
>> centralize
>>>> both logistics and records of each call. You can fine it here:
>>>>
>>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting
>>>>
>>>> The meetings are on Zoom and set to be wide open. Anyone can join via
>>>> computer or phone. I'm using a tier that allows for 100 participants.
>> If
>>> we
>>>> need more, I can change the type of meeting but it's more of a pain for
>>>> logistics. We can try this and see how it goes. Once the meeting starts
>>>> I'll hit record, I'll post the video on YouTube and add the link to the
>>>> notes. All meeting notes for each agenda items can live in the doc
>> above
>>>> and remain as a permanent record. After the meeting, I'll send the
>> notes
>>>> link to the dev list as a reminder that it happened to anyone
>> subscribed.
>>>>
>>>> If you have agenda items, please edit the Confluence page and add your
>>>> name and what you would like discussed.
>>>>
>>>> My contribution here is as an organizer. Please feel free to email or
>>>> Slack if you need anything. Most important, a video meet is an alpha
>>>> product and we'll learn a lot from the first time trying. I'll try to
>>> keep
>>>> note of things to improve in the doc.
>>>>
>>>> See you there,
>>>>
>>>> Patrick
>>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
>
> --
>
> regards,
> Laxmikant Upadhyay


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Feedback from the last Apache Cassandra Contributor Meeting

[Scott Andreas]

Thank you, Patrick!

> On Feb 11, 2020, at 3:05 PM, Patrick McFadin  wrote:
> 
> Survey is closed. Thank you everyone that took time to give your feedback.
> Here are the results: https://www.surveymonkey.com/results/SM-7YTMZYLT7/
> 
> Based on the feedback, these meetings are useful and this seems to be the
> ideal format:
> 
> 1 Hour scheduled
> Monthly
> Rotate through 10AM-1PM PST to try to cover as many time zones as possible.
> 
> Excellent suggestion was to pre-determine a scribe for the meeting notes.
> I'll add that to the meeting setup in cwiki.
> 
> I'll get the meetings calendared for the next 6 months based on those
> criteria and update the cwiki as needed.
> 
> Thanks again!
> 
> Patrick
> 
>> On Mon, Feb 10, 2020 at 9:28 AM Patrick McFadin  wrote:
>> 
>> Just a Monday reminder on the survey link I sent. I got a few responses
>> but could use a few more to give us some decent N. If you have < 5minutes
>> today, I would appreciate your feedback. I'll keep it open until tomorrow
>> and then send results.
>> 
>> Patrick
>> 
>>> On Mon, Feb 3, 2020 at 4:21 PM Patrick McFadin  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> One action item I took from our first contributor meeting was gather
>>> feedback for the next meetings. I've created a short survey if you would
>>> like to offer feedback. I'll let it run for the week and report back on the
>>> results.
>>> 
>>> https://www.surveymonkey.com/r/C95B7ZP
>>> 
>>> Thanks,
>>> 
>>> Patrick
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Idea: Marking required scope for 4.0 GA vs. optional

[Scott Andreas]

Yep that makes sense to me.

There's still much work to be done to exercise 4.0 builds to identify unknown 
issues that haven't yet been filed – but those items can be tagged as release 
blockers as they're identified. 👍


From: Joshua McKenzie 
Sent: Saturday, March 28, 2020 7:14 AM
To: dev@cassandra.apache.org
Subject: Idea: Marking required scope for 4.0 GA vs. optional

As we're under a feature freeze but not code freeze, there are quite
reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look like
nice to haves for the release but wouldn't necessarily block cutting GA. I
think there would be value in us flagging tickets that are required for 4.0
to get out the door as blockers - it looks like we don't have the Priority
entry anymore (a good thing imo) but we could use the label field to
indicate which tickets are blockers and filter our JIRA board and weekly
reporting on that. That would also help contributors know where to focus
their efforts to help get 4.0 out the door while not stifling people
scratching their own itch on things leading up to the release.

What do the rest of you on the project think?

~Josh

Re: Discussion: addition to CEP guide

[Scott Andreas]

Sounds good to me as well, thanks for suggesting.


From: Jon Haddad 
Sent: Wednesday, April 22, 2020 9:54 AM
To: dev@cassandra.apache.org
Subject: Re: Discussion: addition to CEP guide

Great idea Josh, +1

On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith 
wrote:

> +1.  This might also serve to produce specific points of discussion around
> the topic as the CEP progresses.
>
> Maybe put it high up the list, e.g. after Description of Approach?
>
>
>
> On 22/04/2020, 17:40, "Joshua McKenzie"  wrote:
>
> Link to CEP guide:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>
> Currently the CEP guide reads:
> ---
>
> *A CEP should contain the following sections: *
>
>-
>
>*Scope,*
>-
>
>*Goals (and non-goals),*
>-
>
>*Description of Approach,*
>-
>
>*Timeline,*
>-
>
>*Mailing list / Slack channels,*
>-
>
>*Related JIRA tickets.*
>
> --
> What does everyone think about adding another bullet item as follows:
>
>- A test plan covering performance, correctness, failure, and
> boundary
>conditions (as applicable)
>
> --
> Or some variation thereof. I personally think it's worth calling out
> "We
> should think about and discuss how we're going to test something from a
> high level collectively before we dive into it", since we've had some
> pain
> in the past in that area.
>
> Thoughts?
>
>
>
>
> -
> 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: List of serious issues fixed in 3.0.x

[Scott Andreas]

Sankalp, thanks for sending the spreadsheet and Josh for preparing this 
analysis (pending image issues; look forward to reading)!

I'd encourage everyone involved in the project to review the list of tickets 
captured here. These issues aren't theoretical and represent real scenarios 
that result in data loss, data corruption, incorrect responses to queries, and 
other violations of fundamental properties of the database.

As a community, we've made great progress over the past two years. The focus on 
quality has dramatically improved the safety of Cassandra as a database -- 
especially in the most recent patchlevel releases of the 3.0.x and 3.11.x 
series.

That said, we're also not out of the woods. The following three issues have 
been reported and confirmed genuine in the past week:

– CASSANDRA-15789: Rows can get duplicated in mixed major-version clusters and 
after full upgrade
– CASSANDRA-15778: CorruptSSTableException after a 2.1 SSTable is upgraded to 
3.0, failing reads
– CASSANDRA-15790: EmptyType doesn't override writeValue so could attempt to 
write bytes when expected not to

Regarding Dinesh's point on regression tests, we're beginning to go even 
further. In response to the issues in this spreadsheet, we're evolving new 
approaches toward *active assertion* of data integrity. C-15789 adds 
read/repair/compaction-path detection of primary key duplication, a great way 
to audit and remediate instances of corruption detected in a cluster. Repaired 
data tracking introduced in C-14145 and improvements to Preview Repair are also 
great examples, enabling Cassandra to assert the consistency of repaired data 
(something we'd taken for granted). Active assertion of data integrity 
invariants in Cassandra is an important frontier -- and one we need to explore 
further.

Previously-adopted methodologies like property-based testing, large-scale diff 
tests asserting identity of data between 2.1- and 3.0.x clusters post-upgrade 
via billions of randomized queries, fault injection, model-based tests, CI 
improvements, and flaky test reduction have helped us make huge progress toward 
quality and continue to pay dividends.

I want to thank everyone for their work on safety and stability. It's clear we 
have more ahead, but it's critical to Apache Cassandra's future and toward 
shipping a 4.0 release that users can trust and adopt quickly.

– Scott


From: Joshua McKenzie 
Sent: Thursday, May 7, 2020 9:31 AM
Cc: dev@cassandra.apache.org
Subject: Re: List of serious issues fixed in 3.0.x

Hearing the images got killed by the web server. Trying from gmail (sorry for 
spam). Time to see if it's the apache smtp server or the list culling images:

---
I did a little analysis on this data (any defect marked with fixversion 4.0 
that rose to the level of critical in terms of availability, correctness, or 
corruption/loss) and charted some things the rest of the project community 
might find interesting:

1: Critical (availability, correctness, corruption/loss) defects fixed per 
month since about 6 months before 3.11.0:
[monthly.png]

2: Components in which critical defects arose (note: bright red bar == sum of 3 
dark red):
[Total Defects by Component.png]

3: Type of defect found and fixed (bright red: cluster down or permaloss, dark 
red: temp corrupt/loss, yellow: incorrect response):

[Total Defects by Type.png]

My personal takeaways from this: a ton of great defect fixing work has gone 
into 4.0. I'd love it if we had both code coverage analysis for testing on the 
codebase as well as data to surface where hotspots of defects are in the code 
that might need further testing (caveat: many have voiced their skepticism of 
the value of this type of data in the past in this project community, so that's 
probably another conversation to have on another thread)

Hope someone else finds the above interesting if not useful.

--
Joshua McKenzie

On Thu, May 7, 2020 at 12:24 PM Joshua McKenzie 
mailto:jmcken...@apache.org>> wrote:
I did a little analysis on this data (any defect marked with fixversion 4.0 
that rose to the level of critical in terms of availability, correctness, or 
corruption/loss) and charted some things the rest of the project community 
might find interesting:

1: Critical (availability, correctness, corruption/loss) defects fixed per 
month since about 6 months before 3.11.0:
[monthly.png]

2: Components in which critical defects arose (note: bright red bar == sum of 3 
dark red):
[Total Defects by Component.png]

3: Type of defect found and fixed (bright red: cluster down or permaloss, dark 
red: temp corrupt/loss, yellow: incorrect response):

[Total Defects by Type.png]

My personal takeaways from this: a ton of great defect fixing work has gone 
into 4.0. I'd love it if we had both code coverage analysis for testing on th

Re: [DISCUSS] CASSANDRA-13994

[Scott Andreas]

That makes sense to me, yep.

My hope and expectation is that the time required for "verification work" will 
shrink dramatically in the not too distant future - ideally to a period of less 
than a month. In this world, the cost of missing one train is reduced to 
catching the next one.

One of the main goals in shifting focus from "testing" and "test plans" to 
"test engineering" is automating as many aspects of release qualification as 
possible, with an asymptotic ideal as a function of compute capacity and time. 
While such automation will never be complete (it's likely that development of 
new features will/must include qualification infra changes to exercise them), 
if we're able to apply the same rigor to major releases as we are to patchlevel 
builds with little incremental effort, I'd be thrilled.

This is mostly a way of saying:
– I like the cadence/sequencing Benedict proposes below.
– I think improvements in test engineering can reduce/eliminate invalidation 
and may increase the scope of what can be a candidate for merge on a given 
branch
– And if not, the cost of missing the train is lower because we'll be able to 
deliver major releases more often.

Scott


From: Jeremiah D Jordan 
Sent: Wednesday, May 27, 2020 11:54 AM
To: Cassandra DEV
Subject: Re: [DISCUSS] CASSANDRA-13994

+1 strongly agree.  If we aren’t going to let something go into 4.0.0 because 
it would "invalidate testing” then we can not let such a thing go into 4.0.1 
unless we plan to re-do said testing for the patch release.

> On May 27, 2020, at 1:31 PM, Benedict Elliott Smith  
> wrote:
>
> I'm being told this still isn't clear, so let me try in a bullet-point 
> timeline:
>
> * 4.0 Beta
> * 4.0 Verification Work
> * [Merge Window]
> * 4.0 GA
> * 4.0 Minor Releases
> * ...
> * 5.0 Dev
> * ...
> * 5.0 Verification Work
> * GA 5.0
>
> I think that anything that is prohibited from "[Merge Window]" because it 
> invalidates "4.0 Verification Work" must also be prohibited until "5.0 Dev" 
> because the next equivalent work that can now validate it occurs only at "5.0 
> Verification Work"
>
> On 27/05/2020, 19:05, "Benedict Elliott Smith"  wrote:
>
>I'm not sure if I communicated my point very well.  I mean to say that if 
> the reason we are prohibiting a patch to land post-beta is because it 
> invalidates work we only perform pre-ga, then it probably should not be 
> permitted to land post-ga either, since it must also invalidate the same work?
>
>That is to say, if we're comfortable with work landing post-ga because we 
> believe it to be safe to release without our pre-major-release verification, 
> we should be comfortable with it landing at any time pre-ga too.  Anything 
> else seems inconsistent to me, and we should examine what assumptions we're 
> making that permit this inconsistency to arise.
>
>
>On 27/05/2020, 18:49, "Joshua McKenzie"  wrote:
>
>>
>> because it invalidates our pre-release verification, then it should not
>> land
>
>until we next perform pre-release verification
>
>At least for me there's a little softness around our collective 
> alignment
>on when pre-release verification takes place. If it's between alpha-1 
> and
>ga we don't want changes that would invalidate those changes to land 
> during
>that time frame. Different for beta-1 to ga. We also risk invalidating
>testing if we do any of that testing before wherever that cutoff is, 
> and a
>lack of clarity on that cutoff further muddies those waters.
>
>My very loosely held perspective is that beta-1 to ga is the window in
>which we apply the "don't do things that will invalidate 
> verification", and
>we plan to do that verification during the beta phase. I *think* this 
> is
>consistent w/the current framing of the lifecycle doc. That being 
> said, I
>don't have strong religion on this so if we collectively want to call 
> it
>"don't majorly disrupt from alpha-1 to ga", we can formalize that in 
> the
>docs and go ahead and triage current open scope for 4.0 and move 
> things out.
>
>
>
>On Wed, May 27, 2020 at 12:59 PM Ekaterina Dimitrova <
>ekaterina.dimitr...@datastax.com> wrote:
>
>> Thank you all for your input.
>> I think an important topic is again to revise the lifecycle and ensure we
>> really have the vision on what is left until beta. I will start a separate
>> thread on the flaky tests situatio

Re: [DISCUSS] Considering when to push tickets out of 4.0

[Scott Andreas]

I'll take attribution for the delay in comment on 15299; this was in part a 
case of a pressing need to investigate a potential 3.0 data resurrection issue 
drawing attention from 4.0.

I agree with the statement that we shouldn't consider protocol V5 ready for 
finalization in its current form. If we feel that this ticket alone is what 
delays release of beta and are comfortable with a release note caveating that 
one V5 ticket remains before the new protocol is finalized, that could be a 
reasonable compromise.

I don't have especially strong feelings re: 15146 and 14825 and think these are 
reasonable candidates for deferral.


From: Joshua McKenzie 
Sent: Tuesday, June 16, 2020 4:08 PM
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Considering when to push tickets out of 4.0

I completely respect and agree with the need for a drumbeat to change our
culture around testing and quality; I also agree we haven't done much to
materially change that uniquely to 4.0. The 40_quality_testing epic is our
first step in that direction though I have some personal concerns about
leaning on bespoke manual testing for quality since we humans are
infinitely fallible. :)

What elicited that response from me is the claim that we haven't yet tested
the software, implicitly invalidating the time and energy the community has
put into that thus far. I wouldn't argue that we've adequately tested for a
GA release, certainly, but we're discussing beta in this thread. As a
project, the advice we have about the testing and usage of the beta is
something along the lines of "use this in test/QA and only in cases where
minutes of downtime is acceptable." Perhaps we should consider revising the
release lifecycle on the wiki if this is something we're not aligned on?

To your point above, the problems found to date were largely with 3.0 and
found by user report and not by project developer testing. The sooner we
can get the 4.0 beta into the hands of the community, the sooner we can get
more of those reports while we also work to broaden and deepen our
programmatic testing frameworks and platforms. (To acknowledge: I presume
that a majority of the user testing that surfaced defects in 3.0 came from
one large user's investment of time and resources, however historically on
the project we've had a large number of defects surfaced by a diverse
collection of users and I'd like to see us move in that direction again for
the long-term health of the project. Hence my attempts to move us towards
beta and take on an awareness campaign and call to action for the community
to engage in testing.)


On Tue, Jun 16, 2020 at 6:37 PM Benedict Elliott Smith 
wrote:

> > Further, we have thousands of tests across all our suites
>
> I think most here would agree that our testing remains inadequate, and
> that this (modest, even in pure numerical terms for such a large project)
> number of often poorly-written unit tests does not really change that fact.
>
> Most of the problems found to date have been found with 3.0, not with 4.0,
> and found by user report.  We agreed a long time ago that we would aim for
> 4.0 to be a more stable release than any prior.  Today I think the only
> reason that might be true is the amount of work invested in fixing problems
> found in _earlier releases_, not due to verification of 4.0.
>
> I say this not to influence the decision about when and what lands in
> beta, only to ensure we stay honest with ourselves about our progress on
> quality.  I hope the software itself is higher quality today, but I do not
> believe it is honest to (yet) claim that our testing is significantly
> higher quality than those releases we all agree were inadequate.  There
> exists some wider external use case testing, but being mostly invisible to
> the community it is unclear how much broader our coverage is with these
> included.
>
> On 16/06/2020, 23:08, "David Capwell"  wrote:
>
> Inline
>
> > On Jun 16, 2020, at 2:17 PM, Joshua McKenzie 
> wrote:
> >
> >>
> >> we still produce incorrect results as shown by CASSANDRA-15313;
> this is a
> >> correctness issue, so must be a blocker for v5 protocol.
> >
> > That makes complete sense; I'd somehow missed the incorrect results
> aspect
> > in trying to get context on the work. I'd be eager to hear about
> progress
> > on it as well.
> >
> > Regarding the question of "why would users test if we haven't tested
> yet",
> > I respectfully disagree both on the assertion we haven't tested yet
> as well
> > as on the distinction between an "us vs. them" in the community.
> We're all
> > users and participants in the Cassandra community and ecosystem so
> anyone
> > downloading the DB to test it out is just as vital as one of us from
> the
> > dev list, committer list, or pmc list testing out the DB.
>
> I apologies if I came off discriminatory, I will try to absorb your
> words carefully

Re: [VOTE] Project governance wiki doc

[Scott Andreas]

+1 nb, thanks for everyone's work on this!


From: Jordan West 
Sent: Tuesday, June 16, 2020 8:09 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Project governance wiki doc

+1 nb

On Tue, Jun 16, 2020 at 5:45 PM Jake Luciani  wrote:

> +1
>
> On Tue, Jun 16, 2020 at 5:37 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > +1
> >
> > On 16/06/2020, 22:23, "Nate McCall"  wrote:
> >
> > +1 (binding)
> >
> > On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> > > Added unratified draft to the wiki here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >
> > > I propose the following:
> > >
> > >1. We leave the vote open for 1 week (close at end of day
> 6/23/20)
> > >unless there's a lot of feedback on the wiki we didn't get on
> gdoc
> > >2. pmc votes are considered binding
> > >3. committer and community votes are considered advisory /
> > non-binding
> > >
> > > Any objections / revisions to the above?
> > >
> > > Thanks!
> > >
> > > ~Josh
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> http://twitter.com/tjake
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Project governance wiki doc (take 2)

[Scott Andreas]

+1 nb

> On Jun 20, 2020, at 9:37 AM, Joshua McKenzie  wrote:
> 
> +1 (binding / present / active)
> 
> On Sat, Jun 20, 2020 at 12:23 PM Ekaterina Dimitrova 
> wrote:
> 
>> +1(non-binding)
>> 
>> On Sat, 20 Jun 2020 at 11:38, Brandon Williams  wrote:
>> 
>>> +1
>>> 
>>> On Sat, Jun 20, 2020, 10:12 AM Joshua McKenzie 
>>> wrote:
>>> 
 Link to doc:
 
 
>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
 
 Change since previous cancelled vote:
 "A simple majority of this electorate becomes the low-watermark for
>> votes
 in favour necessary to pass a motion, with new PMC members added to the
 calculation."
 
 This previously read "super majority". We have lowered the low water
>> mark
 to "simple majority" to balance strong consensus against risk of stall
>>> due
 to low participation.
 
 
   - Vote will run through 6/24/20
   - pmc votes considered binding
   - simple majority of binding participants passes the vote
   - committer and community votes considered advisory
 
 Lastly, I propose we take the count of pmc votes in this thread as our
 initial roll call count for electorate numbers and low watermark
 calculation on subsequent votes.
 
 Thanks again everyone (and specifically Benedict and Jon) for the time
>>> and
 collaboration on this.
 
 ~Josh
 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Community marketing for C*

[Scott Andreas]

Melissa, welcome to the project and thank you for your email!

One of Apache Cassandra’s longstanding challenges has been establishing a voice 
for itself as an open source project independent of the many corporate entities 
that support its development. Working together to build awareness and 
enthusiasm leading up to the 4.0 release sounds great.

Happy to help with writing, speaking, and any way I can.

Cheers,

— Scott

> On Jun 24, 2020, at 11:45 AM, Melissa Logan  wrote:
> Hi all,
> 
> I’m with an open source-focused marketing firm
> (https://constantia.io/) that works with DataStax -- we’ve been tasked
> by them to drive awareness of the Apache Cassandra project and
> community efforts. A neutral marketing “contributor” to C*, if you
> will.
> 
> Our team has a long history with open source community marketing.
> Community-led software is the way to go.
> 
> As 4.0 release approaches, our goal is to get people interested in C*
> and testing the beta. To be 100% crystal clear: this is about
> increasing awareness of the Apache Cassandra project, not vendors or
> other corporate entities associated with the ecosystem. And just like
> development, it works best when many participate.
> 
> To start, we will be contributing C* blogs to opensource.com and
> others — and doing media outreach (like the recent ZDNet article).
> Anyone interested in lending a hand as a writer and/or spokesperson?
> 
> Appreciate your consideration.
> 
> Melissa Logan
> 
> -
> 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: [DISCUSS] When to branch 4.0

[Scott Andreas]

Great point re: increasing the public visibility of testing and validation 
activity.

I’ll partner with a few contributors I work with to prep a summary of our 
findings that aren’t already captured in JIRA tickets we’ve filed against 3.x 
and 4.0 so far (as David mentioned, many issues we’re identifying are 3.0 
regressions). 

Some of these findings are notable, and many are quite standard — the type of 
experience that’s built from prep to deploy a major piece of software at large 
scale with a high degree of automation and confidence. But the pieces that are 
“standard” are the category of work that anyone automating large Cassandra 4.0 
deployments must undertake and are things Cassandra’s users will need to be 
aware of. I’m sure those findings will be valuable to all on this list.

Not all blocking issues involve a combination of range tombstones, 
legacylayout, complex types, paging state, mixed-version clusters, and reverse 
iteration. :)

— Scott

> On Jun 26, 2020, at 7:10 PM, Joshua McKenzie  wrote:
> 
> 
>> 
>> 
>> I've seen a lot of talk from some quarters of a new approach to quality,
>> but so far there have been few contributions from the same quarters
>> 
> Just a heads up - this comes across as passive aggressive sniping. I'm sure
> you didn't mean it as such but it does read that way (at least to me).
> 
> When it comes to quality, much like you said in another thread Benedict I
> think we all need to be honest with ourselves. There's been a lot of talk
> from *all* quarters but outside a lot of expression of intent across many
> fronts (verbal, ML, JIRA, slack), very little has publically materialized
> on the project to this point that I know of.
> 
> I cleared out assignees on 40_quality_testing tickets earlier this week
> (overloading shepherds in this field was a mistake IMO - that's on me)
> which has clarified for some contributors that they can take that work on.
> There's still considerable uncertainty as to what the scope is for those
> tickets and nobody really replied to Jordan pinging shepherds for
> clarification a long while ago.
> 
> 
> 
> On Fri, Jun 26, 2020 at 8:44 PM Dinesh Joshi  wrote:
> 
>>>> On Jun 26, 2020, at 3:45 PM, David Capwell  wrote:
>>> 
>>> the ability to test their impact.  Even simple things become hard given
>> the
>>> fact only committers can run Jenkins tests, or you pay money to be able
>> to
>>> run the tests...  If the intent is to make it easier for new people to
>>> contribute to the project, shouldn't the focus be on fixing their pain
>>> points such as testing?
>> 
>> +1 on not branching and keeping focus on testing and fixing 4.0.
>> 
>> I am sorry about the situation for non-committers. I tried reaching out to
>> legal and infra in the past without a great response. If someone in the
>> community has a way to reach out and get clarity on problems affecting our
>> contributors, it would be great. Otherwise, I will try to bug them again.
>> 
>> Dinesh
>> -
>> 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: [DISCUSS] A point of view on Testing Cassandra

[Scott Andreas]

Thanks for starting discussion!

Replying to the thread with what I would have left as comments.

––

> As yet, we lack empirical evidence to quantify the relative stability or 
> instability of our project compared to a peer cohort

I think it's more important that we set a standard for the project (e.g., 
fundamental conformance to properties of the database) rather than attempting 
to measure quality relative to other DBs. That might be a useful measure, but I 
don't think it's the most important one. With regard to measuring against a 
common standard in the project, this is roughly what I had in mind when 
proposing "Release Quality Metrics" on the list in 2018. I still think making 
progress on something like this is essential toward defining a quantitative bar 
for release: https://www.mail-archive.com/dev@cassandra.apache.org/msg13154.html

> Conversely, the ability to repeatedly and thoroughly validate the correctness 
> of both new and existing functionality in the system is vital to the speed 
> with which we can evolve it's form and function.

Strongly agreed.

> Utopia (and following section)

Some nods to great potential refactors to consider post-4.0 here. ^

> We should productize a kubernetes-centric, infra agnostic tool that has the 
> following available testing paradigms:

This would be an excellent set of capabilities to have.

> We need to empower our user community to participate in the testing process...

I really like this point. I took as a thought experiment "what would feel great 
to be able to say" if one were to write a product announcement for 4.0 and 
landed on something like "Users of Apache Cassandra can preflight their 4.0 
upgrade by runing $tool to clone, upgrade, and compare their clusters, ensuring 
that the upgrade will complete smoothly and correctly."

> The less friction and less investment we can require from ecosystem 
> participants, the more we can expect them to engage in desired behavior.

+1

––

I like the document and there's a lot that has me nodding. Toward the opening 
statement on "empirical evidence to quantify relative stability," I'd love to 
revisit discussion on quantifying attributes like these here: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=93324430

– Scott


From: David Capwell 
Sent: Tuesday, July 14, 2020 6:23 PM
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] A point of view on Testing Cassandra

I am also not fully clear on the motives, but welcome anything which helps
bring in better and more robust testing; thanks for starting this.

Since I can not comment in the doc I have to copy/paste and put here... =(

Reality
> ...
> investing in improving our smoke and integration testing as much as is
> possible with our current constraints seems prudent.


This section reads as very anti-adding tests to test/unit; I am 100% in
favor of improving/creating our smoke, integration, regression,
performance, E2E, etc. testing, but don't think I am as negative to
test/unit, these tests are still valuable and more are welcome.

To enumerate a punch list of traits we as engineers need from a testing
> suite


Would be good to speak about portability, accessibility, and version
independents.  If a new contributor wants to add tests to this suite they
need to be able to run it, and it should run within a "reasonable" time
frame; one of the big issuers with python dtests is that it takes 14+ hours
to run, this makes it no longer accessible to new contributors.


On Tue, Jul 14, 2020 at 11:47 AM Joshua McKenzie 
wrote:

> The purpose is purely to signal a point of view on the state of testing in
> the codebase, some shortcomings of the architecture, and what a few of us
> are doing and further planning to do about it. Kind of a "prompt discussion
> if anyone has a wild allergic reaction to it, or encourage collaboration if
> they have a wild positive reaction" sort of thing. Maybe a spiritual
> "CEP-lite". :)
>
> I would advocate that we be very selective about the topics on which we
> strive for a consistent shared point of view as a project. There are a lot
> of us and we all have different experiences and different points of view
> that lead to different perspectives and value systems. Agreeing on discrete
> definitions of done, 100% - that's table stakes. But agreeing on how we get
> there, my personal take is we'd all be well served to spend our energy
> Doing the Work and expressing these complementary positions rather than
> trying to bend everyone to one consistent point of view.
>
> Let a thousand flowers bloom, as someone wise recently told me. :)
>
> That said, this work will be happening in an open source repo with a
> permissive license (almost certai

Re: [VOTE] Release Apache Cassandra 4.0-beta1

[Scott Hirleman]

I'll add in here as someone who was acting as PM on a lot of cross-team
projects at my last few gigs, this is a good example of coordination
improving the process. If people are unwilling to change their opinions or
even express them, that is an issue. Timing of release/progress is
important and pushing back on whether changes are necessary is valid too.

Being aware that Marketing contributions are valid/valuable community
contributions is a key to the success of a project. Seems like there were
some white spaces in what was known but this was a good resolution for all.
Is there some update to public documentation that can be put out there to
explain the coordination and timing w/ the Marketing team? Want to make
sure this isn't only included in a single email chain but is posted up for
all to review and see because it's important info.

On Fri, Jul 17, 2020 at 2:38 PM  wrote:

> Thanks for the clarification Melissa. It’s interesting to see how open
> source marketing and timing differs from “traditional”.
>
> Looks like I was mistaken about coordination implications of delay. Sorry
> for instigating needless conflict.
>
> > On Jul 17, 2020, at 5:11 PM, 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
> -1s.
> >>
> >
> >
> > Vote closed/cancelled, am re-cutting it…
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Scott Hirleman
scott.hirle...@gmail.com

Re: naming development branches consistently

[Scott Hirleman]

Cyril, your commentary violates the code of conduct of the ASF
<https://apache.org/foundation/policies/conduct.html> re rules #2 and #5.
It could also be very hurtful to those who feel this is important, as many
in the community do. Please think before pushing further on this as
projects need to be welcoming and inclusive. Thank you.

On Mon, Aug 24, 2020 at 4:00 PM Cyril Scetbon  wrote:

> Wow, thanks for the link Almero. I suppose the dictionary comes next then
> 🤷‍♂️
>
> > On Aug 24, 2020, at 6:54 PM, Gouws, Almero 
> wrote:
> >
> >
> https://www.zdnet.com/article/mysql-drops-master-slave-and-blacklist-whitelist-terminology/
> >
> > -Almero
> >
> > -Original Message-
> > From: Cyril Scetbon 
> > Sent: Monday, August 24, 2020 3:47 PM
> > To: dev@cassandra.apache.org
> > Subject: RE: [EXTERNAL] naming development branches consistently
> >
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
> >
> >
> >
> > Seriously ? Should we change how MySQL architectures are defined ?
> Should we remove it from the dictionary too ? Just to see how radical It
> could be … 🤦‍♂️
> >
> >> On Aug 24, 2020, at 12:12 PM, Brandon Williams 
> wrote:
> >>
> >> With the current social climate I thought removing the master
> >> reference rather than proliferating it would be better.
> >>
> >> On Mon, Aug 24, 2020 at 11:07 AM Joshua McKenzie 
> wrote:
> >>>
> >>> Why not rename "trunk" to "master" in C*?   =D
> >>>
> >>> On Mon, Aug 24, 2020 at 11:17 AM Brandon Williams 
> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> Currently in the cassandra repo our development branch is named
> >>>> 'trunk', but this is not consistently used in other repos, such as
> >>>> cassandra-dtest, -builds, -website, and probably others, which use
> >>>> 'master' instead.  I propose we rename all of those to 'trunk' to
> >>>> match.
> >>>>
> >>>> Kind Regards,
> >>>> Brandon
> >>>>
> >>>> 
> >>>> - 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
> >
> >
> > -
> > 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
>
>

-- 
Scott Hirleman
scott.hirle...@gmail.com

Re: 4.0 GA scope: the opt-in approach (CALL TO ACTION)

[Scott Andreas]

Thank you, Josh! Just took a pass and opted in 22 of the 55 tickets with the 
triage keyword as of this evening, most of which are active this month or are 
for flaky/failing tests.

– Scott


From: Joshua McKenzie 
Sent: Monday, October 5, 2020 11:01 AM
To: dev@cassandra.apache.org
Subject: Re: 4.0 GA scope: the opt-in approach (CALL TO ACTION)

Friendly reminder: please check the link in the previous email and remove
the 4.0-triage version from any tickets you want to keep included in 4.0 GA.

Thanks.

~Josh


On Fri, Oct 02, 2020 at 5:58 PM, Joshua McKenzie 
wrote:

> As discussed on the contributor call, we collectively agreed to try
> something new to determine scope for 4.0. Rather than going ticket by
> ticket or "asking for forgiveness" and having people move things out
> individually, we've flagged all tickets in the 4.0 scope that are still
> open with the fixversion '4.0-triage' with the intent to "opt things in".
>
> Link: https://issues.apache.org/jira/issues/
> ?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%204.0-triage
>
> If there's a ticket you want to keep in the 4.0 release, please edit the
> ticket and remove the '4.0-triage' fixversion. Let's target having this
> done by End of Day Friday, October 9th (one week from now).
>
> If you don't have access to remove that fixver from a ticket, please reach
> out to me (jmckenzie), Jordan West, or Jon Meredith on the-asf slack in
> #cassandra-dev or via DM and we'll help you out.
>
> At the end of day on Oct 9th, we'll go through and move every ticket that
> still has 4.0-triage into 4.0.x and have our scope for 4.0 GA.
>
> Sound good?
>
> ~Josh
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.6

[Scott Andreas]

+1nb


From: Jordan West 
Sent: Thursday, October 8, 2020 7:40 AM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release dtest-api 0.0.6

+1

On Thu, Oct 8, 2020 at 7:25 AM Brandon Williams  wrote:

> +1
>
> On Thu, Oct 8, 2020 at 3:20 AM Oleksandr Petrov
>  wrote:
> >
> > Proposing the test build of in-jvm dtest API 0.0.6 for release.
> >
> > Repository:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6
> >
> > Candidate SHA:
> >
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT
> > tagged with 0.0.6
> > Artifact:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/
> >
> > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> >
> > Changes since last release:
> >
> >   * CASSANDRA-16148: Add IInstance#getReleaseVersionString
> >
> > 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.
> >
> > -- Alex
>
> -
> 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: Supported upgrade path for 4.0

[Scott Andreas]

Great, thanks Ben!

The primary configuration my colleagues and I will be vetting is the 3.0.x -> 
4.0 path (implicitly, 2.1 -> 3.0 -> 4.0). From a quality + safety perspective 
we will be ensuring that it’s a smooth ride for folks who opt for this route; 
though no major concerns on my part with the project recommending 2.1 -> 3.11 
-> 4.0 aside from not having experienced it myself.

> On Oct 11, 2020, at 12:47 AM, Ben Slater  wrote:
> 
> Just to add to Mick's point, we (Instaclustr) have also been running and
> recommending 3.11.x by default. It's currently by far the most common
> version in our managed fleet and our last 3.0.x cluster will likely be
> upgraded shortly. 3.11.x is also our recommendation for consulting and
> support customers. I'd therefore support Mick's recommendation (really
> based on our experience with and confidence in 3.11.x rather than being
> able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
> preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
> can't see us doing any work on 3.0 to 4.0.
> 
> Cheers
> Ben
> 
> ---
> 
> 
> *Ben Slater**Chief Product Officer*
> 
> 
> 
>    
> 
> 
> Read our latest technical blog posts here
> .
> 
> This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
> and Instaclustr Inc (USA).
> 
> This email and any attachments may contain confidential and legally
> privileged information.  If you are not the intended recipient, do not copy
> or disclose its content, but please reply to this email immediately and
> highlight the error to the sender and then immediately delete the message.
> 
> 
> On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever  wrote:
> 
>>> "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
>> recommend
>>> people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
>> cluster
>>> in a regressed performance state for potentially months as they execute
>>> their upgrade."
>>> 
>>> Did I get anything wrong here Mick? ^
>>> 
>> 
>> 
>> That's correct Josh.
>> 
>> From tickets like those listed, and from experience, we recommend folk
>> avoid 3.0 altogether. This has only been made more evident by witnessing
>> the benefits from 3.0 → 3.11 upgrades.
>> 
>> My recommendation remains  2.*→3.11→4.0. And I don't believe I'm alone.
>> Though if a user was already on 3.0, then I would (of course) recommend an
>> upgrade directly to 4.0.
>> 
>> I feel like I'm just splitting straws at this point, since we have accepted
>> (folk willing to help with) both paths to 4.0, and I can't see how we stop
>> recommending  2.*→3.11 upgrades.
>> 

Re: [VOTE] Release Apache Cassandra 3.0.23

[Scott Andreas]

+1 nb

> On Oct 31, 2020, at 11:37 AM, Brandon Williams  wrote:
> 
> +1
> 
> Signatures and checksums match, source build works, as does dis/enablebinary.
> 
> On Thu, Oct 29, 2020 at 7:29 AM Mick Semb Wever  wrote:
>> 
>> Proposing the test build of Cassandra 3.0.23 for release.
>> 
>> sha1: 31530ff5ac6bd3bacd4b378573a2d191bdab8cd7
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.23-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1222/org/apache/cassandra/cassandra-all/3.0.23/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/3.0.23/
>> 
>> 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]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.23-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.23-tentative
>> 
>> -
>> 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: [VOTE] Release Apache Cassandra 4.0-beta3

[Scott Andreas]

+1 nb

> On Oct 31, 2020, at 11:38 AM, Brandon Williams  wrote:
> 
> +1
> 
> Signatures and checksums match, source build works, as does dis/enablebinary.
> 
> On Thu, Oct 29, 2020 at 7:30 AM Mick Semb Wever  wrote:
>> 
>> Proposing the test build of Cassandra 4.0-beta3 for release.
>> 
>> sha1: be716b46f2cb3b2d1f01dc225396c6284d5a35de
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta3-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1224/org/apache/cassandra/cassandra-all/4.0-beta3/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta3/
>> 
>> 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]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta3-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta3-tentative
>> 
>> -
>> 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: Renaming master to trunk on cassandra-builds, cassandra-website, cassandra-dtest

[Scott Hirleman]

Thanks Mick, language matters, big ups for taking care of this.

On Tue, Oct 27, 2020 at 5:37 AM Mick Semb Wever  wrote:

> > The general preference there was trunk over main, so to match the
> cassandra repository.
>
>
> All Cassandra code repositories have trunk now as their default branch.
>
> All master branches have been removed.
>
> The cassandra-dtest repo was referenced in a few places. Please let me
> know if I missed updating a reference anywhere.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Scott Hirleman
scott.hirle...@gmail.com

Re: Cassandra 4.0 dropping support for older distributions Centos 5, Debian 4, Ubuntu 7.10

[Scott Andreas]

Thanks for flagging this, Mick!

No concern from me as all EOL dates for these distributions have long passed 
and agreed that a NEWS entry is a good way to surface to users.


From: Mick Semb Wever 
Sent: Friday, November 13, 2020 12:09 PM
To: dev@cassandra.apache.org
Subject: Re: Cassandra 4.0 dropping support for older distributions Centos 5, 
Debian 4, Ubuntu 7.10

Sounds ok to be, but one small question; if a user is still running older
> versions, can they downgrade JNA or would this break?  Basically, do our
> defaults/testing no longer support or would our source no longer be
> compatible?
>


The patch for CASSANDRA-16212 does not change the use of JNA, so a
downgrade of the jna jar file would be possible. But once the upgrade is in
place there's no way really for us to enforce that any subsequent ticket
doesn't take advantage of any new jna api.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.7

[Scott Andreas]

+1nb


From: Brandon Williams 
Sent: Thursday, December 3, 2020 10:05 AM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release dtest-api 0.0.7

+1

On Thu, Dec 3, 2020, 7:02 AM Oleksandr Petrov 
wrote:

> Proposing the test build of in-jvm dtest API 0.0.7 for release.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.7
>
> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/d5174b1f44b7d9cb919d4975b4d437041273c09c
> tagged with 0.0.7
> Artifact:
> https://repository.apache.org/content/repositories/orgapachecassandra-1225/org/apache/cassandra/dtest-api/0.0.7/
>
> Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
>
> Changes since last release:
>
>   * CASSANDRA-16136: Add Metrics to instance API
>   * CASSANDRA-16272: Nodetool assert apis do not include the new
> stdout and stderr in the failure message
>
> 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.
>
> -- Alex
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Revisiting the quality testing epic scope

[Scott Andreas]

Thanks for raising the question, Benjamin! Notes on a few tickets inline below.

Non-Blocking:
– CASSANDRA-15537 Local Read/Write Path: Upgrade and Diff Test
I think it’s reasonable to consider this ticket complete. Yifan and others have 
worked to execute several dozen diff tests and while I’m sure others will 
continue, it’s reasonable to say cassandra-diff has been used to compare 3.0 
vs. 4.0 clusters with a wide variety of data models. I’ll check with Yifan on 
Tuesday re: updating the status of the ticket. It would be wonderful to hear of 
diff runs and experience from additional contributors if others can share.

– CASSANDRA-15584 Tooling - External Ecosystem
Great collaboration on this one (including issues filed arising from this 
coverage, such as a recent ticket related to Medusa).

Blocking GA:
– CASSANDRA-15579 Distributed Read/Write Path
The coordination and replication subtasks (16180, 16181) are making good 
progress. I’ll check with Caleb and David on 16262 (the fuzz testing subtask on 
Tuesday).

– CASSANDRA-15581 Compaction
Most of these are perf tests rather than development tasks, though the ones 
complete are listed as Patch Available. I’ll check with Yifan if it’d make 
sense to move those for which no planned work remains to Resolved. I don’t 
think there’s a lot left here.

– CASSANDRA-15538 Local Read/Write Path - Other Areas
Will see if anything specific is planned, as scope is relatively undefined.

With the exception of 15538, most of these look to be moving along or nearly 
complete. I don’t think I’d shift others aside from it into the non-blocking 
category - but the silver lining is that it shouldn’t be long before the others 
wrap up.

We do have several flaky test tickets that could use attention, though — these 
may be quick to push through if anyone is able to pick them up:

– CASSANDRA-16236: Fix flaky testTrackMaxDeletionTime
– CASSANDRA-16238: Fix flaky test test_insert_data_during_replace_same_address 
- replace_address_test.TestReplaceAddress
– CASSANDRA-16239: Fix flaky test 
org.apache.cassandra.distributed.test.NetstatsRepairStreamingTest 
testWithCompressionDisabled
– CASSANDRA-16317: Fix flaky test incompleteCommit - 
org.apache.cassandra.distributed.test.CASTest
– CASSANDRA-16355: Fix flaky test incompletePropose - 
org.apache.cassandra.distributed.test.CASTest
– CASSANDRA-16382: Fix flaky 
LongSharedExecutorPoolTest.testPromptnessOfExecution
– CASSANDRA-16358: Minor Flakiness in 
ProxyHandlerConnectionsTest#testExpireSomeFromBatch
– CASSANDRA-16229: Flaky jvm-dtest: 
org.apache.cassandra.distributed.test.ring.NodeNotInRingTest.nodeNotInRingTest
– CASSANDRA-16061: 
transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup

Cheers,

– Scott

> On Jan 14, 2021, at 9:05 AM, Benjamin Lerer  
> wrote:
> 
> Hi everybody,
> 
> As discussed before the holidays, it might make sense to revisit the scope
> of the quality testing tickets for 4.0 GA to ensure that the 4.0 release is
> not held for longer than necessary.
> 
> The current status of the quality testing tasks are the following:
> 
> *DONE:*
> 
> * CASSANDRA-15583 <https://issues.apache.org/jira/browse/CASSANDRA-15583>
> Tooling, Bundled and First Party*
> CASSANDRA-15586 <https://issues.apache.org/jira/browse/CASSANDRA-15586>
> Cluster Setup and Maintenance
> CASSANDRA-15587 <https://issues.apache.org/jira/browse/CASSANDRA-15587>
> Platforms and Runtimes
> 
> 
> *NON BLOCKING:*
> 
> The goals of the following ticket have been reached. Once GA is closed they
> will be marked as done.
> 
> CASSANDRA-15537 <https://issues.apache.org/jira/browse/CASSANDRA-15537>
> Local Read/Write Path: Upgrade and Diff Test
> CASSANDRA-15584 <https://issues.apache.org/jira/browse/CASSANDRA-15584>
> Tooling - External Ecosystem
> 
> If I understood Jordan comment correctly on the following ticket, its
> should also not be a blocker for 4.0
> CASSANDRA-15585 <https://issues.apache.org/jira/browse/CASSANDRA-15585>
> Test Frameworks, Tooling, Infra / Automation
> 
> *BLOCKING GA:*
> 
> CASSANDRA-15579 <https://issues.apache.org/jira/browse/CASSANDRA-15579>
> Distributed Read/Write Path
>4 sub-tasks: 1 resolved, 2 in progress, 1 open
> 
> CASSANDRA-15580 <https://issues.apache.org/jira/browse/CASSANDRA-15580>
> Repair
>Test scenarios are ready, working on integrating them to circle-ci
> 
> CASSANDRA-15581 <https://issues.apache.org/jira/browse/CASSANDRA-15581>
> Compaction
>9 sub-tasks: 5 patch available, 1 review in progress, 3 triage needed
> 
> CASSANDRA-15582 <https://issues.apache.org/jira/browse/CASSANDRA-15582>
> Metrics
>   16 sub-tasks: 9 resolved, 5 patch available, 5 open
> 
> CASSANDRA-15588 <https://issues.apache.org/jira/browse/CASSANDRA-15588

Re: [DISCUSS] Revisiting the quality testing epic scope

[Scott Andreas]

Thanks Benjamin!

I propose we de-scope 15538 as the ticket does not currently have a clear 
definition of done. Unless others disagree, we can remove the fix version via 
lazy consensus in a couple days. That leaves us with a well-defined set of 
tickets that are making progress.

Re: the next question:
"Do you have a timeframe in mind for releasing 4.0 GA? Assuming that there is 
no sudden burst in the number of issues."

This is a great question for all on the list. Please consider what follows as 
my interpretation of our current status relative to the project's Release 
Lifecycle doc (and all "we/you" pronouns collective): 
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

We're currently meeting all criteria for the Beta phase except "No flaky tests" 
and a small number of known bugs (eg., 16307, 16078). The good news is we have 
the tickets in both categories identified (discussed earlier in this thread), 
and they don't appear to be a large amount of work - potentially with the 
exception of CASSANDRA-16078: Performance regression for queries accessing 
multiple rows. The ticket reports a 39% perf regression for queries fetching 
multiple rows in a partition via IN clauses – a major regression that should 
block release until understood/fixed. Caleb's working on this now.

Once those issues and the validation epics that are now in review are wrapped 
(which look like a few weeks' work if contributors can jump on the flaky test 
tickets), we'll have met our criteria for graduating beta.

The definition of an RC release is that any SHA we cut an RC build from may 
legitimately be the SHA declared "Apache Cassandra 4.0.0." This is where it 
gets real. When the project declares a build "RC," we're staking our collective 
credibility on it and recommend that users upgrade to a build that received 
this designation.

I feel very good about where 4.0 is at. We've all surfaced and resolved a large 
number of important issues. We've enhanced the project's testing infrastructure 
to broaden the surface covered, which reduces the probability of unknown 
unknowns. And we've collectively developed toolchains for large-scale 
verification, including of existing live clusters via diff.

After beta’s complete, the next chasm to cross seems like our own collective 
willingness to deploy and operate Cassandra 4.0 clusters in production. Once 
we're at RC, willing to do so, and to recommend users do the same, I think 
we'll have hit our definition of done.

As we wrap up the remaining beta issues and flaky tests, now's a good time for 
that RC gut check. If there's a remaining issue that would prevent you from 
running trunk in a prod environment, please file it and raise attention - it'll 
help us finish polishing the release. And if there isn't - deploy it!

We still need to finish the remaining bugs in scope and get tests reliably 
green. But it feels good to be this close.

– Scott


From: Benjamin Lerer 
Sent: Tuesday, January 19, 2021 1:54 AM
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Revisiting the quality testing epic scope

Thank you for your reply, Scott.

My understanding is that Alexander is moving forward on CASSANDRA-15580
(Repair)  and that Andres is focussing with Caleb on the tickets of
CASSANDRA-15579 (Distributed Read/Write Path). The biggest unknown here
seems to be CASSANDRA-16262 as you mentioned.

Regarding CASSANDRA-15582 (Metrics), I shifted my focus toward helping with
reviews for the release candidate. By consequence, outside of 2 patches
created by  Sumanth during the holidays, the epic has not been moving
forward.

the silver lining is that it shouldn’t be long before the others wrap up.
>

Do you have a timeframe in mind for releasing 4.0 GA? Assuming that there
is no sudden burst in the number of issues.

We do have several flaky test tickets that could use attention, though
>

I believe that Adam, Berenguer and Brandon have started focusing on them.

On Sat, Jan 16, 2021 at 10:49 PM Scott Andreas  wrote:

> Thanks for raising the question, Benjamin! Notes on a few tickets inline
> below.
>
> Non-Blocking:
> – CASSANDRA-15537 Local Read/Write Path: Upgrade and Diff Test
> I think it’s reasonable to consider this ticket complete. Yifan and others
> have worked to execute several dozen diff tests and while I’m sure others
> will continue, it’s reasonable to say cassandra-diff has been used to
> compare 3.0 vs. 4.0 clusters with a wide variety of data models. I’ll check
> with Yifan on Tuesday re: updating the status of the ticket. It would be
> wonderful to hear of diff runs and experience from additional contributors
> if others can share.
>
> – CASSANDRA-15584 Tooling - External Ecosystem
> Great collaboration on this one

Re: [VOTE] Release Apache Cassandra 3.0.24

[Scott Andreas]

+1 nb


From: Yifan Cai 
Sent: Friday, January 29, 2021 12:51 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 3.0.24

+1 nb

On Fri, Jan 29, 2021 at 7:11 AM Aleksey Yeshchenko
 wrote:

> +1
>
> > On 29 Jan 2021, at 14:31, Ekaterina Dimitrova 
> wrote:
> >
> > +1(nb)
> >
> > On Fri, 29 Jan 2021 at 8:21, Oleksandr Petrov <
> oleksandr.pet...@gmail.com>
> > wrote:
> >
> >>> Proposing the test build of Cassandra 4.0-beta4 for release.
> >>
> >> Correction: test build of 3.0.24. The rest looks right.
> >>
> >> On Fri, Jan 29, 2021 at 1:48 PM Oleksandr Petrov <
> >> oleksandr.pet...@gmail.com>
> >> wrote:
> >>
> >>> Proposing the test build of Cassandra 4.0-beta4 for release.
> >>>
> >>> sha1: 6748ecd63cae047b5b0e8c3165088252954e9d5f
> >>> Git:
> >>>
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.24-tentative
> >>> Maven Artifacts:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1229/org/apache/cassandra/cassandra-all/3.0.24/
> >>>
> >>> The Source and Build Artifacts, and the Debian and RPM packages and
> >>> repositories, are available here:
> >>> https://dist.apache.org/repos/dist/dev/cassandra/3.0.24/
> >>>
> >>> 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]: CHANGES.txt:
> >>>
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.24-tentative
> >>> [2]: NEWS.txt:
> >>>
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.24-tentative
> >>>
> >>
> >>
> >> --
> >> alex p
> >>
>
>
> -
> 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: Welcome Paulo Motta as Cassandra PMC member

[Scott Andreas]

Congratulations, Paulo!


From: Jordan West 
Sent: Wednesday, February 10, 2021 5:39 PM
To: dev@cassandra.apache.org
Subject: Re: Welcome Paulo Motta as Cassandra PMC member

Congrats Paulo!

Jordan

On Tue, Feb 9, 2021 at 10:25 PM Berenguer Blasi 
wrote:

> Congrats Paulo! well done.
>
> On 9/2/21 21:28, Lorina Poland wrote:
> > Congratulations Paulo!
> > Lorina Poland
> > e. lor...@datastax.com
> > w. www.datastax.com
> >
> >
> >
> > On Tue, Feb 9, 2021 at 10:30 AM Andrés de la Peña <
> a.penya.gar...@gmail.com>
> > wrote:
> >
> >> Congrats Paulo!
> >>
> >> On Tue, 9 Feb 2021 at 17:42, Sumanth Pasupuleti <
> >> sumanth.pasupuleti...@gmail.com> wrote:
> >>
> >>> Congratulations Paulo!
> >>>
> >>> On Tue, Feb 9, 2021 at 8:10 AM Jasonstack Zhao Yang <
> >>> jasonstack.z...@gmail.com> wrote:
> >>>
>  Congrats Paulo!
> 
>  On Wed, 10 Feb 2021 at 00:03, Ekaterina Dimitrova <
> >> e.dimitr...@gmail.com
>  wrote:
> 
> > Congrats! Well done!
> >
> > On Tue, 9 Feb 2021 at 11:02, J. D. Jordan  > wrote:
> >
> >> Congrats Paulo! A great addition to the PMC.
> >>
> >>> On Feb 9, 2021, at 9:59 AM, Jonathan Ellis 
>  wrote:
> >>> Congratulations, Paulo!  Well deserved.
> >>>
>  On Tue, Feb 9, 2021 at 9:54 AM Benjamin Lerer <
> >> benjamin.le...@datastax.com>
>  wrote:
> 
>  The PMC's members are pleased to announce that Paulo Motta has
> > accepted
>  the invitation to become a PMC member yesterday.
> 
>  Thanks a lot, Paulo, for everything you have done for the
> >> project
>  all
> >> these
>  years.
> 
>  Congratulations and welcome
> 
>  The Apache Cassandra PMC members
> 
> >>>
> >>> --
> >>> Jonathan Ellis
> >>> co-founder, http://www.datastax.com
> >>> @spyced
> >>
> >> -
> >> 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: Project Roadmap

[Scott Andreas]

+1 as well. This would be great for the project and for our users.


From: Benedict Elliott Smith 
Sent: Tuesday, March 2, 2021 3:26 AM
To: dev@cassandra.apache.org
Subject: Re: Project Roadmap

Yep, I'm not proposing we start discussions right now. Just wanted to float the 
idea, see how people felt about it and how people might like it to look 
procedurally.

My only goal is that we have a rough roadmap agreed before GA, to publish 
alongside any announcement.

On 02/03/2021, 09:57, "Benjamin Lerer"  wrote:

>
> I completely agree we should consider any roadmap a living document that
> we expect to revise, but my hope is that we will formalise an agreed
> roadmap by vote.


I believe that everybody will be in favor of discussing the plans for the
next release. We do not really need to commit to anything at this point.
My proposal would be to get 4.0-RC out of the door and let a couple of
weeks for people to think about the next release. Then we can trigger a
discussion for everybody on what they are willing to focus on first.
What do you think?

Le mar. 2 mars 2021 à 06:29, Berenguer Blasi  a
écrit :

> +1000 on some form of roadmap for visibility and planning
>
> On 1/3/21 18:35, Benedict Elliott Smith wrote:
> > I completely agree we should consider any roadmap a living document that
> we expect to revise, but my hope is that we will formalise an agreed
> roadmap by vote.  My view is that we should aim to regularly revisit the
> roadmap, and anticipate that it will be revised based on contributors'
> shifting priorities and pressures.
> >
> > I think the important thing is that in revising the roadmap we'll again
> make explicit trade-offs as a community about what we want to invest in
> before the next release.
> >
> >
> > On 01/03/2021, 13:26, "Benjamin Lerer"  wrote:
> >
> > Having an open discussion about what we want to release as a
> community on
> > the next version makes total sense to me. I also agree that the
> roadmap
> > should not be written on stone and that we should be flexible if we
> believe
> > that we need to.
> > We should also take this discussion as an opportunity to discuss how
> we
> > plan to use CEPs moving forward.
> > .
> >
> > Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith <
> bened...@apache.org> a
> > écrit :
> >
> > > I guess I meant that I don't foresee roadmap discussions having a
> hard
> > > requirement of CEP for all goals we might discuss, though it would
> probably
> > > be expected that many of the biggest proposals would already at
> least have
> > > a minimal CEP to be filed, you're right.
> > >
> > > Certainly if an advanced CEP exists I hadn't meant to exclude it,
> I more
> > > meant that the CEP process is quite involved and spans the
> lifetime of the
> > > work, and a roadmap helps the project decide on goals irrespective
> of a
> > > CEP, and helps resource a CEP early in its lifecycle.
> > >
> > > On 01/03/2021, 11:15, "Mick Semb Wever"  wrote:
> > >
> > > >
> > > > I think of a roadmap as a pre-CEP activity for upcoming
> releases,
> > > items
> > > > thereon beginning the CEP process, …
> > > >
> > >
> > >
> > > What about having it the other way around? That the roadmap is
> a
> > > visualisation of the CEPs, i.e. those past initial triage that
> have
> > > initial
> > > commitment and momentum. A reflective approach of the roadmap,
> just a
> > > visualisation of existing processes, prevents the adding of a
> new
> > > process
> > > to the community. It will also incentivise the thoroughness of
> new
> > > CEPs.
> > >
> > > The benefit of having the roadmap as a separate manual process
> pre-CEP
> > > might save us the cost of creating CEPs that get rejected, but
> I can't
> > > see
> > > that actually being a problem for us.
> > >
> > > +1 to having the roadmap, in any form.
> > >
> > >
> > >
> > >
> -
> > > 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: Roadmap for 4.0

[Scott Andreas]

Re-raising a point made earlier in the thread by Jeff and affirmed by Josh:

–––
Jeff:
>> A hard date for a feature freeze makes sense, a hard date for a release
>> does not.

Josh:
> Strongly agree. We should also collectively define what "Done" looks like
> post freeze so we don't end up in bike-shedding hell like we have in the
> past.
–––

Another way of saying this: ensuring that the 4.0 release is of high quality is 
more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature complete" 
date (modulo a "definition of done" as Josh suggested), that will help us align 
toward the polish, performance work, and dog-fooding needed to feel great about 
shipping 4.0. It's a good time to start thinking about the approaches to 
testing, profiling, and dog-fooding various contributors will want to take on 
before release.

I love how Ben put it:

> An "exciting" 4.0 release to me is one that is stable and usable
> with no perf regressions on day 1 and includes some of the big
> internal changes mentioned previously.
>
> This will set the community up well for some awesome and exciting
> stuff that will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

– Scott


From: Kenneth Brotman 
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0

Focusing on 4.0 release then, lets agree on a date next year. Whatever is ready 
for release by that date is what will be in that release.

Kenneth Brotman

-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com]
Sent: Wednesday, April 04, 2018 12:59 PM
To: dev
Subject: Re: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman  
wrote:
> Can I suggest a way of defining the next few progressions as a way of 
> approaching this?
>
> How about something like this:
> Version 4.0:  A major release of as many improvements to the code as 
> can be ready for a release on a date sometime next year ;to be decided on by 
> us this month.
> Versions 4.x: minor releases about every three months starting after 
> a major release with improvements to the code that can be ready for release, 
> with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements 
> are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with 
> improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready for 
> release in that major version,
> A minor release every 3 months of whatever can be ready for 
> release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would be 
> ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion. 
Please see the following two (lengthy) threads from last year for background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
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: [VOTE] Release Apache Cassandra 4.0-rc1

[Scott Andreas]

+1 nb.

This is a huge milestone for the project.


From: Paulo Motta 
Sent: Tuesday, March 30, 2021 4:57 AM
To: Cassandra DEV
Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1

+1

Em ter., 30 de mar. de 2021 às 00:25, Dinesh Joshi 
escreveu:

> +1
>
> Dinesh
>
> > On Mar 29, 2021, at 1:41 PM, Nate McCall  wrote:
> >
> > +1
> >
> >
> >> On Tue, Mar 30, 2021 at 2:06 AM Mick Semb Wever  wrote:
> >>
> >> Proposing the test build of Cassandra 4.0-rc1 for release.
> >>
> >> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> >> Git:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> >> Maven Artifacts:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >>
> >> The Source and Build Artifacts, and the Debian and RPM packages and
> >> repositories, are available here:
> >> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >>
> >> 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.
> >>
> >> Known issues with this release, that are planned to be fixed in 4.0-rc2,
> >> are
> >> - four files were missing copyright headers,
> >> - LICENSE and NOTICE contain additional unneeded information,
> >> - jar files under lib/ in the source artefact.
> >>
> >> These issues are actively being worked on, along with our expectations
> that
> >> the ASF makes the policy around them more explicit so it is clear
> exactly
> >> what is required of us.
> >>
> >>
> >> [1]: CHANGES.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> >> [2]: NEWS.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSSION] Next release roadmap

[Scott Andreas]

Thanks for starting this discussion, Benjamin!

I share others’ enthusiasm on this thread for improvements to secondary 
indexes, trie-based partition indexes, guardrails, and encryption at rest.

Here are some other post-4.0 areas for investment that have been on my mind:

�C Transactional Cluster Metadata
Migrating from optimistic modification and propagation of cluster metadata via 
gossip to a transactional implementation opens a lot of possibilities. Token 
movements and instance replacements get safer and faster. Schema changes can be 
made atomic, enabling users to execute DDL rapidly without waiting for 
convergence. Operations like expansions and shrinks become easier to automate 
with less care and feeding.

�C Paxos improvements
During discussion on C-12126, Benedict expressed interest in post-4.0 
improvements that can be made to Cassandra’s Paxos / LWT implementation that 
would enable the database to serve serial writes with two round-trips and 
serial reads with one round-trip in the uncontended case. For many cross-WAN 
serial use cases, this may halve the latency of CAS queries.

�C Multi-Partition LWTs
LWT is a great primitive, but modeling applications with the constraint of 
single-key CAS can be a game of Twister. Extending the paxos improvements 
discussed above to enable multi-partition CAS would enable users of Apache 
Cassandra to perform serial operations across partition boundaries.

�C Downgrade-ability
I also see “downgradeability” as important to future new release adoption. 
Taking file format changes as an example, it’s currently not possible to 
downgrade in the event that a serious issue has been identified �C unless 
you’re able to host-replace yourself out after upgrading one replica, or revert 
to a pre-upgrade snapshot and accept data loss. It would be excellent if it 
were possible for v.next to continue writing the previous 
SSTable/commitlog/hint/etc. format until a switch is flipped to opt into new 
file formats. Apache HDFS takes a similar approach, enabling downgrade until 
NameNode metadata is finalized [1]. This would be an excellent capability to 
have in Apache Cassandra, and dramatically lower the stakes for new release 
adoption.

On pluggability / disaggregation:
I agree that these are important themes. We’ll want to bring a lot of care and 
attention to this work. Disaggregation can open a lot of possibilities - with 
the drawback of future changes being restricted to the defined interface and an 
inability to optimize across interface boundaries. We can probably hit a sweet 
spot, though.

Toolchains to validate implementations of pluggable components will become very 
important. It would be bad for the project’s users if bundled implementations 
were of uneven quality or supported subsets of functionality. Converging on a 
common validation toolchain for pluggable subsystems can help us ensure that 
quality while minimizing the effort required to test new implementations.

Finally, I think it's important we work to maintain trunk in a shippable state. 
This might look like major changes and new features hiding behind feature flags 
that enable users to selectively enable them as development and validation 
proceeds, with new code executed regardless of the flag held to a higher 
standard.

Cheers,

�C Scott

[1] 
https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsRollingUpgrade.html



From: guo Maxwell 
Sent: Wednesday, April 14, 2021 10:25 PM
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Next release roadmap

+1

Brandon Williams  于2021年4月15日周四 上午4:48写道：

> Agreed.  Everyone just please keep in mind this thread is for roadmap
> contributions you plan to make, not contributions you would like to
> see.
>
> On Wed, Apr 14, 2021 at 3:45 PM Nate McCall  wrote:
> >
> > Agree with Stefan 100% on this. We need to move towards pluggability. Our
> > users are asking for it, it makes sense architecturally, and people are
> > doing it anyway.
> >
> >
> > ...
> > > for me definitely https://issues.apache.org/jira/browse/CASSANDRA-9633
> > >
> > > I am surprised nobody mentioned this in the previous answers, there is
> > > ~50 people waiting for it to happen and multiple people working on it
> > > seriously and wanting that feature to be there for so so long.
> > > ...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

--
you are the apple of my eye !

-
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)

[Scott Andreas]

+1nb, thank you!


From: Ekaterina Dimitrova 
Sent: Wednesday, April 21, 2021 12:23 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

+1 and thanks everyone for all the hard work

Checked:
- gpg signatures
- sha checksums
- binary convenience artifact runs
- src convenience artifacts builds with one command, and runs
- deb and rpm install and run

On Wed, 21 Apr 2021 at 14:57, Michael 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.
>
>
> +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

Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

[Scott Andreas]

Looks like we’ve crossed the 72-hour mark.

Shall we tally? 😀

> On Apr 23, 2021, at 4:43 AM, Paulo Motta  wrote:
> +1
> 
>> On Fri, 23 Apr 2021 at 06:35 Aleksey Yeshchenko 
>> wrote:
>> +1
 On 23 Apr 2021, at 08:51, Sam Tunnicliffe  wrote:
>>> +1
 On 23 Apr 2021, at 04:19, Jasonstack Zhao Yang <
>> jasonstack.z...@gmail.com> wrote:
 +1
 On Fri, 23 Apr 2021 at 08:16, Nate McCall  wrote:
> +1
> On Thu, Apr 22, 2021 at 6:59 AM Mick Semb Wever 
>> wrote:
>> Proposing the test build of Cassandra 4.0-rc1 for release.
>> sha1: 3282f5ecf187ecbb56b8d73ab9a9110c010898b0
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1235/org/apache/cassandra/cassandra-all/4.0-rc1/
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
>> 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]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>> -
>> 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: Welcome Stefan Miklosovic as Cassandra committer

[Scott Andreas]

Congratulations, Štefan!


From: David Capwell 
Sent: Monday, May 3, 2021 10:53 AM
To: dev@cassandra.apache.org
Subject: Re: Welcome Stefan Miklosovic as Cassandra committer

Congrats!

> On May 3, 2021, at 9:47 AM, Ekaterina Dimitrova  wrote:
>
> Congrat Stefan! Well done!!
>
> On Mon, 3 May 2021 at 11:49, J. D. Jordan  wrote:
>
>> Well deserved!  Congrats Stefan.
>>
>>> On May 3, 2021, at 10:46 AM, Sumanth Pasupuleti <
>> sumanth.pasupuleti...@gmail.com> wrote:
>>>
>>> Congratulations Stefan!!
>>>
 On Mon, May 3, 2021 at 8:41 AM Brandon Williams 
>> wrote:

 Congratulations, Stefan!

> On Mon, May 3, 2021 at 10:38 AM Benjamin Lerer 
>> wrote:
>
> The PMC's members are pleased to announce that Stefan Miklosovic has
> accepted the invitation to become committer last Wednesday.
>
> Thanks a lot, Stefan,  for all your contributions!
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members

 -
 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: Welcome Caleb Rackliffe as Cassandra committer

[Scott Andreas]

Congratulations, Caleb!

— Scott

> On May 14, 2021, at 10:29 AM, Andrés de la Peña  
> wrote:
> 
> Congrats Caleb, well deserved! :)
> 
>> On Fri, 14 May 2021 at 17:53, Paulo Motta  wrote:
>> 
>> Awesome, congratulations Caleb!! :)
>> 
>> Em sex., 14 de mai. de 2021 às 13:16, Patrick McFadin 
>> escreveu:
>> 
>>> YES! Love seeing this. A very much deserved congratulations Caleb!
>>> 
>>> Patrick
>>> 
>>> On Fri, May 14, 2021 at 9:12 AM David Capwell >> 
>>> wrote:
>>> 
>>>> Congrats!
>>>> 
>>>>> On May 14, 2021, at 8:52 AM, Charles Cao 
>> wrote:
>>>>> 
>>>>> Congrats Caleb! Well deserved :)
>>>>> 
>>>>> ~Charles
>>>>> 
>>>>>> On May 14, 2021, at 07:30, Yifan Cai  wrote:
>>>>>> 
>>>>>> Congrats Caleb!
>>>>>> 
>>>>>>> On May 14, 2021, at 6:56 AM, Joshua McKenzie >> 
>>>> wrote:
>>>>>>> 
>>>>>>> Congrats Caleb!
>>>>>>> 
>>>>>>>>> On Fri, May 14, 2021 at 9:10 AM Brandon Williams <
>> dri...@gmail.com
>>>> 
>>>> wrote:
>>>>>>>> 
>>>>>>>> Congrats Caleb! Well deserved.
>>>>>>>> 
>>>>>>>>> On Fri, May 14, 2021, 8:03 AM Mick Semb Wever 
>>>> wrote:
>>>>>>>>> 
>>>>>>>>> The PMC members are pleased to announce that Caleb Rackliffe has
>>>>>>>>> accepted the invitation to become committer.
>>>>>>>>> 
>>>>>>>>> Thanks heaps Caleb for helping make Cassandra awesome!
>>>>>>>>> 
>>>>>>>>> Congratulations and welcome,
>>>>>>>>> The Apache Cassandra PMC members
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>> -
>>>>>> 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: Welcome Dinesh Joshi as Cassandra PMC member

[Scott Andreas]

Congratulations, Dinesh!


From: Lorina Poland 
Sent: Wednesday, June 2, 2021 9:27 AM
To: dev@cassandra.apache.org
Subject: Re: Welcome Dinesh Joshi as Cassandra PMC member

Congratulations, Dinesh!

Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Wed, Jun 2, 2021 at 9:22 AM Vinay Chella 
wrote:

> Congratulations Dinesh.
>
> On Wed, Jun 2, 2021 at 9:18 AM Brandon Williams  wrote:
>
> > Congrats, Dinesh!
> >
> > On Wed, Jun 2, 2021 at 11:16 AM Benjamin Lerer 
> wrote:
> > >
> > >  The PMC's members are pleased to announce that Dinesh Joshi has
> accepted
> > > the invitation to become a PMC member.
> > >
> > > Thanks a lot, Dinesh, for everything you have done for the project all
> > > these years.
> > >
> > > Congratulations and welcome
> > >
> > > The Apache Cassandra PMC members
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Regards,
> Vinay Chella
> Engineering Manager, Data Abstractions Platform Team
>
> pronouns: he/him
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Are we ready for 4.0.0 (GA) ?

[Scott Andreas]

A second RC is appropriate given the revert of CASSANDRA-15899 necessitated by 
the discovery of CASSANDRA-16735: Adding columns via ALTER TABLE can generate 
corrupt sstables.

Ekaterina and Benedict's statement regarding the true positive rate of flaky 
tests also shows the value of resolving these, and that it would be good to pay 
this down as far as we can reasonably do so without unnecessarily withholding 
the release.

I do think it's possible that an RC2 build is a candidate for nomination as our 
GA release. I don't think the RC2 phase needs to be drawn-out, but believe it 
would build confidence for the project to have positive feedback from a release 
containing the fix for C-16735. If work paying down the remaining flaky tests 
surfaces a similar true positive rate, a third build might be warranted, and it 
would be to the benefit of our users - but I don't think we're far off.

I hope others are working to deploy the beta/RC builds and integrate + deploy 
changes from trunk into the releases they're deploying, as heavy contributors 
doing so provides us the best opportunity to catch these issues before our 
users do.

We're getting close.


From: bened...@apache.org 
Sent: Monday, June 14, 2021 3:03 PM
To: dev@cassandra.apache.org
Subject: Re: Are we ready for 4.0.0 (GA) ?

A rate of 4/30 is a rate of 13% true bugs, which worries me with respect to our 
promise of shipping a bug-free GA.  In past releases we have ensured no flaky 
tests, I think.

That said, I’ve not had the time to contribute to the fixing of flaky tests, so 
I’ll leave the decision to those who have, or otherwise have a strong opinion.


From: Ekaterina Dimitrova 
Date: Monday, 14 June 2021 at 20:51
To: dev@cassandra.apache.org 
Subject: Re: Are we ready for 4.0.0 (GA) ?
To give some context around the flaky tests, I pulled a quick report for the 
fixed ones during the past two months. It is attached for your reference.

To summarize, in two months 30 tickets for flaky tests were closed and only 4 
of them were Cassandra bugs(marked in red in the report), the rest of them were 
test fixes.

I think Butler and running in a loop any new tests before adding them to our 
test suite will help a lot. Also, Mick did a lot of work to stabilize Jenkins. 
Timeouts and resource issues are less common than before, that is  a win! Thank 
you Mick!

Best regards,
Ekaterina


On Mon, 14 Jun 2021 at 13:08, Adam Holmberg 
mailto:adam.holmb...@datastax.com>> wrote:
To the point of "long-term observability over flakies":

I will mention here that we intend to deploy a tool called Butler that we
have developed and used internally for a while. It compliments Jenkins to
present different views of test results, allowing developers to better
ascertain those tests that are flaky vs failing vs new regressions. We
already have a server provisioned for public hosting. The application
requires a bit of work to generalize for this project. We've been putting
it on while focused on getting 4.0 over the line, but should be getting to
it soon after.

On Mon, Jun 14, 2021 at 11:33 AM Mick Semb Wever 
mailto:m...@apache.org>> wrote:

> Are we ready to cut 4.0.0 (GA) once the following tickets land?
>
>  CASSANDRA-16733 – Allow operators to disable 'ALTER ... DROP COMPACT
> STORAGE' statements"
>  CASSANDRA-16669 – Password obfuscation for DCL audit log statements
>  CASSANDRA-16735 – Adding columns via ALTER TABLE can generate corrupt
> sstables
>
>
> A bit more background.
>
> 1. On our 4.0 GA board there's a few other tickets, which have priority but
> are not blockers for a GA release.
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
>
>  CASSANDRA-16715 – WEBSITE - June 2021 updates
>  CASSANDRA-12519 – dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
>  CASSANDRA-16681 – org.apache.cassandra.utils.memory.LongBufferPoolTest -
> tests are flaky
>  CASSANDRA-16689 – Flaky LeaveAndBootstrapTest
>
>
> 2. We also said we would get 5 green CI runs in a row. Progress on that
> front
> has been slow and risks delaying GA and our user base. It has had priority
> and there's been lots of momentum which is persisting: lots of flaky fixes
> committed; and the following are being discussed to keep pushing it in the
> right direction…
>  - Long-term observability over flakies
>  - Jenkins agent observability (infra stability)
>
> The past weeks has seen good progress on stability of ci-cassandra.a.o with
> the introduction of cpu docker limits imposed, and better monitoring of the
> agents so we can ensure we get the saturation and load we want. Dockerising
> the cqlshlib tests is also in progress.
>
> The alternative to a 4.0.0 GA release is a 4.0-rc2 release.
> Should the next release be: 4.0.0 (GA) or 4.0-rc2 ?
>


--
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

--

Re: [VOTE] Release Apache Cassandra 4.0-rc2

[Scott Andreas]

+1 nb


From: Andrés de la Peña 
Sent: Monday, June 28, 2021 1:04 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc2

+1 (nb)

On Mon, 28 Jun 2021 at 21:01, Jon Meredith  wrote:

> +1 (nb)
>
> On Mon, Jun 28, 2021 at 9:47 AM Yifan Cai  wrote:
> >
> > +1
> >
> >
> > - Yifan
> >
> > > On Jun 28, 2021, at 8:40 AM, Ekaterina Dimitrova <
> e.dimitr...@gmail.com> wrote:
> > >
> > > +1 Thanks everyone!
> > >
> > >> On Mon, 28 Jun 2021 at 11:39, Aleksey Yeschenko 
> wrote:
> > >>
> > >> +1
> > >>
> >  On 28 Jun 2021, at 14:05, Gary Dusbabek 
> wrote:
> > >>>
> > >>> +1; yay!
> > >>>
> >  On Sun, Jun 27, 2021 at 11:02 AM Mick Semb Wever 
> wrote:
> > >>>
> >  Proposing the test build of Cassandra 4.0-rc2 for release.
> > 
> >  sha1: 4c98576533e1d7663baf447e8877788096489165
> >  Git:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc2-tentative
> >  Maven Artifacts:
> > 
> > 
> > >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1237/org/apache/cassandra/cassandra-all/4.0-rc2/
> > 
> >  The Source and Build Artifacts, and the Debian and RPM packages and
> >  repositories, are available here:
> >  https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc2/
> > 
> >  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]: CHANGES.txt:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc2-tentative
> >  [2]: NEWS.txt:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc2-tentative
> >  [3]: The maven artifacts were accidentally prematurely made public.
> Docs
> >  have been updated to prevent this happening again.
> > 
> > >>
> > >>
> > >> -
> > >> 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
>
>

[DISCUSS] CASSANDRA-16767, CASSANDRA-16768, and CASSANDRA-16769 for 3.11.x

[Scott Carey]

I'd like to discuss the inclusion of the above tickets for a 3.11.x
release.  These are not a pure 'bug fix' so I'll need a waiver to get them
into 3.11.x  (and implicitly, 4.0.x).

The first two are straightforward oversights:  neither *nodetool
garbagecollect *nor *nodetool scrub* currently accept a *--user-defined*
parameter list of SSTables in the same way that *nodetool compact* does.

This is an operational problem for large tables.

I often need to scrub just one file that is corrupted for some reason, and
not scrub an entire 1TB+ of data for a table on a node.  This renders
'nodetool scrub' operationally useless for large tables.

For *garbagecollect* it is often operationally easy to identify which
tables are likely to be full of bloa- and operationally useful to do this
task in small increments.  The existing order that garbagecollect processes
SSTables prevents it from being useful in any incremental fashion -- if you
stop it and later restart, it will first process the SSTables you just
garbage collected.

The third ticket adds an option for* nodetool garbagecollect*,
*--oldest-fraction* that can select a fraction of the oldest table data in
bytes, and garbagecollect only the SSTables that 'cover' that percentage of
data.  Operationally, this lends itself to easy automation -- for example
running this once a week on 10% of a table's data would imply that there is
no data on disk that has been overwritten within the last 10 weeks.  This
caps data bloat in ways neither LCS nor STCS can currently achieve without
regular major compactions or full-pass garbagecollect.

I have a large LCS table that has existed in steady state for about two
years. Its oldest SSTable files were about 20 months old.  These old tables
were 95% bloated by that time -- 'garbagecollect' was able to shrink those
to 5% of their original size.
Being able to automate garbagecollect on a small fraction of the older data
would be a big disk space and performance win, without the downsides of a
major compaction.

The overall risk of these additions is low:

   - They do not modify any existing behavior, only add new options.
   - They re-use existing machinery for most of the work, and only adds
   logic in areas that are already well tested.  The areas that need the most
   scrutiny in review have good test coverage.
   - scripts that worked with nodetool before should continue to work
   except for the case where a keyspace is named --user-defined or
   --oldest-fraction, but this flaw already exists with other nodetool
   commands.
   - Three is no modification to sensitive areas like the read, write, or
   autocompaction path.  This merely does the same thing that is already done,
   just on a subset of SSTables rather than all of them.



Thanks for considering this proposal,

-Scott Carey


P.S.
You might wonder why the --oldest-fraction is necessary when one can use
--user-defined and some OS level scripting.

   1.  --oldest-fraction calculates the SSTable fraction based on the total
   data size, not file count.
   2. nodetool can avoid race conditions with autocompaction on sstable
   selection
   3. nodetool has access to the current state of active SSTables, a script
   just sees files on disk, files that might be scheduled for delete or files
   that are actively being written to.
   4. Even if used at a 100% fraction, it processes from oldest to newest
   by the SSTable generation number, meaning that if it is interrupted half
   way through, then re-started, it won't immediately work on the files that
   were just processed, as those will have the largest generation number.

Re: Patch Available status 2021-07-07

[Scott Hirleman]

Thanks so much Brandon and Benjamin for your important work here, very
valuable and much appreciated.

On Wed, Jul 7, 2021 at 9:20 AM Benjamin Lerer  wrote:

> Hi everybody,
>
> One of the main issues that has been raised in the* Attracting new
> contributors thread *is the time needed before a patch is reviewed.
> This is true for everybody but specially for newcomers that hesitate to
> manifest themselves on the dev channel or by pinging people directly.
>
> Part of the issue is a visibility problem and I hope that by providing more
> visibility to the tickets that are Patch Available we can improve the
> situation.
>
>
> *Newcomers Patch Available tickets: *
>
> We currently have 48 tickets from non-committers that are marked as Patch
> Available.
> Brandon has been going through the backlog doing some triaging for more
> than a week. I joined his effort a bit. Any help is welcome.
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-15663?jql=project%20%3D%20Cassandra%20AND%20assignee%20not%20in%20membersOf(Committers)%20AND%20assignee%20not%20in%20(brandon.williams%2C%20dikanggu%2C%20urandom%2C%20jay.zhuang%2C%20yifanc%2C%20cnlwsu%2C%20carlyeks%2C%20tjake%2C%20e.dimitrova%2C%20pauloricardomg)%20AND%20status%20%3D%20%22Patch%20Available%22%20%20%20ORDER%20BY%20updated%20DESC
>
> Currently 30 of those tickets do not have a reviewer:
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-13834?jql=project%20%3D%20Cassandra%20AND%20assignee%20not%20in%20membersOf(Committers)%20AND%20assignee%20not%20in%20(brandon.williams%2C%20dikanggu%2C%20urandom%2C%20jay.zhuang%2C%20yifanc%2C%20cnlwsu%2C%20carlyeks%2C%20tjake%2C%20e.dimitrova%2C%20pauloricardomg)%20AND%20status%20%3D%20%22Patch%20Available%22%20%20%20AND%20cf%5B12313420%5D%20is%20EMPTY%20ORDER%20BY%20updated%20DESC
>
> We also need a second reviewer for CASSANDRA-14325
> <https://issues.apache.org/jira/browse/CASSANDRA-14325>  (Java executable
> check succeeds despite no java on PATH)
>
> *Committers Patch Available tickets:*
>
> We also have 33 tickets from committers that are marked as Patch Available
> and 17 of those tickets have no reviewers.
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-16776?jql=project%20%3D%20Cassandra%20AND%20(assignee%20in%20membersOf(Committers)%20OR%20assignee%20in%20(brandon.williams%2C%20dikanggu%2C%20urandom%2C%20jay.zhuang%2C%20yifanc%2C%20cnlwsu%2C%20carlyeks%2C%20tjake%2C%20e.dimitrova%2C%20pauloricardomg))%20AND%20status%20%3D%20%22Patch%20Available%22%20AND%20cf%5B12313420%5D%20is%20EMPTY%20ORDER%20BY%20updated%20DESC
>
>
> As you can see we have a significant amount of Patch Available tickets. Any
> help to review those tickets is welcome.
>
> Thanks in advance for your help.
>


-- 
Scott Hirleman
scott.hirle...@gmail.com

Re: [DISCUSS] Clarifying the CEP process

[Scott Hirleman]

Or maybe someone _can_ comment on the JIRA but should also for sure put
that same comment in the discussion thread? That way, it is at worst
redundant and doesn't get lost as a comment on a JIRA many may not see?

On Thu, Jul 8, 2021 at 3:32 AM Mick Semb Wever  wrote:

> > I think that’s a bit extreme – …
>
>
>
> Yeah, that was kinda my intention. But my thinking was just about getting
> us out of our habits of using JIRA. Of course I didn't mean any censure.
> Once we have some precedence in place, common-sense should prevail.
>
>
> Perhaps we should put together a cheat sheet for kinds of discussion and
> > what venue to raise them in at different phases in a CEP lifecycle.
>
>
>
> Agree.
>


-- 
Scott Hirleman
scott.hirle...@gmail.com

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

[Scott Andreas]

+1nb.

Thank you for sharing a Circle run, Sumanth!


From: Sumanth Pasupuleti 
Sent: Wednesday, July 14, 2021 12:52 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 (nb)
Confirmed passing j8 UTs and dtests
https://app.circleci.com/pipelines/github/sumanth-pasupuleti/cassandra/77/workflows/7b0ad00d-7ae3-41d2-b1a7-82fa63b7

On Wed, Jul 14, 2021 at 11:03 AM Jeremy Hanna 
wrote:

> +1 (nb)
>
> > On Jul 15, 2021, at 3:42 AM, Blake Eggleston
>  wrote:
> >
> > +1
> >
> >> On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko 
> wrote:
> >>
> >> +1
> >>
>  On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
> >>>
> >>> +1
> >>>
>  On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever 
> wrote:
> 
>  Proposing the test build of Cassandra 4.0.0 for release.
> 
>  sha1: 924bf92fab1820942137138c779004acaf834187
>  Git:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
>  Maven Artifacts:
> 
> 
> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
> 
>  The Source and Build Artifacts, and the Debian and RPM packages and
>  repositories, are available here:
>  https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> 
>  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]: CHANGES.txt:
> 
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
>  [2]: NEWS.txt:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>>
> >>> --
> >>> Jonathan Ellis
> >>> co-founder, http://www.datastax.com
> >>> @spyced
> >>
> >>
> >> -
> >> 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: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

[Scott Andreas]

+1 nb

> On Jul 23, 2021, at 2:46 PM, 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.
>> 
>> 
> 
> +1
> 
> 
> Tested:
> sha1, md5, sha256, sha512 match.
> gpg signatures match.
> Source artefact builds. (and doesn't contain compiled dependencies)
> Tarball Binary artefact runs.
> Debian binary package runs.
> Redhat binary package runs.

Re: [VOTE] Release Apache Cassandra 3.0.25

[Scott Andreas]

+1nb, primarily for CASSANDRA-16735.

> On Jul 25, 2021, at 10:40 AM, Brandon Williams  wrote:
> 
> I am proposing the test build of Cassandra 3.0.25 for release.
> 
> sha1: 06235e93e16d1f483a3b03ba02f8fb29e33305fa
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.25-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1245/org/apache/cassandra/cassandra-all/3.0.25/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.25/
> 
> 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]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.25-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.25-tentative
> 
> -
> 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: [VOTE] Release Apache Cassandra 3.11.11

[Scott Andreas]

+1nb

> On Jul 25, 2021, at 12:06 PM, Brandon Williams  wrote:
> 
> I am proposing the test build of Cassandra 3.11.11 for release.
> 
> sha1: 4cafe2288e56e1135d65e76adbcd6c2de9306d6b
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.11-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1246/org/apache/cassandra/cassandra-all/3.11.11/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.11/
> 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]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.11-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.11-tentative
> 
> -
> 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: [VOTE] CEP-10: Cluster and Code Simulations

[Scott Andreas]

+1 nb


From: Sam Tunnicliffe 
Sent: Tuesday, July 27, 2021 12:54 AM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] CEP-10: Cluster and Code Simulations

+1

> On 26 Jul 2021, at 11:51, bened...@apache.org wrote:
>
> Proposing the CEP-10 (Cluster and Code Simulations) for adoption
>
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10%3A+Cluster+and+Code+Simulations
> Discussion: 
> https://lists.apache.org/thread.html/rc908165994b15a29ef9c17b0b1205b2abc5bd38228b5a0117e442104%40%3Cdev.cassandra.apache.org%3E
>
> The vote will be open for 72 hours.
> Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s and no binding vetoes.


-
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: [DISCUSS] Releases after 4.0

[Scott Carey]

Just my random thoughts as an outsider while trying to look at this thread
months after the fact.  I could have missed some details along the way and
might not quite understand the final proposal.


On this topic in general, it seems a bit odd to me to have support / fixes
for a release defined primarily as an amount of time after the release date
given that future releases can't be guaranteed to hit a specific month.  It
also causes exceptions to the rule for 3.0 and 3.11.   If instead, the
support interval was primarily defined relative to the date of future
releases, the result would be a (near) constant number of supported
releases, regardless of the pace of the releases.  A minimum support
interval would probably be needed in case the pace quickens to faster than
one a year, however.

For example, if major version N is released today, it could mean that
existing releases all 'roll down' a tier 2 months after that:  N-3 has 2
months left of critical/high severity bug fixes before retirement,,  N-2
becomes high severity only in 3 months, etc.  The 2 month buffer in this
example allows for a last round of important fixes to occur right after a
major release, when it is likely that resources that were focused on the
major release free up to do any final work / review on fixes for older or
retiring branches..

In effect for 4.0, this would mean something like
   4.0 full support until two months after 6.0 is released, or 2 years,
whichever is longer.
   4.0 critical fixes until two months after 7.0 is released, or 3 years,
wichever is longer.
this automatically takes care of the long time delay for 3.0 and 3.11
without any special exceptions for them.  And in the future, if there was
an extra-long release for some reasonit would not cause a reduction in the
number of actively supported versions, nor affect the 'cadence' of
major-release -> final fixups for old branches.  It also allows for
occasional shorter releases without any increase in the total branches
supported if the average of the last few is still about one year.  For
example, maybe major release X takes 14 months, then major release X+1
takes 10 months.





On Mon, Aug 2, 2021 at 10:55 AM Joshua McKenzie 
wrote:

> Where did we land on this? Joey's statement above:
>
> > * 4.0: Fully supported until April 2023 and high severity bugs until
> April
> > 2024 (2 year full, 1 year bugfix)
> > * 3.11: Fully supported until April 2022 and high severity bugs until
> > April 2023 (1 year full, 1 year bugfix)
> > * 3.0: Supported for high severity correctness/performance bugs until
> > April 2022 (1 year bugfix)
> > * 2.2+2.1: EOL immediately.
> > Then going forward we could have this nice pattern when we cut the yearly
> > release:
> > Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> > Y(n-1): Fully supported for 1 more year and supported for high severity
> > correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> > Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> > bugfix)
>
>
> Doesn't look like it matches what we have on the site:
>  https://cassandra.apache.org/_/download.html
>
> Apache Cassandra 2.2
> > Released on 2020-11-04, and supported until 4.1 release (April 2022) with
> > critical fixes only.
>
>
> Also - do we need to revise our dates from April 2022 to July 2022 to
> reflect when GA hit?
>
>
>
> On Thu, Apr 1, 2021 at 10:06 AM Ekaterina Dimitrova  >
> wrote:
>
> > +1 on my end about the Roadmap page and to start looking in the future
> > again :-) I am also optimistic about the assumption of having 4.0 out in
> > April :-) Exciting times
> >
> > On Thu, 1 Apr 2021 at 9:37, Benedict Elliott Smith 
> > wrote:
> >
> > > > it would make sense to put that information on a *Roadmap* page
> > >
> > > That makes sense to me, and I'm looking forward to agreeing a roadmap.
> I
> > > think it will be nice for the project to start properly looking to the
> > > future again.
> > >
> > > On 01/04/2021, 14:06, "Benjamin Lerer" 
> > > wrote:
> > >
> > > Thanks everybody.
> > >
> > > I opened CASSANDRA-16556
> > >  to update
> > the
> > > end
> > > of support dates for the different versions. I assumed that we will
> > > manage
> > > to release 4.0-GA in April (otherwise I will re-update them ;-) )
> > >
> > > Concerning the release cadence, it seems that we do not have a
> proper
> > > place
> > > to put that information on our website. In an offline discussion
> Mick
> > > raised the point that it would make sense to put that information
> on
> > a
> > > *Roadmap
> > > *page. That makes sense to me. I will trigger the roadmap
> discussion
> > > next
> > > week and once we agree on some roadmap, I propose to create a new
> > page
> > > for
> > > it where I will include the information on the release cadence.
> > >
> > > I am fully open to another proposal.
> > >
> > >
> > > On Tue, Mar 30, 2021 at 11:24 AM 

Re: [DISCUSS] CASSANDRA-16767, CASSANDRA-16768, and CASSANDRA-16769 for 3.11.x

[Scott Carey]

Thank you Brandon, for answering my questions on slack, and providing early
feedback on these ideas more than a month before I created the patches and
replying here.

Does anyone else have any comments or opinions?  Can a decision be reached
one way or another?  It is my understanding that we'll need more than one
+1 to move forward here.

I understand that the 4.0 release was a busy time, and that many probably
saw this, thought about replying, but got too busy and never did.
However, in light of the recent discussions around attracting new
contributors, I would like to highlight that being left in limbo with no
resolution is worse than being told "no", especially for new contributors.




On Fri, Jul 2, 2021 at 1:23 PM Brandon Williams  wrote:

> On Tue, Jun 29, 2021 at 5:49 PM Scott Carey  wrote:
> >
> > I'd like to discuss the inclusion of the above tickets for a 3.11.x
> > release.  These are not a pure 'bug fix' so I'll need a waiver to get
> them
> > into 3.11.x  (and implicitly, 4.0.x).
> >
> > The first two are straightforward oversights:  neither *nodetool
> > garbagecollect *nor *nodetool scrub* currently accept a *--user-defined*
> > parameter list of SSTables in the same way that *nodetool compact* does.
> >
> > This is an operational problem for large tables.
> >
> > I often need to scrub just one file that is corrupted for some reason,
> and
> > not scrub an entire 1TB+ of data for a table on a node.  This renders
> > 'nodetool scrub' operationally useless for large tables.
>
> I think that given not having user defined options for these
> compaction types is clearly an oversight, and that the alternative of
> deleting the large 1TB+ sstable and then repairing is a cure worse
> than the disease, this should be added to 3.11.x and 4.0.x. I am +1
> here.
>
> > For *garbagecollect* it is often operationally easy to identify which
> > tables are likely to be full of bloa- and operationally useful to do this
> > task in small increments.  The existing order that garbagecollect
> processes
> > SSTables prevents it from being useful in any incremental fashion -- if
> you
> > stop it and later restart, it will first process the SSTables you just
> > garbage collected.
> >
> > The third ticket adds an option for* nodetool garbagecollect*,
> > *--oldest-fraction* that can select a fraction of the oldest table data
> in
> > bytes, and garbagecollect only the SSTables that 'cover' that percentage
> of
> > data.  Operationally, this lends itself to easy automation -- for example
> > running this once a week on 10% of a table's data would imply that there
> is
> > no data on disk that has been overwritten within the last 10 weeks.  This
> > caps data bloat in ways neither LCS nor STCS can currently achieve
> without
> > regular major compactions or full-pass garbagecollect.
>
> This is a less obvious thing to be added, and I personally lack the
> operational experience to comment on how much relief this would
> provide firsthand, so I'll leave that to others.  But it does make
> sense to me and since it isn't heavily modifying anything my
> inclination is that this could be an acceptable addition as well.
>
> Kind Regards,
> Brandon
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Welcome Adam Holmberg as Cassandra committer

[Scott Andreas]

Congratulations, Adam! 🎉


From: Joseph Lynch 
Sent: Tuesday, August 17, 2021 7:44 AM
To: dev@cassandra.apache.org
Subject: Re: Welcome Adam Holmberg as Cassandra committer

Congratulations Adam!

On Tue, Aug 17, 2021 at 10:25 AM Jordan West  wrote:
>
> Congrats Adam!
>
> On Tue, Aug 17, 2021 at 5:51 AM Paulo Motta 
> wrote:
>
> > Congratulations and well deserved Adam!
> >
> > Em ter., 17 de ago. de 2021 às 03:58, Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> escreveu:
> >
> > > Congratulations Adam!!
> > >
> > > On Mon, Aug 16, 2021 at 10:32 PM Berenguer Blasi <
> > berenguerbl...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Well done Adam, congrats!
> > > >
> > > > On 16/8/21 18:27, Andrés de la Peña wrote:
> > > > > Congrats Adam, well deserved!
> > > > >
> > > > > On Mon, 16 Aug 2021 at 17:14, Patrick McFadin 
> > > > wrote:
> > > > >
> > > > >> Great to see you on the committer list Adam!
> > > > >>
> > > > >> On Mon, Aug 16, 2021 at 7:06 AM Jonathan Ellis 
> > > > wrote:
> > > > >>
> > > > >>> Well deserved.  Congratulations!
> > > > >>>
> > > > >>> On Mon, Aug 16, 2021 at 5:57 AM Benjamin Lerer 
> > > > >> wrote:
> > > >   The PMC members are pleased to announce that Adam Holmberg has
> > > > >> accepted
> > > >  the invitation to become committer.
> > > > 
> > > >  Thanks a lot, Adam, for everything you have done for the project
> > all
> > > > >>> these
> > > >  years.
> > > > 
> > > >  Congratulations and welcome
> > > > 
> > > >  The Apache Cassandra PMC members
> > > > 
> > > > >>>
> > > > >>> --
> > > > >>> Jonathan Ellis
> > > > >>> co-founder, http://www.datastax.com
> > > > >>> @spyced
> > > > >>>
> > > >
> > > > -
> > > > 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: [DISCUSS] CEP 14: Paxos Improvements

[Scott Andreas]

Benedict, thank you for sharing this CEP!

Adding some notes on why I support this proposal:

- Reducing common-case round trips from 4x to 2x on writes and 2x to 1x on 
reads is a huge improvement. This latency reduction may be sufficient to allow 
many users of Cassandra who operate in a single datacenter, availability zone, 
or region to migrate to a multi-region topology.

- The Cluster Simulation work described in CEP-10 provides a toolchain for 
probabilistically-exhaustive validation and simulation of transactional 
correctness, allowing assertion of linearizability in the presence of 
adversarial thread scheduling and message ordering over an unbounded number of 
simulated clusters and transactions.

- Some use cases may see a superlinear increase in LWT performance due to a 
reduction in contention afforded by fewer message round-trips. E.g., halving 
latency shortens the interval during which competing transactions may conflict, 
reducing contention and improving throughput beyond a level that would be 
afforded by the latency reduction alone.

- Better safety among range movements: Electorate verification during range 
movements provides a stronger assertion of linearizability via assurance of the 
set of instances voting on a transaction.

– Scott


From: bened...@apache.org 
Sent: Wednesday, August 18, 2021 2:31 PM
To: dev@cassandra.apache.org
Subject: [DISCUSS] CEP 14: Paxos Improvements

RE: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements

I’m proposing this CEP for approval by the project. The goal is to both improve 
the performance of LWTs and to ensure their correctness across a range of 
scenario like range movements. This work builds upon the Simulator CEP that has 
been recently adopted, and patches will follow in the coming weeks.

If you have any concerns or questions please raise them here for discussion.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Potential issues during 4.0 upgrade

[Scott Andreas]

Thank you for raising this, Sam!

Agreed this is a bug that warrants releasing 4.0.1 and notifying user@.

To elaborate on impact, this issue can produce a state in rolling 3.x -> 4.0 
upgrades in which 4.0 nodes fail to serialize gossip state during the shadow 
round once the size of this state exceeds 128kb. This prevents new instances 
from coming up. Once in this state, it is also not possible for new instances 
to start up and join the ring. If existing 4.0 instances restart, they will 
also be unable to gossip and remain down.

It's a pretty serious situation without an obvious way out aside from deploying 
this patch. We should get a new release out quickly.

– Scott


From: Sam Tunnicliffe 
Sent: Monday, August 23, 2021 11:27 AM
To: dev@cassandra.apache.org
Subject: Potential issues during 4.0 upgrade

Hi all,

I just opened a JIRA which is relevant to those running large clusters (around 
the 400 node range) and who have plans to upgrade to 4.0 upgrades soon.

https://issues.apache.org/jira/browse/CASSANDRA-16877 
<https://issues.apache.org/jira/browse/CASSANDRA-16877>

The issue is that in large clusters, the size of gossip messages sent when a 
node (re)starts may exceed the hard limit of the urgent message channel. This 
causes an error on the sender and ultimately the message is dropped. This in 
turn can cause startup failures and/or partial loss of availability.

Fortunately, the fix is quite simple and I’ve submitted a patch that I and 
other contributors have been running since discovering this issue and can 
confirm resolves the problem. It would be great to get it reviewed and merged 
ASAP and then cut a 4.0.1 release. In the meantime, it may be wise to suggest 
that operators of large clusters hold off on any planned 4.0 upgrades.

Thanks,
Sam


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Java support roadmap

[Scott Andreas]

+1 for moving Java 11 support out of experimental for 4.0 at minimum, and no 
concern with doing so for 3.0/3.11 if someone were to propose.

I and contributors I work with have deployed 4.0 + JDK11 in production, have 
found no issues, and would treat any issues that arise as ones we’re able to 
jump on and contribute development + review resources to resolve in the project.

No JDK11-specific bugs to report, though users should of course test their 
ancillary tooling for compatibility. As an example, a change in the File API in 
Java 10 altered the precision of filesystem timestamps as returned by the API, 
so users upgrading from 8 to 11 who have a dependency on timestamp identity may 
want to examine it.

That JDK change was: https://bugs.openjdk.java.net/browse/JDK-8177809

— Scott

---
Mobile

On Aug 26, 2021, at 7:35 AM, Ekaterina Dimitrova  wrote:

Hi everyone,
I had a few people asking me recently about the Java 11 support.
I came across this thread we had last year -
https://lists.apache.org/thread.html/r38f6beaa22e247cb38212f476f5f79efdc6587f83af0397406c06d7c%40%3Cdev.cassandra.apache.org%3E
.
I think we have all tests running in both Java 8 and Java 11 for trunk and
cassandra-4.0 in both Jenkins and CircleCI.
Does anyone know about any Java 11 specific bugs discovered? I personally
haven't heard of any in the past year. What is the plan of the community
for moving Java 11 support out of experimental?
Also, Java 17 LTS GA is planned for Sepember 2021 and I can try to test it
with trunk.
Any thoughts?
Last but not least, do we know  anyone running Java 11 in production?
This thread was really opened as a stage to share our thoughts and
hopefully come up with a plan as a community.

Looking forward to seeing what people think here.

Thank you,
Ekaterina

Re: [VOTE] CEP-14: Paxos Improvements

[Scott Andreas]

+1

> On Aug 27, 2021, at 12:58 PM, Mick Semb Wever  wrote:
> 
> 
>> 
>> 
>> Proposal:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements
>> Discussion:
>> https://lists.apache.org/thread.html/r1af3da2d875ef93479e3874072ee651f406b96c915759c7968d3266e%40%3Cdev.cassandra.apache.org%3E
>> 
>> The vote will be open for 72 hours.
>> Votes by committers are considered binding.
>> A vote passes if there are at least three binding +1s and no binding
>> vetoes.
>> 
> 
> 
> +1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Cassandra Summit CFP update

[Scott Hirleman]

To come over the top on this, speaking can be great for your career and
company. And Patrick will help you find a great topic. And you only have to
deal with him for 15min, which is _mostly_ doable ;p

If you need help getting internal approvals - communications or potentially
even budget -, we have a CFP Concierge that can partner with you to try to
get you over the line.

Since these lists are mostly technical people, a talk can be a great chance
to partner with someone in your organization on the business and/or
engineering exec side to tell the story of something awesome you built
enabled by Cassandra. So leverage it to get some visibility internally for
the awesome work you are doing.

Again, you can easily grab time with Patrick to find a topic that would
make a great talk. He loves doing this stuff. So if you are on the fence,
why not submit? If you aren't sure if you'll get approved, is there a harm
in submitting what would be an awesome talk? Maybe a 30min harm to your
schedule at most?

Patrick 15min CFP consult (seriously, take advantage, he'll get you excited
about your topic):
https://calendly.com/patrick-mcfadin/15-minute-cassandra-summit-cfp-consult

On Tue, Nov 29, 2022 at 12:53 PM Patrick McFadin  wrote:

>
>
>
>
>
>
>
>
>
> *Hi everyone,An update on the current CFP process for Cassandra
> Summit. There are currently 23 talk submissions which are far behind what
> we need. Two days of tracks mean we need 60 approved talks. Ideally, we
> need over 100 submitted to ensure we have a good pool of quality talks. We
> already have quite a few vendor pitches that have nothing to do with
> Cassandra. Think of it as like CFP
> spam. https://events.linuxfoundation.org/cassandra-summit/program/cfp/
> <https://events.linuxfoundation.org/cassandra-summit/program/cfp/>The
> deadline is December 11th. That is 12 days! If you are assuming that will
> get pushed out, don’t. We have a tight schedule before March 13th. Speakers
> must be notified of talk acceptance by the beginning of January to book
> travel in time. The full schedule will be published by mid-January. That
> being said, I have talked to quite a few people that are working on a
> submission. Thank you for being willing to create a talk! How can I help
> you get it completed? Again, here is my Calendly link if you need to talk
> it over:
> https://calendly.com/patrick-mcfadin/15-minute-cassandra-summit-cfp-consult
> <https://calendly.com/patrick-mcfadin/15-minute-cassandra-summit-cfp-consult>This
> is our conference! Let’s make it a festival of the database we love and the
> things we build with it. One more thing. We need sponsors! If your employer
> can, this is a great opportunity to get your brand out in front of people
> building the future. I’ll be back. Go submit a talk. You’ll be happy you
> did! Patrick*
>


-- 
Scott Hirleman
scott.hirle...@gmail.com

Re: [VOTE] CEP-25: Trie-indexed SSTable format

[C. Scott Andreas]

+1nbOn Dec 19, 2022, at 1:27 PM, Josh McKenzie  wrote:+1On Mon, Dec 19, 2022, at 11:54 AM, SAURABH VERMA wrote:+1On Mon, Dec 19, 2022 at 9:36 PM Benjamin Lerer  wrote:+1Le lun. 19 déc. 2022 
à 16:31, Andrés de la Peña  a écrit :+1On Mon, 19 Dec 2022 at 15:11, Aleksey Yeshchenko  wrote:+1On 19 Dec 2022, at 13:42, Ekaterina Dimitrova  wrote:+1On Mon, 
19 Dec 2022 at 8:30, J. D. Jordan  wrote:+1 nb> On Dec 19, 2022, at 7:07 AM, Brandon Williams  wrote:> > +1> > Kind Regards,> Brandon> >> On Mon, Dec 19, 
2022 at 6:59 AM Branimir Lambov  wrote:>> >> Hi everyone,>> >> I'd like to propose CEP-25 for approval.>> >> Proposal: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format>> Discussion: https://lists.apache.org/thread/3dpdg6dgm3rqxj96cyhn58b50g415dyh>> >> The vote will be open for 72 hours.>> 
Votes by committers are considered binding.>> A vote passes if there are at least three binding +1s and no binding vetoes.>> >> Thank you,>> Branimir-- Thanks & Regards,Saurabh Verma, India

CircleCI Security Incident

[C. Scott Andreas]

FYI for visibility among our development community -

CircleCI reports they have experienced a security incident and are asking all 
users to immediately rotate any secrets stored in CircleCI (environment 
variables, object storage credentials, etc). They’re also recommending 
monitoring any internal systems for unauthorized access from December 21.

Details: https://circleci.com/blog/january-4-2023-security-alert/

— Scott