You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Doug Rohrer <dr...@apple.com> on 2024/10/08 19:51:26 UTC
Re: [DISCUSS] Donating easy-cass-stress to the project
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 <ad...@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
> <[jwest@apache.org](mailto:jwest@apache.org)> a écrit :
>
>
>> I would likely commit to it as well
>>
>>
>
>>
>> Jordan
>>
>>
>
>>
>> On Mon, Apr 29, 2024 at 10:55 David Capwell
<[dcapwell@apple.com](mailto:dcapwell@apple.com)> 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
<[mck@apache.org](mailto:mck@apache.org)> 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
Posted by Bernardo Botella <co...@bernardobotella.com>.
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 <dr...@apple.com> 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 <ad...@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 <jwest@apache.org <ma...@apache.org>> a écrit :
>>> I would likely commit to it as well
>>>
>>> Jordan
>>>
>>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dcapwell@apple.com <ma...@apple.com>> 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 <mck@apache.org <ma...@apache.org>> 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
Posted by Soheil Rahsaz <so...@gmail.com>.
Hi
I would also love to contribute to this project
On Sat, Oct 12, 2024 at 3:34 AM Jordan West <jw...@apache.org> 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 <he...@rhinosource.com>
> 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 <jo...@rustyrazorblade.com>
>> 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 <jw...@apache.org> 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 <dr...@apple.com> 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 <dr...@apple.com> 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 <
>>>>> adejanovski@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 <jw...@apache.org> a écrit :
>>>>>
>>>>>> I would likely commit to it as well
>>>>>>
>>>>>> Jordan
>>>>>>
>>>>>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dc...@apple.com>
>>>>>> 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 <mc...@apache.org> 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
Posted by Mick Semb Wever <mc...@apache.org>.
On Wed, 23 Oct 2024 at 05:48, Jordan West <jo...@gmail.com> 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
Posted by Jordan West <jo...@gmail.com>.
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 <jm...@apache.org> 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 <dc...@apple.com> 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 <sc...@paradoxica.net>
> 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 <dr...@gmail.com> 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 <jo...@rustyrazorblade.com>
> 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 <sc...@paradoxica.net> 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č <sm...@apache.org>
> wrote:
>
> * easy-cass-stress, sorry. Everything else holds.
>
> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org>
> wrote:
>
>
> What does "replacing" actually mean? If this tool is added to a separate
> repository, you mean like it would be put there under the "easy-cass-lab"
> name and all source code of cassandra-stress in the Cassandra repository
> would be removed? Are we going to deprecate what we have first or it is
> going to be a big bang?
>
> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think
> that "easy-cass-lab" should be the name of a repo we are going to use. For
> a custom tool living outside of Cassandra until now, sure, but the official
> stress tool should not be called "easy-cass-lab". People would be like ...
> what? IMHO we should rename it to cassandra-stress.
>
> On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote:
>
>
> I'm +1 on replacing the existing cassandra-stress. My team did some work
> last Summer to remove Thrift related CLI args, but arg parsing alone is a
> 5K line mess. It's certainly not being well-maintained and could use a
> replacement.
>
> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org>
> wrote:
>
>
> Unsolicited .02:
>
> - If this will eventually replace the in-tree cassandra-stress, does it
> warrant a CEP ? (i'm ok with skipping, though that step might have
> encouraged the questions above)
>
> I'm +1 to this replacing, -0 on requiring a CEP.
>
> Given the current tool is unmaintained and doesn't (to my knowledge) have
> a workflow-based usage paradigm that could be easily extended, seems like a
> clear win.
>
>
> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>
> reply below.
>
>
> I’m terms of next steps: Mick what do we need to do next? Figure out the
> answers to your questions re: getting contributor sign off?
>
>
>
> The process of donation is as follows… (feel free to correct me, or add
> anything)
>
>
> 1. General pre-agreement from the PMC that we'll take this project in, and
> how it will fit in.
>
> Some questions I (personally) have are,
> - Is the PMC ok with accepting a kotlin repository into the main part of
> the project ? (I assume so, kotlin == java, just asking the question. this
> was asked before, maybe i missed any response)
> - Who are the initial three PMC members that are volunteering to be active
> ? (Jon, Jordan, and ?)
> - How will the activity in this repository maintain visibility to the rest
> of the project ? (see recent discussions wrt sidecar's activity silo-ing)
> - Is the repo intending to adopt general project practices ? (e.g. release
> formalities, "patch by ; reviewed by for " commit messages, etc etc etc. if
> not, what is planned…)
> - If this will eventually replace the in-tree cassandra-stress, does it
> warrant a CEP ? (i'm ok with skipping, though that step might have
> 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
Posted by Josh McKenzie <jm...@apache.org>.
> 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 <dc...@apple.com> 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 <sc...@paradoxica.net> 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 <dr...@gmail.com> 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 <jo...@rustyrazorblade.com> 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 <sc...@paradoxica.net> 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č <sm...@apache.org> wrote:
>>>>>>
>>>>>> * easy-cass-stress, sorry. Everything else holds.
>>>>>>
>>>>>> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org> wrote:
>>>>>>>
>>>>>>> What does "replacing" actually mean? If this tool is added to a separate repository, you mean like it would be put there under the "easy-cass-lab" name and all source code of cassandra-stress in the Cassandra repository would be removed? Are we going to deprecate what we have first or it is going to be a big bang?
>>>>>>>
>>>>>>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think that "easy-cass-lab" should be the name of a repo we are going to use. For a custom tool living outside of Cassandra until now, sure, but the official stress tool should not be called "easy-cass-lab". People would be like ... what? IMHO we should rename it to cassandra-stress.
>>>>>>>
>>>>>>> On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I'm +1 on replacing the existing cassandra-stress. My team did some work last Summer to remove Thrift related CLI args, but arg parsing alone is a 5K line mess. It's certainly not being well-maintained and could use a replacement.
>>>>>>>>
>>>>>>>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> Unsolicited .02:
>>>>>>>>>
>>>>>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have encouraged the questions above)
>>>>>>>>>
>>>>>>>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>>>>>>>>
>>>>>>>>> Given the current tool is unmaintained and doesn't (to my knowledge) have a workflow-based usage paradigm that could be easily extended, seems like a clear win.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>>>>>>>>
>>>>>>>>> reply below.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I’m terms of next steps: Mick what do we need to do next? Figure out the answers to your questions re: getting contributor sign off?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The process of donation is as follows… (feel free to correct me, or add anything)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. General pre-agreement from the PMC that we'll take this project in, and how it will fit in.
>>>>>>>>>
>>>>>>>>> Some questions I (personally) have are,
>>>>>>>>> - Is the PMC ok with accepting a kotlin repository into the main part of the project ? (I assume so, kotlin == java, just asking the question. this was asked before, maybe i missed any response)
>>>>>>>>> - Who are the initial three PMC members that are volunteering to be active ? (Jon, Jordan, and ?)
>>>>>>>>> - How will the activity in this repository maintain visibility to the rest of the project ? (see recent discussions wrt sidecar's activity silo-ing)
>>>>>>>>> - Is the repo intending to adopt general project practices ? (e.g. release formalities, "patch by ; reviewed by for " commit messages, etc etc etc. if not, what is planned…)
>>>>>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have 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
Posted by Mick Semb Wever <mc...@apache.org>.
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 <dc...@apple.com> 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 <sc...@paradoxica.net>
> 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 <dr...@gmail.com> 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 <jo...@rustyrazorblade.com>
> 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 <sc...@paradoxica.net> 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č <sm...@apache.org>
> wrote:
>
> * easy-cass-stress, sorry. Everything else holds.
>
> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org>
> wrote:
>
>
> What does "replacing" actually mean? If this tool is added to a separate
> repository, you mean like it would be put there under the "easy-cass-lab"
> name and all source code of cassandra-stress in the Cassandra repository
> would be removed? Are we going to deprecate what we have first or it is
> going to be a big bang?
>
> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think
> that "easy-cass-lab" should be the name of a repo we are going to use. For
> a custom tool living outside of Cassandra until now, sure, but the official
> stress tool should not be called "easy-cass-lab". People would be like ...
> what? IMHO we should rename it to cassandra-stress.
>
> On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote:
>
>
> I'm +1 on replacing the existing cassandra-stress. My team did some work
> last Summer to remove Thrift related CLI args, but arg parsing alone is a
> 5K line mess. It's certainly not being well-maintained and could use a
> replacement.
>
> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org>
> wrote:
>
>
> Unsolicited .02:
>
> - If this will eventually replace the in-tree cassandra-stress, does it
> warrant a CEP ? (i'm ok with skipping, though that step might have
> encouraged the questions above)
>
> I'm +1 to this replacing, -0 on requiring a CEP.
>
> Given the current tool is unmaintained and doesn't (to my knowledge) have
> a workflow-based usage paradigm that could be easily extended, seems like a
> clear win.
>
>
> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>
> reply below.
>
>
> I’m terms of next steps: Mick what do we need to do next? Figure out the
> answers to your questions re: getting contributor sign off?
>
>
>
> The process of donation is as follows… (feel free to correct me, or add
> anything)
>
>
> 1. General pre-agreement from the PMC that we'll take this project in, and
> how it will fit in.
>
> Some questions I (personally) have are,
> - Is the PMC ok with accepting a kotlin repository into the main part of
> the project ? (I assume so, kotlin == java, just asking the question. this
> was asked before, maybe i missed any response)
> - Who are the initial three PMC members that are volunteering to be active
> ? (Jon, Jordan, and ?)
> - How will the activity in this repository maintain visibility to the rest
> of the project ? (see recent discussions wrt sidecar's activity silo-ing)
> - Is the repo intending to adopt general project practices ? (e.g. release
> formalities, "patch by ; reviewed by for " commit messages, etc etc etc. if
> not, what is planned…)
> - If this will eventually replace the in-tree cassandra-stress, does it
> warrant a CEP ? (i'm ok with skipping, though that step might have
> 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
Posted by David Capwell <dc...@apple.com>.
> 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 <sc...@paradoxica.net> 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 <dr...@gmail.com> 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 <jo...@rustyrazorblade.com> 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 <sc...@paradoxica.net> 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č <sm...@apache.org> wrote:
>>>>
>>>> * easy-cass-stress, sorry. Everything else holds.
>>>>
>>>> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org> wrote:
>>>>>
>>>>> What does "replacing" actually mean? If this tool is added to a separate repository, you mean like it would be put there under the "easy-cass-lab" name and all source code of cassandra-stress in the Cassandra repository would be removed? Are we going to deprecate what we have first or it is going to be a big bang?
>>>>>
>>>>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think that "easy-cass-lab" should be the name of a repo we are going to use. For a custom tool living outside of Cassandra until now, sure, but the official stress tool should not be called "easy-cass-lab". People would be like ... what? IMHO we should rename it to cassandra-stress.
>>>>>
>>>>> On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote:
>>>>>>
>>>>>> I'm +1 on replacing the existing cassandra-stress. My team did some work last Summer to remove Thrift related CLI args, but arg parsing alone is a 5K line mess. It's certainly not being well-maintained and could use a replacement.
>>>>>>
>>>>>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org> wrote:
>>>>>>>
>>>>>>> Unsolicited .02:
>>>>>>>
>>>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have encouraged the questions above)
>>>>>>>
>>>>>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>>>>>>
>>>>>>> Given the current tool is unmaintained and doesn't (to my knowledge) have a workflow-based usage paradigm that could be easily extended, seems like a clear win.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>>>>>>
>>>>>>> reply below.
>>>>>>>
>>>>>>>
>>>>>>> I’m terms of next steps: Mick what do we need to do next? Figure out the answers to your questions re: getting contributor sign off?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The process of donation is as follows… (feel free to correct me, or add anything)
>>>>>>>
>>>>>>>
>>>>>>> 1. General pre-agreement from the PMC that we'll take this project in, and how it will fit in.
>>>>>>>
>>>>>>> Some questions I (personally) have are,
>>>>>>> - Is the PMC ok with accepting a kotlin repository into the main part of the project ? (I assume so, kotlin == java, just asking the question. this was asked before, maybe i missed any response)
>>>>>>> - Who are the initial three PMC members that are volunteering to be active ? (Jon, Jordan, and ?)
>>>>>>> - How will the activity in this repository maintain visibility to the rest of the project ? (see recent discussions wrt sidecar's activity silo-ing)
>>>>>>> - Is the repo intending to adopt general project practices ? (e.g. release formalities, "patch by ; reviewed by for " commit messages, etc etc etc. if not, what is planned…)
>>>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have 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 <ma...@cassandra.a.o> and general@incubator.a.o <ma...@incubator.a.o>
>>>>>>>
>>>>>>>
>>>>>>> 4. When the vote passes, request ASF Infra (create INFRA jira ticket) to move the repository to github.com <http://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
Posted by "C. Scott Andreas" <sc...@paradoxica.net>.
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 <dr...@gmail.com> 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 <jo...@rustyrazorblade.com> 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 <sc...@paradoxica.net> 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č <sm...@apache.org> wrote: * easy-cass-stress, sorry. Everything else holds. On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org> wrote: What does "replacing" actually mean? If this tool is added to a separate repository, you mean like it would be put there under the "easy-cass-lab" name and all source code of cassandra-stress in the Cassandra repository would be removed? Are we going to deprecate what we have first or it is going to be a big bang? Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think that "easy-cass-lab" should be the name of a repo we are going to use. For a custom tool living outside of Cassandra until now, sure, but the official stress tool should not be called "easy-cass-lab". People would be like ... what? IMHO we should rename it to cassandra-stress. On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote: I'm +1 on replacing the existing cassandra-stress. My team did some work last Summer to remove Thrift related CLI args, but arg parsing alone is a 5K line mess. It's certainly not being well-maintained and could use a replacement. On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org> wrote: Unsolicited .02: - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have encouraged the questions above) I'm +1 to this replacing, -0 on requiring a CEP. Given the current tool is unmaintained and doesn't (to my knowledge) have a workflow-based usage paradigm that could be easily extended, seems like a clear win. On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote: reply below. I’m terms of next steps: Mick what do we need to do next? Figure out the answers to your questions re: getting contributor sign off? The process of donation is as follows… (feel free to correct me, or add anything) 1. General pre-agreement from the PMC that we'll take this project in, and how it will fit in. Some questions I (personally) have are, - Is the PMC ok with accepting a kotlin repository into the main part of the project ? (I assume so, kotlin == java, just asking the question. this was asked before, maybe i missed any response) - Who are the initial three PMC members that are volunteering to be active ? (Jon, Jordan, and ?) - How will the activity in this repository maintain visibility to the rest of the project ? (see recent discussions wrt sidecar's activity silo-ing) - Is the repo intending to adopt general project practices ? (e.g. release formalities, "patch by ; reviewed by for " commit messages, etc etc etc. if not, what is planned…) - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have 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
Posted by Brandon Williams <dr...@gmail.com>.
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 <jo...@rustyrazorblade.com> 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 <sc...@paradoxica.net> 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č <sm...@apache.org> wrote:
>>
>> * easy-cass-stress, sorry. Everything else holds.
>>
>> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org> wrote:
>>>
>>> What does "replacing" actually mean? If this tool is added to a separate repository, you mean like it would be put there under the "easy-cass-lab" name and all source code of cassandra-stress in the Cassandra repository would be removed? Are we going to deprecate what we have first or it is going to be a big bang?
>>>
>>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think that "easy-cass-lab" should be the name of a repo we are going to use. For a custom tool living outside of Cassandra until now, sure, but the official stress tool should not be called "easy-cass-lab". People would be like ... what? IMHO we should rename it to cassandra-stress.
>>>
>>> On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote:
>>>>
>>>> I'm +1 on replacing the existing cassandra-stress. My team did some work last Summer to remove Thrift related CLI args, but arg parsing alone is a 5K line mess. It's certainly not being well-maintained and could use a replacement.
>>>>
>>>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org> wrote:
>>>>>
>>>>> Unsolicited .02:
>>>>>
>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have encouraged the questions above)
>>>>>
>>>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>>>>
>>>>> Given the current tool is unmaintained and doesn't (to my knowledge) have a workflow-based usage paradigm that could be easily extended, seems like a clear win.
>>>>>
>>>>>
>>>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>>>>
>>>>> reply below.
>>>>>
>>>>>
>>>>> I’m terms of next steps: Mick what do we need to do next? Figure out the answers to your questions re: getting contributor sign off?
>>>>>
>>>>>
>>>>>
>>>>> The process of donation is as follows… (feel free to correct me, or add anything)
>>>>>
>>>>>
>>>>> 1. General pre-agreement from the PMC that we'll take this project in, and how it will fit in.
>>>>>
>>>>> Some questions I (personally) have are,
>>>>> - Is the PMC ok with accepting a kotlin repository into the main part of the project ? (I assume so, kotlin == java, just asking the question. this was asked before, maybe i missed any response)
>>>>> - Who are the initial three PMC members that are volunteering to be active ? (Jon, Jordan, and ?)
>>>>> - How will the activity in this repository maintain visibility to the rest of the project ? (see recent discussions wrt sidecar's activity silo-ing)
>>>>> - Is the repo intending to adopt general project practices ? (e.g. release formalities, "patch by ; reviewed by for " commit messages, etc etc etc. if not, what is planned…)
>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have 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
Posted by Jon Haddad <jo...@rustyrazorblade.com>.
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 <sc...@paradoxica.net> 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č <sm...@apache.org>
> wrote:
>
> * easy-cass-stress, sorry. Everything else holds.
>
> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org>
> wrote:
>
>> What does "replacing" actually mean? If this tool is added to a separate
>> repository, you mean like it would be put there under the "easy-cass-lab"
>> name and all source code of cassandra-stress in the Cassandra repository
>> would be removed? Are we going to deprecate what we have first or it is
>> going to be a big bang?
>>
>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think
>> that "easy-cass-lab" should be the name of a repo we are going to use. For
>> a custom tool living outside of Cassandra until now, sure, but the official
>> stress tool should not be called "easy-cass-lab". People would be like ...
>> what? IMHO we should rename it to cassandra-stress.
>>
>> On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote:
>>
>>> I'm +1 on replacing the existing cassandra-stress. My team did some
>>> work last Summer to remove Thrift related CLI args, but arg parsing alone
>>> is a 5K line mess. It's certainly not being well-maintained and could use a
>>> replacement.
>>>
>>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org>
>>> wrote:
>>>
>>>> Unsolicited .02:
>>>>
>>>> - If this will eventually replace the in-tree cassandra-stress, does it
>>>> warrant a CEP ? (i'm ok with skipping, though that step might have
>>>> encouraged the questions above)
>>>>
>>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>>>
>>>> Given the current tool is unmaintained and doesn't (to my knowledge)
>>>> have a workflow-based usage paradigm that could be easily extended, seems
>>>> like a clear win.
>>>>
>>>>
>>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>>>
>>>> reply below.
>>>>
>>>>
>>>> I’m terms of next steps: Mick what do we need to do next? Figure out
>>>> the answers to your questions re: getting contributor sign off?
>>>>
>>>>
>>>>
>>>> The process of donation is as follows… (feel free to correct me, or add
>>>> anything)
>>>>
>>>>
>>>> 1. General pre-agreement from the PMC that we'll take this project in,
>>>> and how it will fit in.
>>>>
>>>> Some questions I (personally) have are,
>>>> - Is the PMC ok with accepting a kotlin repository into the main part
>>>> of the project ? (I assume so, kotlin == java, just asking the question.
>>>> this was asked before, maybe i missed any response)
>>>> - Who are the initial three PMC members that are volunteering to be
>>>> active ? (Jon, Jordan, and ?)
>>>> - How will the activity in this repository maintain visibility to the
>>>> rest of the project ? (see recent discussions wrt sidecar's activity
>>>> silo-ing)
>>>> - Is the repo intending to adopt general project practices ? (e.g.
>>>> release formalities, "patch by ; reviewed by for " commit messages, etc etc
>>>> etc. if not, what is planned…)
>>>> - If this will eventually replace the in-tree cassandra-stress, does it
>>>> warrant a CEP ? (i'm ok with skipping, though that step might have
>>>> 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
Posted by sc...@paradoxica.net.
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č <sm...@apache.org> wrote:
>
> * easy-cass-stress, sorry. Everything else holds.
>
> On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <smiklosovic@apache.org <ma...@apache.org>> wrote:
>> What does "replacing" actually mean? If this tool is added to a separate repository, you mean like it would be put there under the "easy-cass-lab" name and all source code of cassandra-stress in the Cassandra repository would be removed? Are we going to deprecate what we have first or it is going to be a big bang?
>>
>> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think that "easy-cass-lab" should be the name of a repo we are going to use. For a custom tool living outside of Cassandra until now, sure, but the official stress tool should not be called "easy-cass-lab". People would be like ... what? IMHO we should rename it to cassandra-stress.
>>
>> On Sun, Oct 13, 2024 at 8:33 PM Brad <bschoeni@gmail.com <ma...@gmail.com>> wrote:
>>> I'm +1 on replacing the existing cassandra-stress. My team did some work last Summer to remove Thrift related CLI args, but arg parsing alone is a 5K line mess. It's certainly not being well-maintained and could use a replacement.
>>>
>>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jmckenzie@apache.org <ma...@apache.org>> wrote:
>>>> Unsolicited .02:
>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have encouraged the questions above)
>>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>>>
>>>> Given the current tool is unmaintained and doesn't (to my knowledge) have a workflow-based usage paradigm that could be easily extended, seems like a clear win.
>>>>
>>>>
>>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>>>> reply below.
>>>>>
>>>>> I’m terms of next steps: Mick what do we need to do next? Figure out the answers to your questions re: getting contributor sign off?
>>>>>
>>>>>
>>>>>
>>>>> The process of donation is as follows… (feel free to correct me, or add anything)
>>>>>
>>>>>
>>>>> 1. General pre-agreement from the PMC that we'll take this project in, and how it will fit in.
>>>>>
>>>>> Some questions I (personally) have are,
>>>>> - Is the PMC ok with accepting a kotlin repository into the main part of the project ? (I assume so, kotlin == java, just asking the question. this was asked before, maybe i missed any response)
>>>>> - Who are the initial three PMC members that are volunteering to be active ? (Jon, Jordan, and ?)
>>>>> - How will the activity in this repository maintain visibility to the rest of the project ? (see recent discussions wrt sidecar's activity silo-ing)
>>>>> - Is the repo intending to adopt general project practices ? (e.g. release formalities, "patch by ; reviewed by for " commit messages, etc etc etc. if not, what is planned…)
>>>>> - If this will eventually replace the in-tree cassandra-stress, does it warrant a CEP ? (i'm ok with skipping, though that step might have 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 <http://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
Posted by Štefan Miklošovič <sm...@apache.org>.
* easy-cass-stress, sorry. Everything else holds.
On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <sm...@apache.org>
wrote:
> What does "replacing" actually mean? If this tool is added to a separate
> repository, you mean like it would be put there under the "easy-cass-lab"
> name and all source code of cassandra-stress in the Cassandra repository
> would be removed? Are we going to deprecate what we have first or it is
> going to be a big bang?
>
> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think
> that "easy-cass-lab" should be the name of a repo we are going to use. For
> a custom tool living outside of Cassandra until now, sure, but the official
> stress tool should not be called "easy-cass-lab". People would be like ...
> what? IMHO we should rename it to cassandra-stress.
>
> On Sun, Oct 13, 2024 at 8:33 PM Brad <bs...@gmail.com> wrote:
>
>> I'm +1 on replacing the existing cassandra-stress. My team did some work
>> last Summer to remove Thrift related CLI args, but arg parsing alone is a
>> 5K line mess. It's certainly not being well-maintained and could use a
>> replacement.
>>
>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org>
>> wrote:
>>
>>> Unsolicited .02:
>>>
>>> - If this will eventually replace the in-tree cassandra-stress, does it
>>> warrant a CEP ? (i'm ok with skipping, though that step might have
>>> encouraged the questions above)
>>>
>>> I'm +1 to this replacing, -0 on requiring a CEP.
>>>
>>> Given the current tool is unmaintained and doesn't (to my knowledge)
>>> have a workflow-based usage paradigm that could be easily extended, seems
>>> like a clear win.
>>>
>>>
>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>>
>>> reply below.
>>>
>>>
>>> I’m terms of next steps: Mick what do we need to do next? Figure out the
>>> answers to your questions re: getting contributor sign off?
>>>
>>>
>>>
>>> The process of donation is as follows… (feel free to correct me, or add
>>> anything)
>>>
>>>
>>> 1. General pre-agreement from the PMC that we'll take this project in,
>>> and how it will fit in.
>>>
>>> Some questions I (personally) have are,
>>> - Is the PMC ok with accepting a kotlin repository into the main part of
>>> the project ? (I assume so, kotlin == java, just asking the question. this
>>> was asked before, maybe i missed any response)
>>> - Who are the initial three PMC members that are volunteering to be
>>> active ? (Jon, Jordan, and ?)
>>> - How will the activity in this repository maintain visibility to the
>>> rest of the project ? (see recent discussions wrt sidecar's activity
>>> silo-ing)
>>> - Is the repo intending to adopt general project practices ? (e.g.
>>> release formalities, "patch by ; reviewed by for " commit messages, etc etc
>>> etc. if not, what is planned…)
>>> - If this will eventually replace the in-tree cassandra-stress, does it
>>> warrant a CEP ? (i'm ok with skipping, though that step might have
>>> 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
Posted by Štefan Miklošovič <sm...@apache.org>.
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 <bs...@gmail.com> wrote:
> I'm +1 on replacing the existing cassandra-stress. My team did some work
> last Summer to remove Thrift related CLI args, but arg parsing alone is a
> 5K line mess. It's certainly not being well-maintained and could use a
> replacement.
>
> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jm...@apache.org>
> wrote:
>
>> Unsolicited .02:
>>
>> - If this will eventually replace the in-tree cassandra-stress, does it
>> warrant a CEP ? (i'm ok with skipping, though that step might have
>> encouraged the questions above)
>>
>> I'm +1 to this replacing, -0 on requiring a CEP.
>>
>> Given the current tool is unmaintained and doesn't (to my knowledge) have
>> a workflow-based usage paradigm that could be easily extended, seems like a
>> clear win.
>>
>>
>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>>
>> reply below.
>>
>>
>> I’m terms of next steps: Mick what do we need to do next? Figure out the
>> answers to your questions re: getting contributor sign off?
>>
>>
>>
>> The process of donation is as follows… (feel free to correct me, or add
>> anything)
>>
>>
>> 1. General pre-agreement from the PMC that we'll take this project in,
>> and how it will fit in.
>>
>> Some questions I (personally) have are,
>> - Is the PMC ok with accepting a kotlin repository into the main part of
>> the project ? (I assume so, kotlin == java, just asking the question. this
>> was asked before, maybe i missed any response)
>> - Who are the initial three PMC members that are volunteering to be
>> active ? (Jon, Jordan, and ?)
>> - How will the activity in this repository maintain visibility to the
>> rest of the project ? (see recent discussions wrt sidecar's activity
>> silo-ing)
>> - Is the repo intending to adopt general project practices ? (e.g.
>> release formalities, "patch by ; reviewed by for " commit messages, etc etc
>> etc. if not, what is planned…)
>> - If this will eventually replace the in-tree cassandra-stress, does it
>> warrant a CEP ? (i'm ok with skipping, though that step might have
>> 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
Posted by Brad <bs...@gmail.com>.
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 <jm...@apache.org> wrote:
> Unsolicited .02:
>
> - If this will eventually replace the in-tree cassandra-stress, does it
> warrant a CEP ? (i'm ok with skipping, though that step might have
> encouraged the questions above)
>
> I'm +1 to this replacing, -0 on requiring a CEP.
>
> Given the current tool is unmaintained and doesn't (to my knowledge) have
> a workflow-based usage paradigm that could be easily extended, seems like a
> clear win.
>
>
> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote:
>
> reply below.
>
>
> I’m terms of next steps: Mick what do we need to do next? Figure out the
> answers to your questions re: getting contributor sign off?
>
>
>
> The process of donation is as follows… (feel free to correct me, or add
> anything)
>
>
> 1. General pre-agreement from the PMC that we'll take this project in, and
> how it will fit in.
>
> Some questions I (personally) have are,
> - Is the PMC ok with accepting a kotlin repository into the main part of
> the project ? (I assume so, kotlin == java, just asking the question. this
> was asked before, maybe i missed any response)
> - Who are the initial three PMC members that are volunteering to be active
> ? (Jon, Jordan, and ?)
> - How will the activity in this repository maintain visibility to the rest
> of the project ? (see recent discussions wrt sidecar's activity silo-ing)
> - Is the repo intending to adopt general project practices ? (e.g. release
> formalities, "patch by ; reviewed by for " commit messages, etc etc etc.
> if not, what is planned…)
> - If this will eventually replace the in-tree cassandra-stress, does it
> warrant a CEP ? (i'm ok with skipping, though that step might have
> 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
Posted by Josh McKenzie <jm...@apache.org>.
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
Posted by Mick Semb Wever <mc...@apache.org>.
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
Posted by Jordan West <jw...@apache.org>.
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 <he...@rhinosource.com> 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 <jo...@rustyrazorblade.com>
> 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 <jw...@apache.org> 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 <dr...@apple.com> 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 <dr...@apple.com> 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 <ad...@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 <jw...@apache.org> a écrit :
>>>>
>>>>> I would likely commit to it as well
>>>>>
>>>>> Jordan
>>>>>
>>>>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dc...@apple.com>
>>>>> 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 <mc...@apache.org> 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
Posted by Dave Herrington <he...@rhinosource.com>.
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 <jo...@rustyrazorblade.com> 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 <jw...@apache.org> 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 <dr...@apple.com> 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 <dr...@apple.com> 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 <ad...@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 <jw...@apache.org> a écrit :
>>>
>>>> I would likely commit to it as well
>>>>
>>>> Jordan
>>>>
>>>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dc...@apple.com> 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 <mc...@apache.org> 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
Posted by Jon Haddad <jo...@rustyrazorblade.com>.
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 <jw...@apache.org> 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 <dr...@apple.com> 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 <dr...@apple.com> 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 <ad...@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 <jw...@apache.org> a écrit :
>>
>>> I would likely commit to it as well
>>>
>>> Jordan
>>>
>>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dc...@apple.com> 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 <mc...@apache.org> 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
Posted by Jordan West <jw...@apache.org>.
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 <dr...@apple.com> 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 <dr...@apple.com> 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 <ad...@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 <jw...@apache.org> a écrit :
>
>> I would likely commit to it as well
>>
>> Jordan
>>
>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dc...@apple.com> 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 <mc...@apache.org> 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
Posted by Doug Rohrer <dr...@apple.com>.
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 <dr...@apple.com> 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 <ad...@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 <jwest@apache.org <ma...@apache.org>> a écrit :
>>> I would likely commit to it as well
>>>
>>> Jordan
>>>
>>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dcapwell@apple.com <ma...@apple.com>> 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 <mck@apache.org <ma...@apache.org>> 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.
>>>>>
>>>>