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