I think that all sounds good. Let's get that new CEP started then. I think
there are opinions flying around based on last week's discussions that need
to coalesce.
Patrick
On Mon, Oct 14, 2024 at 3:19 PM Francisco Guerrero
wrote:
> From my point of view CEP-1 is overly broad in terms it wants t
>From my point of view CEP-1 is overly broad in terms it wants to achieve.
My understanding is that CEPs have to have a well-defined scope.
I agree with Joey that we should close CEP-1 with the features I have
proposed earlier in this thread. And have any future Sidecar work captured in
subsequent
> 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
Hi everyone!
I am curious what Dinesh's perspective is but I think the specific
enumerated scope in CEP-1 isn't super critical to be honest. That CEP
successfully (imo) built consensus that the community wants a separate
management process, and that sidecar both exists today and has useful
functio
Hi everyone,
Thank you to everyone who took the time to complete the survey. There was
~150 responses which was a little shy of last year's survey but still a
good sample.
I've compiled the graphs for the questions for you to look over. There is a
link to the raw data if anyone would like to embr
What are we going to do with CEP-1? Cut and rescope in a new CEP or rewrite
CEP-1?
On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero
wrote:
> Hi folks,
>
> It was great meeting some of you in person at Community over Code where
> we had a chance to discuss the Cassandra Sidecar project. A lot
Hi folks,
It was great meeting some of you in person at Community over Code where
we had a chance to discuss the Cassandra Sidecar project. A lot of
you expressed interest in having a release of Sidecar to start using the
existing features in the project:
- C* adapters for versions 4.0, 4.1, 5.0
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 agree that should be 1) and 2) together.
Regarding the PR review for 2.0, I can look into some (I'm not proficient with
Go, it has been a long time) but for triaging what should be in a major I can
surely help. Low hanging fruit should also not be a problem for me to review.
Are we looking to
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
11 matches
Mail list logo
