+1 On Wed, Apr 15, 2020, 6:58 AM Aleksey Yeshchenko <alek...@apple.com.invalid> wrote:
> +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 > >
