+1 to jitpack
On Fri, Apr 17, 2020 at 8:50 AM Oleksandr Petrov
wrote:
> Thank you for suggestions, Jeremiah!
>
> I first really liked the idea of jitpack since I thought it clones
> repository and builds stuff locally. However, it seems like they build on
> their machines in docker container.
Thank you for suggestions, Jeremiah!
I first really liked the idea of jitpack since I thought it clones
repository and builds stuff locally. However, it seems like they build on
their machines in docker container. While this is something that could be
useful in many cases, I think just using
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
wrote:
> I was taking with Alex on slack
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
(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
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
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
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”)
> 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
+1
On Wed, Apr 15, 2020 at 12:22 PM Brandon Williams wrote:
> +1
>
> On Wed, Apr 15, 2020 at 8:35 AM Oleksandr Petrov
> 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
On Wed, Apr 15, 2020 at 8:35 AM Oleksandr Petrov
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
+1
On Wed, Apr 15, 2020 at 8:32 AM Yifan Cai wrote:
> +1
>
>
> From: Sam Tunnicliffe
> Sent: Wednesday, April 15, 2020 7:49:50 AM
> To: dev@cassandra.apache.org
> Subject: Re: Simplify voting rules for in-jvm-dtest-api releases
>
&
+1
From: Sam Tunnicliffe
Sent: Wednesday, April 15, 2020 7:49:50 AM
To: dev@cassandra.apache.org
Subject: Re: Simplify voting rules for in-jvm-dtest-api releases
+1
> On 15 Apr 2020, at 14:35, Oleksandr Petrov wrote:
>
> Hi everyone,
>
> Apach
+1
> On 15 Apr 2020, at 14:35, Oleksandr Petrov 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
I like the idea, +1
> On 15 Apr 2020, at 10:30, Jon Haddad wrote:
>
> +1
>
>> On Wed, Apr 15, 2020, 6:58 AM Aleksey Yeshchenko
>> wrote:
>>
>> +1
>>
>>> On 15 Apr 2020, at 14:35, Oleksandr Petrov
>> wrote:
>>>
>>> Hi everyone,
>>>
>>> Apache release rules were made for first-class
+1
On Wed, Apr 15, 2020, 6:58 AM Aleksey Yeshchenko
wrote:
> +1
>
> > On 15 Apr 2020, at 14:35, Oleksandr Petrov
> 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].
+1
> On 15 Apr 2020, at 14:35, Oleksandr Petrov 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
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
19 matches
Mail list logo
