I've posted the question on the legal-discussion mailing list, and got some helpful responses.
We can't work around the vote, best we can do is make it shorter (3 +1 votes / 24 hours). We have several options now: 1. Release SNAPSHOT builds prefixed with in-jvm dtest commit SHAs and cut release every week or so (release-train if you wish) 2. Avoid using Apache repository for releases altogether, and just push jars to Cassandra repository 3. Make this code "unofficial" (publish and manage outside Apache) I'm not a big fan of (2), since we already tried that with Python and Java drivers, also I'm not sure about binaries in git. As regards (3), I'm not sure if this makes it harder for the folks who rely on Apache legal framework for contributions. Unless there are strong opinions against (1), which seems to be a reasonable middle ground, we can do it. Please let me know if you also have other ideas. Thank you, -- Alex On Wed, Apr 15, 2020 at 10:33 PM Jeremiah D Jordan <jerem...@datastax.com> wrote: > I think as long as we don’t publish the artifacts to maven central or some > other location that is for “anyone” we do not need a formal release. Even > then since the artifact is only meant for use by people developing C* that > might be fine. > > If artifacts are only for use by individuals actively participating in the > development process, then no formal release is needed. See the definition > of “release” and “publication” found here: > > http://www.apache.org/legal/release-policy.html#release-definition > > DEFINITION OF "RELEASE" < > http://www.apache.org/legal/release-policy.html#release-definition> > > Generically, a release is anything that is published beyond the group > that owns it. For an Apache project, that means any publication outside the > development community, defined as individuals actively participating in > development or following the dev list. > > > > More narrowly, an official Apache release is one which has been endorsed > as an "act of the Foundation" by a PMC. > > > > > > > PUBLICATION <http://www.apache.org/legal/release-policy.html#publication > > > > Projects SHALL publish official releases and SHALL NOT publish > unreleased materials outside the development community. > > > > During the process of developing software and preparing a release, > various packages are made available to the development community for > testing purposes. Projects MUST direct outsiders towards official releases > rather than raw source repositories, nightly builds, snapshots, release > candidates, or any other similar packages. The only people who are supposed > to know about such developer resources are individuals actively > participating in development or following the dev list and thus aware of > the conditions placed on unreleased materials. > > > > > -Jeremiah > > > On Apr 15, 2020, at 3:05 PM, Nate McCall <zznat...@gmail.com> wrote: > > > > 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 > >> > > -- alex p
