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