Re: Proposing an Apache Cassandra Management process

[dinesh.jo...@yahoo.com.INVALID]

On Mon, Aug 20, 2018 at 4:23 AM Mick Semb Wever <m...@apache.org> wrote:
>
> We are looking to contribute Reaper to the Cassandra project.
>
> Looking at the patch it's very similar in its base design already, but
> Reaper does has a lot more to offer. We have all been working hard to move
> it to also being a side-car so it can be contributed. This raises a number
> of relevant questions to this thread: would we then accept both works in
> the Cassandra project, and what burden would it put on the current PMC to
> maintain both works.
I think the comparison is not fair. The patch that has landed is new and is the 
beginning of a sidecar within Cassandra. It would be unfair to compare its 
features with Reaper which has been around for some time now. 
I proposed a management process (not exactly a sidecar) for Cassandra about 4 
months ago. Had you guys indicated interest in contributing Reaper, we would 
not be discussing two separate implementations. Don't get me wrong, I'm happy 
that we're talking about this right now.
> This seems at odds when we're already struggling to keep up with the
> incoming patches/contributions, and there could be other git repos in the
> project we will need to support in the future too. 
I think this is a great problem to have for a project. This is a sign that the 
pool of contributors is greater than reviewers / committers. I personally have 
been volunteering my time reviewing tickets, fixing flaky tests and generally 
helping out. I definitely think we need more people actively contributing.
> The Reaper project has worked hard in building both its user and
> contributor base. And I would have thought these, including having the
> contributor base overlap with the C* PMC, were prerequisites before moving
> a larger body of work into the project (separate git repo or not). I guess
You're talking about donating a body of code i.e. Reaper which is different 
from building a new feature from scratch.
> There's been little effort in evaluating these two bodies of work, one
> which is largely unknown to us, and my concern is how we would fairly
> support both going into the future?
I don't think we should have two separate implementations as part of the 
project. It would be best if we could have a single sidecar that could have 
features from Reaper as well as the proposed patch.
Thanks,
Dinesh