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

[Mick Semb Wever]

On Wed, 23 Oct 2024 at 05:48, Jordan West  wrote:

> Josh/Mick, where does that leave us? I’d like to start with the smaller
> scope Josh described in his last email. We can tackle in-tree/stress
> separately.
>
> I was going to start working on getting signed ICLAs. Does that still
> sound like the right next step? Or is that also not necessary unless we
> take the approach originally described by Mick?
>


I'm working on getting the SGA from DataStax.   And yes, please collect
ICLAs from those that have contributed past SHA
2d4542c27d3f1c0e24899c01247b9a8ee3c9a238

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

[Jordan West]

Josh/Mick, where does that leave us? I’d like to start with the smaller
scope Josh described in his last email. We can tackle in-tree/stress
separately.

I was going to start working on getting signed ICLAs. Does that still sound
like the right next step? Or is that also not necessary unless we take the
approach originally described by Mick?

Jordan

On Tue, Oct 15, 2024 at 04:23 Josh McKenzie  wrote:

> IIUC there's no subproject involved here.
>
> To elaborate a touch: this isn't a subproject in terms of governance. i.e.
> no 3 dedicated PMC sponsors required, no "pmc must legally vote on
> releasing an artifact" (unless of course we start independently releasing
> artifacts for it as opposed to just pointing people at the repo and tags),
> and no real "we must have at least N people with a commit-bit and a focus
> on this area for it to be taken in".
>
> Makes sense given the context and purpose of the tool and keeping it
> lighter weight should make it easier for everyone to collaborate on it, to
> Mick's point - much like the ccm and dtest repos.
>
> On Tue, Oct 15, 2024, at 3:19 AM, Mick Semb Wever wrote:
>
>
> IIUC there's no subproject involved here.  This is a separate repository
> coming in, akin to cassandra-dtest (plus releases).
>
> The question wrt replacing cassandra-stress was only thinking about
> something down the road, to help smoke out stuff like compaction-stress.
> No suggestion implied that easy-cass-stress should be moved in-tree.
>
>
>
> On Tue, 15 Oct 2024 at 00:15, David Capwell  wrote:
>
> I think we should just accept easy-cass-stress as a subproject and go
> from there.  Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.
>
>
> I strongly agree with you here. The proposal is to just add the project
>
>
> On Oct 14, 2024, at 11:08 AM, C. Scott Andreas 
> wrote:
>
> Separating the two is completely fine yep -- just mentioned since
> deprecation/removal of stress also came up in the thread.
>
> Let's complete the donation. Just wanted to make sure we don't remove
> compaction-stress without a substitute.
>
> – Scott
>
> On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote:
>
>
> I think we should just accept easy-cass-stress as a subproject and go
> from there. Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.
>
> Kind Regards,
> Brandon
>
> On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad 
> wrote:
>
>
> Scott, I think introducing replacing compaction stress as a requirement
> here adds unnecessary friction to the donation process. I'd prefer to avoid
> coupling the two things. Unless you or someone else is volunteering to
> rewrite it I think this would effectively halt the donation, which I doubt
> is your intention. Can we do that as a separate thing?
>
> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*,
> and renaming it would make it clear that it's no longer my project, that's
> fine with me.
>
> Jon
>
>
> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
>
>
> 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č 
> 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". Pe

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

[Josh McKenzie]

> IIUC there's no subproject involved here.
To elaborate a touch: this isn't a subproject in terms of governance. i.e. no 3 
dedicated PMC sponsors required, no "pmc must legally vote on releasing an 
artifact" (unless of course we start independently releasing artifacts for it 
as opposed to just pointing people at the repo and tags), and no real "we must 
have at least N people with a commit-bit and a focus on this area for it to be 
taken in".

Makes sense given the context and purpose of the tool and keeping it lighter 
weight should make it easier for everyone to collaborate on it, to Mick's point 
- much like the ccm and dtest repos.

On Tue, Oct 15, 2024, at 3:19 AM, Mick Semb Wever wrote:
> 
> IIUC there's no subproject involved here.  This is a separate repository 
> coming in, akin to cassandra-dtest (plus releases).
> 
> The question wrt replacing cassandra-stress was only thinking about something 
> down the road, to help smoke out stuff like compaction-stress.  No suggestion 
> implied that easy-cass-stress should be moved in-tree.
> 
> 
> 
> On Tue, 15 Oct 2024 at 00:15, David Capwell  wrote:
>>> I think we should just accept easy-cass-stress as a subproject and go
>>> from there.  Replacing stress can be handled separately and still has
>>> the large issue of reconciling the build systems that I raised in the
>>> beginning of this thread, but can be figured out eventually.
>> 
>> I strongly agree with you here. The proposal is to just add the project
>> 
>> 
>>> On Oct 14, 2024, at 11:08 AM, C. Scott Andreas  wrote:
>>> 
>>> Separating the two is completely fine yep -- just mentioned since 
>>> deprecation/removal of stress also came up in the thread.
>>> 
>>> Let's complete the donation. Just wanted to make sure we don't remove 
>>> compaction-stress without a substitute.
>>> 
>>> – Scott
>>> 
 On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote:
 
 
 I think we should just accept easy-cass-stress as a subproject and go
 from there. Replacing stress can be handled separately and still has
 the large issue of reconciling the build systems that I raised in the
 beginning of this thread, but can be figured out eventually.
 
 Kind Regards,
 Brandon
 
 On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  
 wrote:
> 
> Scott, I think introducing replacing compaction stress as a requirement 
> here adds unnecessary friction to the donation process. I'd prefer to 
> avoid coupling the two things. Unless you or someone else is volunteering 
> to rewrite it I think this would effectively halt the donation, which I 
> doubt is your intention. Can we do that as a separate thing?
> 
> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*, 
> and renaming it would make it clear that it's no longer my project, 
> that's fine with me.
> 
> Jon
> 
> 
> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
>> 
>> 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č 
>>  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 ... wh

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

[Mick Semb Wever]

IIUC there's no subproject involved here.  This is a separate repository
coming in, akin to cassandra-dtest (plus releases).

The question wrt replacing cassandra-stress was only thinking about
something down the road, to help smoke out stuff like compaction-stress.
No suggestion implied that easy-cass-stress should be moved in-tree.



On Tue, 15 Oct 2024 at 00:15, David Capwell  wrote:

> I think we should just accept easy-cass-stress as a subproject and go
> from there.  Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.
>
>
> I strongly agree with you here. The proposal is to just add the project
>
>
> On Oct 14, 2024, at 11:08 AM, C. Scott Andreas 
> wrote:
>
> Separating the two is completely fine yep -- just mentioned since
> deprecation/removal of stress also came up in the thread.
>
> Let's complete the donation. Just wanted to make sure we don't remove
> compaction-stress without a substitute.
>
> – Scott
>
> On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote:
>
>
> I think we should just accept easy-cass-stress as a subproject and go
> from there. Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.
>
> Kind Regards,
> Brandon
>
> On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad 
> wrote:
>
>
> Scott, I think introducing replacing compaction stress as a requirement
> here adds unnecessary friction to the donation process. I'd prefer to avoid
> coupling the two things. Unless you or someone else is volunteering to
> rewrite it I think this would effectively halt the donation, which I doubt
> is your intention. Can we do that as a separate thing?
>
> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*,
> and renaming it would make it clear that it's no longer my project, that's
> fine with me.
>
> Jon
>
>
> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
>
>
> 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č 
> 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  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 
> 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

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

[David Capwell]

> I think we should just accept easy-cass-stress as a subproject and go
> from there.  Replacing stress can be handled separately and still has
> the large issue of reconciling the build systems that I raised in the
> beginning of this thread, but can be figured out eventually.

I strongly agree with you here. The proposal is to just add the project


> On Oct 14, 2024, at 11:08 AM, C. Scott Andreas  wrote:
> 
> Separating the two is completely fine yep -- just mentioned since 
> deprecation/removal of stress also came up in the thread.
> 
> Let's complete the donation. Just wanted to make sure we don't remove 
> compaction-stress without a substitute.
> 
> – Scott
> 
>> On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote:
>> 
>> 
>> I think we should just accept easy-cass-stress as a subproject and go
>> from there. Replacing stress can be handled separately and still has
>> the large issue of reconciling the build systems that I raised in the
>> beginning of this thread, but can be figured out eventually.
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  wrote:
>>> 
>>> Scott, I think introducing replacing compaction stress as a requirement 
>>> here adds unnecessary friction to the donation process. I'd prefer to avoid 
>>> coupling the two things. Unless you or someone else is volunteering to 
>>> rewrite it I think this would effectively halt the donation, which I doubt 
>>> is your intention. Can we do that as a separate thing?
>>> 
>>> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*, 
>>> and renaming it would make it clear that it's no longer my project, that's 
>>> fine with me.
>>> 
>>> Jon
>>> 
>>> 
>>> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
 
 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č  
 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  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  
>> 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 fo

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

[C. Scott Andreas]

Separating the two is completely fine yep -- just mentioned since deprecation/removal of stress also came up in the thread. Let's complete the donation. Just wanted to make sure we 
don't remove compaction-stress without a substitute. – Scott On Oct 14, 2024, at 10:46 AM, Brandon Williams  wrote: I think we should just accept 
easy-cass-stress as a subproject and go from there. Replacing stress can be handled separately and still has the large issue of reconciling the build systems that I raised in the 
beginning of this thread, but can be figured out eventually. Kind Regards, Brandon On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  wrote: Scott, I think 
introducing replacing compaction stress as a requirement here adds unnecessary friction to the donation process. I'd prefer to avoid coupling the two things. Unless you or someone 
else is volunteering to rewrite it I think this would effectively halt the donation, which I doubt is your intention. Can we do that as a separate thing? Regarding the name, I'm 
fine if we rename it. My tooling is easy-cass-*, and renaming it would make it clear that it's no longer my project, that's fine with me. Jon On Sun, Oct 13, 2024 at 8:20 PM 
 wrote: 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č  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  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 
 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 encouraged the questions above) 2. IP Donation. Start filling out the IP Donation¹ form². Part of this process is t

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

[Brandon Williams]

I think we should just accept easy-cass-stress as a subproject and go
from there.  Replacing stress can be handled separately and still has
the large issue of reconciling the build systems that I raised in the
beginning of this thread, but can be figured out eventually.

Kind Regards,
Brandon

On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad  wrote:
>
> Scott, I think introducing replacing compaction stress as a requirement here 
> adds unnecessary friction to the donation process.  I'd prefer to avoid 
> coupling the two things.  Unless you or someone else is volunteering to 
> rewrite it I think this would effectively halt the donation, which I doubt is 
> your intention.  Can we do that as a separate thing?
>
> Regarding the name, I'm fine if we rename it.  My tooling is easy-cass-*, and 
> renaming it would make it clear that it's no longer my project, that's fine 
> with me.
>
> Jon
>
>
> On Sun, Oct 13, 2024 at 8:20 PM  wrote:
>>
>> 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č  
>> 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  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  
 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 c

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

[Jon Haddad]

Scott, I think introducing replacing compaction stress as a requirement
here adds unnecessary friction to the donation process.  I'd prefer to
avoid coupling the two things.  Unless you or someone else is volunteering
to rewrite it I think this would effectively halt the donation, which I
doubt is your intention.  Can we do that as a separate thing?

Regarding the name, I'm fine if we rename it.  My tooling is easy-cass-*,
and renaming it would make it clear that it's no longer my project, that's
fine with me.

Jon


On Sun, Oct 13, 2024 at 8:20 PM  wrote:

> 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č 
> 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  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 
>>> 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
 encouraged the questions above)


 2. IP Donation.  Start filling out the IP Donation¹ form².

 Part of this process is to get approval to donate and an ICLA from each
 individual past contributor.  In addition any company involved in past
 works must consent through either an SGA or their CCLA.  In this case, all
 work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was 

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č  > 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 > > 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 >> > 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 
> encouraged the questions above)
> 
> 
> 2. IP Donation.  Start filling out the IP Donation¹ form².  
> 
> Part of this process is to get approval to donate and an ICLA from each 
> individual past contributor.  In addition any company involved in past 
> works must consent through either an SGA or their CCLA.  In this case, 
> all work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was 
> copyrighted³ to The Last Pickle which is now owned by DataStax. Given 
> that copyright was over an entire body of work I would say that the SGA⁴ 
> is appropriate.   (I'm happy to handle this.)   We only need approval and 
> ICLA's from contributors after⁵ that SHA, as the previous copyright to 
> The Last Pickle applied to all past contributions. 
> 
> 
> 3. When the form, and all its steps are c

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

[Štefan Miklošovič]

* easy-cass-stress, sorry. Everything else holds.

On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič 
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  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 
>> 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
>>> encouraged the questions above)
>>>
>>>
>>> 2. IP Donation.  Start filling out the IP Donation¹ form².
>>>
>>> Part of this process is to get approval to donate and an ICLA from each
>>> individual past contributor.  In addition any company involved in past
>>> works must consent through either an SGA or their CCLA.  In this case, all
>>> work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was copyrighted
>>> ³ to The Last Pickle which is now owned by DataStax. Given that
>>> copyright was over an entire body of work I would say that the SGA⁴ is
>>> appropriate.   (I'm happy to handle this.)   We only need approval and
>>> ICLA's from contributors after⁵ that SHA, as the previous copyright to
>>> The Last Pickle applied to all past contributions.
>>>
>>>
>>> 3. When the form, and all its steps are complete, raise a vote on
>>> dev@cassandra.a.o and general@incubator.a.o
>>>
>>>
>>> 4. When the vote passes, request ASF Infra (create INFRA jira ticket) to
>>> move the repository to github.com/apache/cassandra-stress  (or
>>> whatever, but keep the cassandra- prefix IMO).
>>>
>>> --
>>>
>>> ¹)  https://incubator.apache.org/ip-clearance/ip-clearance-template.html
>>>
>>> ²)
>>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-java-driver.xml
>>>
>>>
>>> ³)
>>> https://github.com/thelastpickle/tlp-stress/blob/master/LICENSE.txt#L1
>>>
>>> ⁴)  https://www.apache.org/licenses/contributor-agreements.html
>>>
>>> ⁵)
>>> https://github.com/rustyrazorblade/easy-cass-stress/compare/2d4542c27d3f1c0e24899c01247b9a8ee3c9a238...main
>>>
>>>
>>>
>>>
>>>
>>>
>>>

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

[Štefan Miklošovič]

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  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 
> 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
>> encouraged the questions above)
>>
>>
>> 2. IP Donation.  Start filling out the IP Donation¹ form².
>>
>> Part of this process is to get approval to donate and an ICLA from each
>> individual past contributor.  In addition any company involved in past
>> works must consent through either an SGA or their CCLA.  In this case, all
>> work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was copyrighted³ to
>> The Last Pickle which is now owned by DataStax. Given that copyright was
>> over an entire body of work I would say that the SGA⁴ is appropriate.   (I'm
>> happy to handle this.)   We only need approval and ICLA's from
>> contributors after⁵ that SHA, as the previous copyright to The Last
>> Pickle applied to all past contributions.
>>
>>
>> 3. When the form, and all its steps are complete, raise a vote on
>> dev@cassandra.a.o and general@incubator.a.o
>>
>>
>> 4. When the vote passes, request ASF Infra (create INFRA jira ticket) to
>> move the repository to github.com/apache/cassandra-stress  (or whatever,
>> but keep the cassandra- prefix IMO).
>>
>> --
>>
>> ¹)  https://incubator.apache.org/ip-clearance/ip-clearance-template.html
>>
>> ²)
>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-java-driver.xml
>>
>>
>> ³)
>> https://github.com/thelastpickle/tlp-stress/blob/master/LICENSE.txt#L1
>>
>> ⁴)  https://www.apache.org/licenses/contributor-agreements.html
>>
>> ⁵)
>> https://github.com/rustyrazorblade/easy-cass-stress/compare/2d4542c27d3f1c0e24899c01247b9a8ee3c9a238...main
>>
>>
>>
>>
>>
>>
>>

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

[Brad]

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  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
> encouraged the questions above)
>
>
> 2. IP Donation.  Start filling out the IP Donation¹ form².
>
> Part of this process is to get approval to donate and an ICLA from each
> individual past contributor.  In addition any company involved in past
> works must consent through either an SGA or their CCLA.  In this case, all
> work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was copyrighted³ to
> The Last Pickle which is now owned by DataStax. Given that copyright was
> over an entire body of work I would say that the SGA⁴ is appropriate.   (I'm
> happy to handle this.)   We only need approval and ICLA's from
> contributors after⁵ that SHA, as the previous copyright to The Last
> Pickle applied to all past contributions.
>
>
> 3. When the form, and all its steps are complete, raise a vote on
> dev@cassandra.a.o and general@incubator.a.o
>
>
> 4. When the vote passes, request ASF Infra (create INFRA jira ticket) to
> move the repository to github.com/apache/cassandra-stress  (or whatever,
> but keep the cassandra- prefix IMO).
>
> --
>
> ¹)  https://incubator.apache.org/ip-clearance/ip-clearance-template.html
>
> ²)
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-java-driver.xml
>
>
> ³)  https://github.com/thelastpickle/tlp-stress/blob/master/LICENSE.txt#L1
>
>
> ⁴)  https://www.apache.org/licenses/contributor-agreements.html
>
> ⁵)
> https://github.com/rustyrazorblade/easy-cass-stress/compare/2d4542c27d3f1c0e24899c01247b9a8ee3c9a238...main
>
>
>
>
>
>
>

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

[Josh McKenzie]

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 
> encouraged the questions above)
> 
> 
> 2. IP Donation.  Start filling out the IP Donation¹ form².  
> 
> Part of this process is to get approval to donate and an ICLA from each 
> individual past contributor.  In addition any company involved in past works 
> must consent through either an SGA or their CCLA.  In this case, all work 
> before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was copyrighted³ to The 
> Last Pickle which is now owned by DataStax. Given that copyright was over an 
> entire body of work I would say that the SGA⁴ is appropriate.   (I'm happy to 
> handle this.)   We only need approval and ICLA's from contributors after⁵ 
> that SHA, as the previous copyright to The Last Pickle applied to all past 
> contributions. 
> 
> 
> 3. When the form, and all its steps are complete, raise a vote on 
> dev@cassandra.a.o and general@incubator.a.o
> 
> 
> 4. When the vote passes, request ASF Infra (create INFRA jira ticket) to move 
> the repository to github.com/apache/cassandra-stress  (or whatever, but keep 
> the cassandra- prefix IMO).
> 
> --
> ¹)  https://incubator.apache.org/ip-clearance/ip-clearance-template.html
> 
> ²)  
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-java-driver.xml
>  
> 
> ³)  https://github.com/thelastpickle/tlp-stress/blob/master/LICENSE.txt#L1 
> 
> ⁴)  https://www.apache.org/licenses/contributor-agreements.html 
> 
> ⁵)  
> https://github.com/rustyrazorblade/easy-cass-stress/compare/2d4542c27d3f1c0e24899c01247b9a8ee3c9a238...main
>  
> 
> 
> 
> 
> 

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

[Mick Semb Wever]

 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
encouraged the questions above)


2. IP Donation.  Start filling out the IP Donation¹ form².

Part of this process is to get approval to donate and an ICLA from each
individual past contributor.  In addition any company involved in past
works must consent through either an SGA or their CCLA.  In this case, all
work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was copyrighted³ to
The Last Pickle which is now owned by DataStax. Given that copyright was
over an entire body of work I would say that the SGA⁴ is appropriate.   (I'm
happy to handle this.)   We only need approval and ICLA's from contributors
after⁵ that SHA, as the previous copyright to The Last Pickle applied to
all past contributions.


3. When the form, and all its steps are complete, raise a vote on
dev@cassandra.a.o and general@incubator.a.o


4. When the vote passes, request ASF Infra (create INFRA jira ticket) to
move the repository to github.com/apache/cassandra-stress  (or whatever,
but keep the cassandra- prefix IMO).

--

¹)  https://incubator.apache.org/ip-clearance/ip-clearance-template.html

²)
https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-java-driver.xml


³)  https://github.com/thelastpickle/tlp-stress/blob/master/LICENSE.txt#L1

⁴)  https://www.apache.org/licenses/contributor-agreements.html

⁵)
https://github.com/rustyrazorblade/easy-cass-stress/compare/2d4542c27d3f1c0e24899c01247b9a8ee3c9a238...main

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

[Soheil Rahsaz]

Hi

I would also love to contribute to this project

On Sat, Oct 12, 2024 at 3:34 AM Jordan West  wrote:

> 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 <
> adejanov...@gmail.com> 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 
>>> directl

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] Donating easy-cass-stress to the project

[Dave Herrington]

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 needle forward and make this conversation a bit
> easier/obvious.
>
>
>
>>>

--

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

[Jon Haddad]

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 needle forward and make this conversation a bit
 easier/obvious.



>>

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

[Jordan West]

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 needle forward and make this conversation a bit
>>> easier/obvious.
>>>
>>>
>>>
>

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

[Doug Rohrer]

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 needle forward and make this conversation a bit 
> easier/obvious.
> 
 

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

[Bernardo Botella]

Just found out about this thread.

I do agree, after seeing Jon and Jordan’s talk on this tool, it would be great 
to have it under the project umbrella. Like Alexander, I have also some ideas 
on workflows to contribute, and would love to help maintain it.

Bernardo

> 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 needle forward and make this conversation a bit 
> easier/obvious.
> 
 

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

[Doug Rohrer]

Hey folks,

I just wanted to resurface this conversation, especially after Jon and Jordon’s 
awesome talk/“live demo" 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 (please correct me if I’m wrong on any point here):

- 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/committers (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:14 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 needle forward and make this conversation a bit 
 easier/obvious.
 
>>> 

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

[Doug Rohrer]

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 RohrerOn 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 wellJordan 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 needle forward and make this conversation a bit easier/obvious.

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

[Alexander DEJANOVSKI]

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 needle forward and make this conversation a bit
>> easier/obvious.
>>
>>
>>

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

[Jordan West]

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 needle forward and make this conversation a bit
> easier/obvious.
>
>
>

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

[David Capwell]

> 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 needle forward and make this conversation a bit easier/obvious.
> 

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

[Mick Semb Wever]

>
> 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 needle forward and make this conversation a bit
easier/obvious.

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

[Brad]

The current cassandra-stress is in poor condition and clocks in at a hefty
16k lines of Java code.  I was involved in some work with it last Summer
(CASSANDRA-18529) and it was tricky.

I'm strongly in favor of replacing it with a modern tool which is easier to
configure and more user friendly.  While it's a valid concern to ask who
might help maintain it, the same could be asked about the
existing cassandra-stress which has not been well maintained recently.

A separate subproject like dtest and the Java driver would maybe help
address concerns with introducing a gradle build system and Kotlin.



On Fri, Apr 26, 2024 at 2:30 PM Jon Haddad  wrote:

> @mck I haven't done anything with IP clearance.  Not sure how to, and I
> want to get a feel for if we even want it in the project before I invest
> time in.  Jeff's question about people willing to maintain the project is a
> good one and if people aren't willing to maintain it with me, it's only
> going to make my life harder to move under the project umbrella.  I don't
> want to go from my wild west style of committing whatever I want to waiting
> around for days or weeks to get features committed.
>
>
> Project rename happened here:
>
> commit 6c9493254f7bed57f19aaf5bda19f0b7734b5333
> Author: Jon Haddad 
> Date:   Wed Feb 14 13:21:36 2024 -0800
>
> Renamed the project
>
>
>
>
>
> On Fri, Apr 26, 2024 at 12:50 AM Mick Semb Wever  wrote:
>
>>
>>
>> On Fri, 26 Apr 2024 at 00:11, Jon Haddad  wrote:
>>
>>> I should probably have noted - since TLP is no more, I renamed
>>> tlp-stress to easy-cass-stress around half a year ago when I took it over
>>> again.
>>>
>>
>>
>> Do we have the IP cleared for donation ?
>> At what SHA did you take and rename tlp-stress, and who was the copyright
>> holder til that point ?
>> We can fix this I'm sure, but we will need the paperwork.
>>
>>
>>

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

[Jon Haddad]

@mck I haven't done anything with IP clearance.  Not sure how to, and I
want to get a feel for if we even want it in the project before I invest
time in.  Jeff's question about people willing to maintain the project is a
good one and if people aren't willing to maintain it with me, it's only
going to make my life harder to move under the project umbrella.  I don't
want to go from my wild west style of committing whatever I want to waiting
around for days or weeks to get features committed.


Project rename happened here:

commit 6c9493254f7bed57f19aaf5bda19f0b7734b5333
Author: Jon Haddad 
Date:   Wed Feb 14 13:21:36 2024 -0800

Renamed the project





On Fri, Apr 26, 2024 at 12:50 AM Mick Semb Wever  wrote:

>
>
> On Fri, 26 Apr 2024 at 00:11, Jon Haddad  wrote:
>
>> I should probably have noted - since TLP is no more, I renamed tlp-stress
>> to easy-cass-stress around half a year ago when I took it over again.
>>
>
>
> Do we have the IP cleared for donation ?
> At what SHA did you take and rename tlp-stress, and who was the copyright
> holder til that point ?
> We can fix this I'm sure, but we will need the paperwork.
>
>
>

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

[Mick Semb Wever]

On Fri, 26 Apr 2024 at 00:11, Jon Haddad  wrote:

> I should probably have noted - since TLP is no more, I renamed tlp-stress
> to easy-cass-stress around half a year ago when I took it over again.
>


Do we have the IP cleared for donation ?
At what SHA did you take and rename tlp-stress, and who was the copyright
holder til that point ?
We can fix this I'm sure, but we will need the paperwork.

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

[Caleb Rackliffe]

I do have some familiarity w/ the codebase, and I could help support it in a minor capacity. (Reviews, small fixes, etc.) Probably not something I could spend hours on every week.On Apr 25, 2024, at 5:11 PM, Jon Haddad  wrote:I should probably have noted - since TLP is no more, I renamed tlp-stress to easy-cass-stress around half a year ago when I took it over again.JonOn Thu, Apr 25, 2024 at 3:05 PM Jeff Jirsa  wrote:Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going forward? On Apr 25, 2024, at 5:55 PM, Jon Haddad  wrote:Yeah, I agree with your concerns.  I very firmly prefer a separate subproject.  I've got zero interest in moving from a modern Gradle project to an ant based one.  It would be a lot of work for not much benefit.If we wanted to replace cassandra-stress, I'd say bring in the release artifact as part of the build process instead of tying it all together, but I'm OK if we keep it separate as well.JonOn Thu, Apr 25, 2024 at 2:43 PM Brandon Williams  wrote:I want to begin by saying I am generally +1 on this because I have
become a fan of easy-cass-stress after using it, but I am curious if
this is intended to be a subproject, or replace cassandra-stress?  If
the latter, we are going to have to reconcile the build systems
somehow.  I don't really want to drag ECS back to ant, but I also
don't want two different build systems in-tree.

Kind Regards,
Brandon

On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
>
> I've been asked by quite a few people, both in person and in JIRA [1] about contributing easy-cass-stress [2] to the project.  I've been happy to maintain the project myself over the years but given its widespread use I think it makes sense to make it more widely available and under the project's umbrella.
>
> My goal with the project was always to provide something that's easy to use.  Up and running in a couple minutes, using the parameters to shape the workload rather than defining everything through configuration.  I was happy to make this tradeoff since Cassandra doesn't have very many types of queries and it's worked well for me over the years.
>
> Obviously I would continue working on this project, and I hope this would encourage others to contribute.  I've heard a lot of good ideas that other teams have implemented in their folks.  I'd love to see those ideas make it into the project, and it sounds like it would be a lot easier for teams to get approval to contribute if it was under the project umbrella.
>
> Would love to hear your thoughts.
>
> Thanks,
> Jon
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
> [2] https://github.com/rustyrazorblade/easy-cass-stress

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

[Jon Haddad]

I should probably have noted - since TLP is no more, I renamed tlp-stress
to easy-cass-stress around half a year ago when I took it over again.

Jon

On Thu, Apr 25, 2024 at 3:05 PM Jeff Jirsa  wrote:

> Unless there’s 2-3 other people who expect to keep working on it, I don’t
> see how we justify creating a subproject
>
> And if there’s not 2-3 people expressing interest, even pulling it into
> the main project seems risky
>
> So: besides Jon, who in the community expects/desires to maintain this
> going forward?
>
> On Apr 25, 2024, at 5:55 PM, Jon Haddad  wrote:
>
> 
> Yeah, I agree with your concerns.  I very firmly prefer a separate
> subproject.  I've got zero interest in moving from a modern Gradle project
> to an ant based one.  It would be a lot of work for not much benefit.
>
> If we wanted to replace cassandra-stress, I'd say bring in the release
> artifact as part of the build process instead of tying it all together, but
> I'm OK if we keep it separate as well.
>
> Jon
>
>
>
>
> On Thu, Apr 25, 2024 at 2:43 PM Brandon Williams  wrote:
>
>> I want to begin by saying I am generally +1 on this because I have
>> become a fan of easy-cass-stress after using it, but I am curious if
>> this is intended to be a subproject, or replace cassandra-stress?  If
>> the latter, we are going to have to reconcile the build systems
>> somehow.  I don't really want to drag ECS back to ant, but I also
>> don't want two different build systems in-tree.
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
>> >
>> > I've been asked by quite a few people, both in person and in JIRA [1]
>> about contributing easy-cass-stress [2] to the project.  I've been happy to
>> maintain the project myself over the years but given its widespread use I
>> think it makes sense to make it more widely available and under the
>> project's umbrella.
>> >
>> > My goal with the project was always to provide something that's easy to
>> use.  Up and running in a couple minutes, using the parameters to shape the
>> workload rather than defining everything through configuration.  I was
>> happy to make this tradeoff since Cassandra doesn't have very many types of
>> queries and it's worked well for me over the years.
>> >
>> > Obviously I would continue working on this project, and I hope this
>> would encourage others to contribute.  I've heard a lot of good ideas that
>> other teams have implemented in their folks.  I'd love to see those ideas
>> make it into the project, and it sounds like it would be a lot easier for
>> teams to get approval to contribute if it was under the project umbrella.
>> >
>> > Would love to hear your thoughts.
>> >
>> > Thanks,
>> > Jon
>> >
>> > [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
>> > [2] https://github.com/rustyrazorblade/easy-cass-stress
>>
>

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

[Jeff Jirsa]

Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going forward? On Apr 25, 2024, at 5:55 PM, Jon Haddad  wrote:Yeah, I agree with your concerns.  I very firmly prefer a separate subproject.  I've got zero interest in moving from a modern Gradle project to an ant based one.  It would be a lot of work for not much benefit.If we wanted to replace cassandra-stress, I'd say bring in the release artifact as part of the build process instead of tying it all together, but I'm OK if we keep it separate as well.JonOn Thu, Apr 25, 2024 at 2:43 PM Brandon Williams  wrote:I want to begin by saying I am generally +1 on this because I have
become a fan of easy-cass-stress after using it, but I am curious if
this is intended to be a subproject, or replace cassandra-stress?  If
the latter, we are going to have to reconcile the build systems
somehow.  I don't really want to drag ECS back to ant, but I also
don't want two different build systems in-tree.

Kind Regards,
Brandon

On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
>
> I've been asked by quite a few people, both in person and in JIRA [1] about contributing easy-cass-stress [2] to the project.  I've been happy to maintain the project myself over the years but given its widespread use I think it makes sense to make it more widely available and under the project's umbrella.
>
> My goal with the project was always to provide something that's easy to use.  Up and running in a couple minutes, using the parameters to shape the workload rather than defining everything through configuration.  I was happy to make this tradeoff since Cassandra doesn't have very many types of queries and it's worked well for me over the years.
>
> Obviously I would continue working on this project, and I hope this would encourage others to contribute.  I've heard a lot of good ideas that other teams have implemented in their folks.  I'd love to see those ideas make it into the project, and it sounds like it would be a lot easier for teams to get approval to contribute if it was under the project umbrella.
>
> Would love to hear your thoughts.
>
> Thanks,
> Jon
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
> [2] https://github.com/rustyrazorblade/easy-cass-stress

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

[Dinesh Joshi]

I am not familiar with ECS but if we’re going to go for it I would prefer
it to be a sub project really. Jon, what do you think?

On Thu, Apr 25, 2024 at 2:44 PM Brandon Williams  wrote:

> I want to begin by saying I am generally +1 on this because I have
> become a fan of easy-cass-stress after using it, but I am curious if
> this is intended to be a subproject, or replace cassandra-stress?  If
> the latter, we are going to have to reconcile the build systems
> somehow.  I don't really want to drag ECS back to ant, but I also
> don't want two different build systems in-tree.
>
> Kind Regards,
> Brandon
>
> On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
> >
> > I've been asked by quite a few people, both in person and in JIRA [1]
> about contributing easy-cass-stress [2] to the project.  I've been happy to
> maintain the project myself over the years but given its widespread use I
> think it makes sense to make it more widely available and under the
> project's umbrella.
> >
> > My goal with the project was always to provide something that's easy to
> use.  Up and running in a couple minutes, using the parameters to shape the
> workload rather than defining everything through configuration.  I was
> happy to make this tradeoff since Cassandra doesn't have very many types of
> queries and it's worked well for me over the years.
> >
> > Obviously I would continue working on this project, and I hope this
> would encourage others to contribute.  I've heard a lot of good ideas that
> other teams have implemented in their folks.  I'd love to see those ideas
> make it into the project, and it sounds like it would be a lot easier for
> teams to get approval to contribute if it was under the project umbrella.
> >
> > Would love to hear your thoughts.
> >
> > Thanks,
> > Jon
> >
> > [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
> > [2] https://github.com/rustyrazorblade/easy-cass-stress
>

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

[Jon Haddad]

Yeah, I agree with your concerns.  I very firmly prefer a separate
subproject.  I've got zero interest in moving from a modern Gradle project
to an ant based one.  It would be a lot of work for not much benefit.

If we wanted to replace cassandra-stress, I'd say bring in the release
artifact as part of the build process instead of tying it all together, but
I'm OK if we keep it separate as well.

Jon




On Thu, Apr 25, 2024 at 2:43 PM Brandon Williams  wrote:

> I want to begin by saying I am generally +1 on this because I have
> become a fan of easy-cass-stress after using it, but I am curious if
> this is intended to be a subproject, or replace cassandra-stress?  If
> the latter, we are going to have to reconcile the build systems
> somehow.  I don't really want to drag ECS back to ant, but I also
> don't want two different build systems in-tree.
>
> Kind Regards,
> Brandon
>
> On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
> >
> > I've been asked by quite a few people, both in person and in JIRA [1]
> about contributing easy-cass-stress [2] to the project.  I've been happy to
> maintain the project myself over the years but given its widespread use I
> think it makes sense to make it more widely available and under the
> project's umbrella.
> >
> > My goal with the project was always to provide something that's easy to
> use.  Up and running in a couple minutes, using the parameters to shape the
> workload rather than defining everything through configuration.  I was
> happy to make this tradeoff since Cassandra doesn't have very many types of
> queries and it's worked well for me over the years.
> >
> > Obviously I would continue working on this project, and I hope this
> would encourage others to contribute.  I've heard a lot of good ideas that
> other teams have implemented in their folks.  I'd love to see those ideas
> make it into the project, and it sounds like it would be a lot easier for
> teams to get approval to contribute if it was under the project umbrella.
> >
> > Would love to hear your thoughts.
> >
> > Thanks,
> > Jon
> >
> > [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
> > [2] https://github.com/rustyrazorblade/easy-cass-stress
>

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

[Brandon Williams]

I want to begin by saying I am generally +1 on this because I have
become a fan of easy-cass-stress after using it, but I am curious if
this is intended to be a subproject, or replace cassandra-stress?  If
the latter, we are going to have to reconcile the build systems
somehow.  I don't really want to drag ECS back to ant, but I also
don't want two different build systems in-tree.

Kind Regards,
Brandon

On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
>
> I've been asked by quite a few people, both in person and in JIRA [1] about 
> contributing easy-cass-stress [2] to the project.  I've been happy to 
> maintain the project myself over the years but given its widespread use I 
> think it makes sense to make it more widely available and under the project's 
> umbrella.
>
> My goal with the project was always to provide something that's easy to use.  
> Up and running in a couple minutes, using the parameters to shape the 
> workload rather than defining everything through configuration.  I was happy 
> to make this tradeoff since Cassandra doesn't have very many types of queries 
> and it's worked well for me over the years.
>
> Obviously I would continue working on this project, and I hope this would 
> encourage others to contribute.  I've heard a lot of good ideas that other 
> teams have implemented in their folks.  I'd love to see those ideas make it 
> into the project, and it sounds like it would be a lot easier for teams to 
> get approval to contribute if it was under the project umbrella.
>
> Would love to hear your thoughts.
>
> Thanks,
> Jon
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
> [2] https://github.com/rustyrazorblade/easy-cass-stress