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 <j...@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 <droh...@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 <droh...@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 <adejanov...@gmail.com> >>> wrote: >>> >>> >>> Hi folks, >>> >>> I'm familiar with the codebase and can help with the maintenance and >>> evolution. >>> I already have some additional profiles that I can push there which were >>> never merged in the main branch of tlp-cluster. >>> >>> I love this tool (I know I'm biased) and hope it gets the attention it >>> deserves. >>> >>> Le mar. 30 avr. 2024, 23:17, Jordan West <jw...@apache.org> a écrit : >>> >>>> I would likely commit to it as well >>>> >>>> Jordan >>>> >>>> On Mon, Apr 29, 2024 at 10:55 David Capwell <dcapw...@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 <m...@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. >>>>> >>>>> >>>>> >>> --
