Open an issue with the LEGAL jira project and ask there. I'm like 62% sure they will say nope. The vote process and the time for such is to allow for PMC to review the release to give the ASF a reasonable degree of assurance for indemnification. However, we might have a fair degree of leeway so long as we do 'vote', it's test scope (as Mick pointed out) and the process for such is published somewhere?
Cheers, -Nate On Thu, Apr 16, 2020 at 7:20 AM Oleksandr Petrov <oleksandr.pet...@gmail.com> wrote: > The most important thing for the purposes of what we’re trying to achieve > is to have a unique non overridable version. In principle, a unique tag > with release timestamp should be enough, as long as we can uniquely > reference it. > > However, even then, I’d say release frequency (establishing “base”) for > releases should be at least slightly relaxed compared to Cassandra itself. > > I will investigate whether it is possible to avoid voting for test only > dependencies, since I’d much rather have it under Apache umbrella, as I was > previously skeptical of a dependency that I believed shouldn’t have been > locked under contributor’s GitHub. > > If test only no-vote option isn’t possible due to legal reasons, we can > proceed with snapshot+timestamp and release-rebase with a 24h simplified > vote. > > Thanks, > —Alex > > On Wed 15. Apr 2020 at 19:24, Mick Semb Wever <m...@apache.org> wrote: > > > > Apache release rules were made for first-class projects. I would like > to > > > propose simplifying voting rules for in-jvm-dtest-api project [1]. > > > > > > I am not sure the PMC can simply vote away the ASF release rules here. > > But it should be possible to implement the proposal by stepping away > > from what the ASF considers a release and work with "nightlies" or > > snapshots. The purpose of an "ASF release" has little value to > > in-jvm-dtest-api, IIUC. > > > > For example you can't put artifacts into a public maven repository > > without a formal release vote. AFAIK the vote process is there for the > > sake of the legal protections the ASF extends to all its projects, > > over any notion of technical quality of the release cut. > > > > And we are not supposed to be including binaries in the source code > > artifacts, at least not for anything that runtime code depends on. > > > > Solutions to this could be… > > - allowing snapshot versions of test scope dependencies*, downloaded > > from the ASF's snapshot repository⁽¹⁾ > > - making an exception for a binary if only used in test scope (i > > believe this is ok), > > - move in-jvm-dtest-api out of ASF (just have it as a github project, > > and publish as needed to a maven repo) > > > > You could also keep using `mvn release:prepare` to cut the versions, > > but just not deploy them to ASF's distribution channels. > > > > This whole area of ASF procedures is quite extensive, so i'd > > definitely appreciate being correctly contradicted :-) > > > > My vote would be to take the approach of using the snapshot > > repository. Semantic versioning has limited value here, and you would > > be able to have a jenkins build push the latest in-jvm-dtest-api > > artifact into the snapshot repository using a uniqueVersion so that it > > can be referenced safely in the build.xml (avoiding having to check > > the jar file into the cassandra/lib/ folder). > > > > regards, > > Mick > > > > ⁽¹⁾ https://repository.apache.org/content/groups/snapshots/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > -- > alex p >
