(1) sounds reasonable to me. I'd like us to document the vote cycle and release train specifics on cassandra.a.o somewhere (developer and releases pages maybe?). Nothing exhaustive, just 'we do X with Y'.
On Thu, Apr 16, 2020 at 11:03 PM Oleksandr Petrov < oleksandr.pet...@gmail.com> wrote: > 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 >
