I'd be more in favor of making it a separate project, basically for all the reasons listed below. I'm assuming we'd want a management process to work across different versions, which will be more awkward if it's in tree. Even if that's not the case, keeping it in a different repo at this point will make iteration easier than if it were in tree. I'd imagine (or at least hope) that validating the management process for release would be less difficult than the main project, so tying them to the Cassandra release cycle seems unnecessarily restrictive.
On August 17, 2018 at 12:07:18 AM, Dinesh Joshi (dinesh.jo...@yahoo.com.invalid) wrote: > On Aug 16, 2018, at 9:27 PM, Sankalp Kohli <kohlisank...@gmail.com> wrote: > > I am bumping this thread because patch has landed for this with repair > functionality. > > I have a following proposal for this which I can put in the JIRA or doc > > 1. We should see if we can keep this in a separate repo like Dtest. This would imply a looser coupling between the two. Keeping things in-tree is my preferred approach. It makes testing, dependency management and code sharing easier. > 2. It should have its own release process. This means now there would be two releases that need to be managed and coordinated. > 3. It should have integration tests for different versions of Cassandra it > will support. Given the lack of test infrastructure - this will be hard especially if you have to qualify a matrix of builds. Dinesh --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
