I haven’t settled on a position yet (will have more time think about things after the 9/1 freeze), but I wanted to point out that the argument that something new should be written because an existing project has tech debt, and we'll do it the right way this time, is a pretty common software engineering mistake. The thing you’re replacing usually needs to have some really serious problems to make it worth replacing.
I’m sure reaper will bring tech debt with it, but I doubt it's a hopeless mess. It would bring a relatively mature project as well as a community of users and developers that the other options won’t. It’s probably a lot less work to rework whatever shortcomings reaper has, add new-hotness repair schedulers to it, and get people to actually use them than it would be to write something from scratch and build community confidence in it and get reaper users to switch. On August 28, 2018 at 1:40:59 PM, Roopa Tangirala (rtangir...@netflix.com.invalid) wrote: 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 > >
