On Wed, 23 Oct 2024 at 05:48, Jordan West 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 th
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 tak
> 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
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-
> 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 wi
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 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 M
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
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 wo
* easy-cass-stress, sorry. Everything else holds.
On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič
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 cassand
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
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 wrote:
> Unsolici
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 (
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
Hi
I would also love to contribute to this project
On Sat, Oct 12, 2024 at 3:34 AM Jordan West 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 1
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 wrote:
> Jon/Jordan,
>
> Happy to contribute to easy-cass-stress in any way I can that will help
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 co
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
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 wrote:
> Clarification - there would be some real value in donating *easy-cass-stress
> (as the subje
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 wrote:
>
> Hey folks,
>
> I just wanted to resurface this convers
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,
Hey folks,
I just wanted to resurface this conversation, especially after Jon and Jordon’s
awesome talk/“live demo" 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 (please correct me if I’m
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
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 m
I would likely commit to it as well
Jordan
On Mon, Apr 29, 2024 at 10:55 David Capwell 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, 2
> 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 wrote:
>
>> A separate subproject like dtest and the Java driver wou
>
> 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
ter
The current cassandra-stress is in poor condition and clocks in at a hefty
16k lines of Java code. I was involved in some work with it last Summer
(CASSANDRA-18529) and it was tricky.
I'm strongly in favor of replacing it with a modern tool which is easier to
configure and more user friendly. Wh
@mck I haven't done anything with IP clearance. Not sure how to, and I
want to get a feel for if we even want it in the project before I invest
time in. Jeff's question about people willing to maintain the project is a
good one and if people aren't willing to maintain it with me, it's only
going
On Fri, 26 Apr 2024 at 00:11, Jon Haddad wrote:
> I should probably have noted - since TLP is no more, I renamed tlp-stress
> to easy-cass-stress around half a year ago when I took it over again.
>
Do we have the IP cleared for donation ?
At what SHA did you take and rename tlp-stress, and who
I do have some familiarity w/ the codebase, and I could help support it in a minor capacity. (Reviews, small fixes, etc.) Probably not something I could spend hours on every week.On Apr 25, 2024, at 5:11 PM, Jon Haddad wrote:I should probably have noted - since TLP is no more, I renamed tlp-stres
I should probably have noted - since TLP is no more, I renamed tlp-stress
to easy-cass-stress around half a year ago when I took it over again.
Jon
On Thu, Apr 25, 2024 at 3:05 PM Jeff Jirsa wrote:
> Unless there’s 2-3 other people who expect to keep working on it, I don’t
> see how we justify
Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going forward?
I am not familiar with ECS but if we’re going to go for it I would prefer
it to be a sub project really. Jon, what do you think?
On Thu, Apr 25, 2024 at 2:44 PM Brandon Williams wrote:
> I want to begin by saying I am generally +1 on this because I have
> become a fan of easy-cass-stress after u
Yeah, I agree with your concerns. I very firmly prefer a separate
subproject. I've got zero interest in moving from a modern Gradle project
to an ant based one. It would be a lot of work for not much benefit.
If we wanted to replace cassandra-stress, I'd say bring in the release
artifact as par
I want to begin by saying I am generally +1 on this because I have
become a fan of easy-cass-stress after using it, but I am curious if
this is intended to be a subproject, or replace cassandra-stress? If
the latter, we are going to have to reconcile the build systems
somehow. I don't really want
I've been asked by quite a few people, both in person and in JIRA [1] about
contributing easy-cass-stress [2] to the project. I've been happy to
maintain the project myself over the years but given its widespread use I
think it makes sense to make it more widely available and under the
project's u
37 matches
Mail list logo
