+1 ________________________________ From: Sam Tunnicliffe <s...@beobal.com> Sent: Wednesday, April 15, 2020 7:49:50 AM To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: Simplify voting rules for in-jvm-dtest-api releases
+1 > On 15 Apr 2020, at 14:35, Oleksandr Petrov <oleksandr.pet...@gmail.com> wrote: > > Hi everyone, > > Apache release rules were made for first-class projects. I would like to > propose simplifying voting rules for in-jvm-dtest-api project [1]. > > A bit of background: in-jvm-dtest-api is a project that is used by all > active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces > that allows creating clusters and running tests, much like Python dtests, > just with a potential to run and develop them faster. Previously, anyone > could break API compatibility by committing to only one of the branches and > not updating the other one, which has happened on several occasions and has > went unnoticed, and has added work for people who had to bring changes to > more than one branch. This unified API and tests are particularly useful > for upgrade tests, but are also good for any kind of testing. > > Since this project was made to simplify contributions to in-jvm dtests, > it'd be great if making changes to this project would actually be simple. > Before that, in order to make changes in in-jvm-dtest API, we required > only +1 from a contributor and a committer could just commit the change. > > I would say that in order to cut a (minor) release of in-jvm-dtest-api you > should: > > 1. Get a +1 from a contributor who can review and test your change > 2. Get a +1 from one of committers who are familiar with in-jvm dtests (we > have enough, I just don't want to volunteer anyone) > > This will guard us from unnecessary changes, and add an extra pair of eyes > for things that influence moore than one branch, but leave us flexible > enough to be able to move forward without conducting a vote. > > Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended > for production purposes, this is a low-risk change in procedure. Moreover, > even if we package in-jvm-dtest-api with some Cassandra release, there will > be an additional vote on the release, where anyone who has concerns about > in-jvm-dtest-api changes can still voice them. > > Please let me know if you'd like more information about in-jvm-dtest API, > or have comments about this change in procedure. > > Thank you, > -- Alex > [1] https://github.com/apache/cassandra-in-jvm-dtest-api --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
