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 > > > > >
