We can wait for a week post Freeze so everyone can participate however we need to decide after that so we can make progress. I am leaning towards piecemeal approach so we can review the code and pick best of all 3 options
> On Aug 29, 2018, at 00:26, kurt greaves <k...@instaclustr.com> wrote: > > 2c: There's a lot to think about here, and as Blake already mentioned most > people don't have time to dedicate a lot of thought to this at the moment. > There appear to be a lot of voices missing from the discussion, and I think > it's pretty clear this isn't super tied to the freeze, so maybe we should > leave this discussion until next week when everyone can take part? This > kind of goes for every sidecar related discussion going on at the moment > IMO. > > On 29 August 2018 at 16:44, Vinay Chella <vche...@netflix.com.invalid> > wrote: > >>> 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. >> >> Agreed, Yes, I don’t think we should write everything from the scratch, but >> carry forwarding tech debt (if any) and design decisions which makes new >> features in future difficult to develop is something that we need to >> consider. I second Dinesh’s thought on taking the best parts from available >> projects to move forward with the right solution which works great and >> easily pluggable. >> >> - >> Vinay Chella >> >> >>> On Tue, Aug 28, 2018 at 10:03 PM Mick Semb Wever <m...@apache.org> wrote: >>> >>> >>>> 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. >>> >>> >>> Thanks for writing this Blake. I'm no fan of writing from scratch. >> Working >>> with other people's code is the joy of open-source, imho. >>> >>> Reaper is not a big project. None of its java files are large or >>> complicated. >>> This is not the C* codebase we're talking about. >>> >>> It comes with strict code style in place (which the build enforces), unit >>> and integration tests. The tech debt that I think of first is removing >>> stuff that we would no longer want to support if it were inside the >>> Cassandra project. A number of recent refactorings have proved it's an >>> easy codebase to work with. >>> >>> It's also worth noting that Cassandra-4.x adoption is still some away, in >>> which time Reaper will only continue to grow and gain users. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
