I like the idea, +1 > On 15 Apr 2020, at 10:30, Jon Haddad <j...@jonhaddad.com> wrote: > > +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 >> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
