I lean towards the snapshot builds as well. I'd prefer we didn't introduce git submodules.. I have had enough facepalm experienced with them in the past that I'd prefer not to see us go down that path.
On Thu, Apr 16, 2020 at 4:34 PM J. D. Jordan <jeremiah.jor...@gmail.com> wrote: > I was taking with Alex on slack earlier today brainstorming ideas and two > that might work are using a git submodule to reference the code by git > hash, so no release needed, or using jitpack.io to be able to pull the > jar down by git hash without doing a release. > > Does anyone find either of those options more appealing than 1/2/3? > > -Jeremiah > > > On Apr 16, 2020, at 6:14 PM, David Capwell <dcapw...@gmail.com> wrote: > > > > Not a fan of 2 or 3. For #2 there is also talk about getting rid of the > > jars in /lib so that would complicate things. > > > > I think frequent releases with snapshots per commit is good. Agree with > > Nate we should document this so we have something we can always point to. > > > >> On Thu, Apr 16, 2020 at 2:54 PM Nate McCall <zznat...@gmail.com> wrote: > >> > >> (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 > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
