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 <jmcken...@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 <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 > > > > > > > >
