I share Dinesh's concern too regarding tech debt with existing codebase. Its good we have multiple solutions for repairs which have been always painful in Cassandra. It would be great to see the community take the best pieces from the available solutions and roll it into the fresh side car which will help ease Cassandra's maintenance for lot of folks.
My main concern with starting with an existing codebase is that it comes with tech debt. This is not specific to Reaper but to any codebase that is imported as a whole. This means future developers and patches have to work within the confines of the decisions that were already made. Practically speaking once a codebase is established there is inertia in making architectural changes and we're left dealing with technical debt. *Regards,* *Roopa Tangirala* Engineering Manager CDE *(408) 438-3156 - mobile* On Mon, Aug 27, 2018 at 10:49 PM Dinesh Joshi <dinesh.jo...@yahoo.com.invalid> wrote: > > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > > We're hoping to get some feedback on our side if that's something people > > are interested in. We've gone back and forth privately on our own > > preferences, hopes, dreams, etc, but I feel like a public discussion > would > > be healthy at this point. Does anyone share the view of using Reaper as > a > > starting point? What concerns to people have? > > > I have briefly looked at the Reaper codebase but I am yet to analyze it > better to have a real, meaningful opinion. > > My main concern with starting with an existing codebase is that it comes > with tech debt. This is not specific to Reaper but to any codebase that is > imported as a whole. This means future developers and patches have to work > within the confines of the decisions that were already made. Practically > speaking once a codebase is established there is inertia in making > architectural changes and we're left dealing with technical debt. > > As it stands I am not against the idea of using Reaper's features and I > would very much like using mature code that has been tested. I would > however like to propose piece-mealing it into the codebase. This will give > the community a chance to review what is going in and possibly change some > of the design decisions upfront. This will also avoid a situation where we > have to make many breaking changes in the initial versions due to > refactoring. > > I would also like it if we could compare and contrast the functionality > with Priam or any other interesting sidecars that folks may want to call > out. In fact it would be great if we could bring in the best functionality > from multiple implementations. > > Dinesh > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
