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

[Jordan West]

Thanks Dave!

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?

Jordan

On Wed, Oct 9, 2024 at 13:44 Dave Herrington  wrote:

> Jon/Jordan,
>
> Happy to contribute to easy-cass-stress in any way I can that will help
> the cause.  I'd probably be most effective in a QA role, since much of my
> field work with DataStax customers involves developing load & stress tests
> to measure the outer bounds of cluster capacity under max load conditions.
> I have used cassandra-stress, have a lot of experience with NoSQLBench and
> am starting to explore & learn easy-cass-stress.
>
> -Dave
>
> David A. Herrington II
> President and Chief Engineer
> RhinoSource, Inc*.*
>
> www.rhinosource.com
>
> On Wed, Oct 9, 2024 at 11:08 AM Jon Haddad 
> wrote:
>
>> Thanks everyone for a good discussion.  To everyone interested in
>> contributing, I appreciate your interest and I'm incredibly proud people
>> have found the project useful.  I hope making it an official part of the
>> project will lead to further improvements as more people contribute.  Very
>> exciting!
>>
>> I just merged a PR from Jordan to make easy-cass-stress installable via a
>> homebrew tap.  I'd love to preserve this functionality, ideally moved under
>> the project.  Assuming we have this working, we should also start releasing
>> Cassandra this way to make it easier for OSX users to install locally, but
>> that's a separate discussion.
>>
>> Jon
>>
>>
>> On Wed, Oct 9, 2024 at 11:48 AM Jordan West  wrote:
>>
>>> Count me in as a contributor if we take the donation. I think the only
>>> hurdle is figuring out the IP stuff which as Mick said should be solvable.
>>>
>>> Jordan
>>>
>>> On Tue, Oct 8, 2024 at 20:34 Doug Rohrer  wrote:
>>>
 Clarification - there would be some real value in donating 
 *easy-cass-stress
 (as the subject says)*, not lab… The demo was about easy-cass-lab,
 which uses easy-cass-stress.

 Thanks,

 Doug

 On Oct 8, 2024, at 1:51 PM, Doug Rohrer  wrote:

 Hey folks,

 I just wanted to resurface this conversation, especially after Jon and
 Jordon’s talk at Community over Code this week. I think there would be some
 real value in getting easy-cass-lab donated and part of the ecosystem.

 To try to summarize:

 - Jon would like to donate if his active development of the project
 isn’t negatively affected.

 - It seems a separate repo/subproject is the right way to go rather
 than bringing it in-tree

 - Several other folks have stepped up to be co-maintainers (thanks!)

 - Some form of IP clearance would need to be done if this were to move
 forward.

 It seems the major concerns other than IP clearance were taken care of
 in the thread. Is there an appetite to bring easy-case-stress into the
 Apache umbrella and, if so, how would we move forward from here?

 Doug Rohrer

 On May 3, 2024, at 1:16 PM, Alexander DEJANOVSKI 
 wrote:

 
 Hi folks,

 I'm familiar with the codebase and can help with the maintenance and
 evolution.
 I already have some additional profiles that I can push there which
 were never merged in the main branch of tlp-cluster.

 I love this tool (I know I'm biased) and hope it gets the attention it
 deserves.

 Le mar. 30 avr. 2024, 23:17, Jordan West  a écrit :

> I would likely commit to it as well
>
> Jordan
>
> On Mon, Apr 29, 2024 at 10:55 David Capwell 
> wrote:
>
>> So: besides Jon, who in the community expects/desires to maintain
>> this going forward?
>>
>>
>> I have been maintaining a fork for years, so don’t mind helping
>> maintain this project.
>>
>> On Apr 28, 2024, at 4:08 AM, Mick Semb Wever  wrote:
>>
>> A separate subproject like dtest and the Java driver would maybe help
>>> address concerns with introducing a gradle build system and Kotlin.
>>>
>>
>>
>> Nit, dtest is a separate repository, not a subproject.  The Java
>> driver is one repository to be in the Drivers subproject.  Esoteric 
>> maybe,
>> but ASF terminology we need to get right :-)
>>
>> To your actual point (IIUC), it can be a separate repository and not
>> a separate subproject.  This permits it to be kotlin+gradle, while not
>> having the formal subproject procedures.  It still needs 3 responsible
>> committers from the get-go to show sustainability.  Would
>> easy-cass-stress have releases, or always be a codebase users work 
>> directly
>> with ?
>>
>> Can/Should we first demote cassandra-stress by moving it out to a
>> separate repo ?
>>  ( Can its imports work off non-snapshot dependencies ? )
>> It might feel like an extra prerequisite step to introduce, but maybe
>> it helps move the needl

Re: [DISCUSS] 5.0 Upgrades and CASSANDRA-19989

[Caleb Rackliffe]

Just to close the loop, this is committed to 5.0 and trunk.

On Wed, Oct 9, 2024 at 3:07 PM Caleb Rackliffe 
wrote:

> Hey folks,
>
> I think we should probably not recommend 5.0 upgrades until
> CASSANDRA-19989 
> is released. It could cause a significant amount of unnecessary read-repair
> activity on TTL'd data while an upgrade is in progress.
>

Re: GoCQL module name change and next release

[João Reis]

I like that too, I initially considered proposing that but thought I'd
propose delivering v5 and vector support faster but +1 on making these two
features a part of 2.0.0 instead.

Štefan Miklošovič  escreveu (quinta, 10/10/2024
à(s) 23:37):

> I would do 1) and 2) together. I would rename the module in 2.0.0 and
> there would be v5 and vector support as well. It would motivate us to get
> v5 and vector out while using that opportunity to rename it to 2.0.0.
>
> On Thu, Oct 10, 2024 at 11:42 AM João Reis  wrote:
>
>> Hi,
>>
>> Following the GoCQL donation we need to change the module name so it
>> matches the new repo URL. Currently users have to keep using the old name
>> unless they add a rewrite to go.mod.
>>
>> There was a discussion on what the approach should be on #1776 [1] and
>> I've created CASSANDRA-19993 [2] to track this work. Since this is a
>> breaking change (it requires users to modify their imports or add a rewrite
>> to go.mod) we need to bump the major version when we do this.
>>
>> With this in mind, there's some topics to discuss:
>>
>> 1) When do we want to make this module name change happen? We can keep
>> doing minor releases under the old module name but it is a bit confusing
>> for new users to have to import gocql using a Github repo URL that
>> effectively no longer exists. Also the amount of users that will be
>> impacted by the module name change will only increase the longer we wait.
>>
>> 2) Should we take this opportunity to include other breaking change
>> related issues with the module name change? Martin mentioned on the gocql
>> mailing list [3] that there's a few issues on Github that are tagged with
>> "semver-major" [4] and these should be considered for a new major release.
>>
>> My take on these topics is that we should work on some of those tagged
>> issues when we decide to change the module name as long as these breaking
>> changes don't require users to significantly rewrite parts of their
>> application. We should make this upgrade and module name change to be the
>> least intrusive as possible for users. Note that *the
>> cassandra-gocql-driver project officially maintains the latest release*
>> *only* (single active branch) so doing a major release effectively drops
>> support for the previous major immediately which means we have an even
>> stronger incentive to make the upgrade as easy as possible.
>>
>> I'm planning on reviewing protocol v5 and vector support PRs soon and we
>> should probably make these 2 contributions available to users as soon as
>> possible. To do this we can do a minor release before we start working on
>> the next major. I'm also open to the idea that we could postpone the major
>> release development and keep doing minor releases for a little longer under
>> the old module name.
>>
>> In summary, my proposal for a short to medium term roadmap is:
>>
>> 1) Release 1.8.0 with v5 and vector support (and potentially other small
>> PRs, I've only looked at these 2 issues yet)
>> 2) Release 2.0.0 with the module name change, some (if not all) of the
>> "semver-major" tagged issues and other contributions
>>
>> Let me know your thoughts,
>> João Reis
>>
>> [1] https://github.com/apache/cassandra-gocql-driver/issues/1776
>> [2] https://issues.apache.org/jira/browse/CASSANDRA-19993
>> [3] https://groups.google.com/g/gocql/c/v0FruczBb2w/m/7Hc3_W9QCgAJ
>> [4]
>> https://github.com/apache/cassandra-gocql-driver/issues?q=is%3Aopen+is%3Aissue+label%3Asemver-major
>>
>