Re: Simplify voting rules for in-jvm-dtest-api releases

[Jake Luciani]

+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. While this is something that could be
> useful in many cases, I think just using snapshots with hash would yield a
> similar result.
>
> Another suggestion from Jeremiah was to use submodules, which could be
> helpful for IDE. We can explore this in future, I just do not have capacity
> at the moment to figure out how to make sure it all builds with ant to make
> it work nicely for developers.
>
> @Nate McCall   I've added some information about
> deployment to readme file [1], and have also posted how to build a snapshot
> [2]. I'll add information about the length of vote with a reference to this
> mailing list discussion for history.
>
> -- Alex
>
>
> [1]
> https://github.com/apache/cassandra-in-jvm-dtest-api/blob/master/README.md
> [2]
>
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/29d055b7cffc66a852505660930c980c185138a1
>
>
> On Fri, Apr 17, 2020 at 1:34 AM J. D. Jordan 
> 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  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 
> 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
> > >
> 

Re: Simplify voting rules for in-jvm-dtest-api releases

[Oleksandr Petrov]

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 snapshots with hash would yield a
similar result.

Another suggestion from Jeremiah was to use submodules, which could be
helpful for IDE. We can explore this in future, I just do not have capacity
at the moment to figure out how to make sure it all builds with ant to make
it work nicely for developers.

@Nate McCall   I've added some information about
deployment to readme file [1], and have also posted how to build a snapshot
[2]. I'll add information about the length of vote with a reference to this
mailing list discussion for history.

-- Alex


[1]
https://github.com/apache/cassandra-in-jvm-dtest-api/blob/master/README.md
[2]
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/29d055b7cffc66a852505660930c980c185138a1


On Fri, Apr 17, 2020 at 1:34 AM J. D. Jordan 
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  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  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 

Re: Simplify voting rules for in-jvm-dtest-api releases

[Jon Haddad]

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 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  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  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  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. 

Re: Simplify voting rules for in-jvm-dtest-api releases

[David Capwell]

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  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  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 

Re: Simplify voting rules for in-jvm-dtest-api releases

[Nate McCall]

(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 
> 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  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  wrote:
> > >>
> >  Apache release rules were made for first-class 

Re: Simplify voting rules for in-jvm-dtest-api releases

[Oleksandr Petrov]

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 
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  >
> > 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  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  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 

Re: Simplify voting rules for in-jvm-dtest-api releases

[Jeremiah D Jordan]

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" 
> 
> 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 
> 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  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 
> 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  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 

Re: Simplify voting rules for in-jvm-dtest-api releases

[Nate McCall]

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 
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  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
>

Re: Simplify voting rules for in-jvm-dtest-api releases

[Oleksandr Petrov]

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  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

Re: Simplify voting rules for in-jvm-dtest-api releases

[Mick Semb Wever]

> 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

Re: Simplify voting rules for in-jvm-dtest-api releases

[Joshua McKenzie]

+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].
> >
> > 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 interfaces
> > that allows creating clusters and running tests, much like Python dtests,
> > just with a potential to run and develop them faster. Previously, anyone
> > could break API compatibility by committing to only one of the branches
> and
> > not updating the other one, which has happened on several occasions and
> has
> > went unnoticed, and has added work for people who had to bring changes to
> > more than one branch. This unified API and tests are particularly useful
> > for upgrade tests, but are also good for any kind of testing.
> >
> > Since this project was made to simplify contributions to in-jvm dtests,
> > it'd be great if making changes to this project would actually be simple.
> > Before that, in order to make changes in in-jvm-dtest API, we required
> > only +1 from a contributor and a committer could just commit the change.
> >
> > I would say that in order to cut a (minor) release of in-jvm-dtest-api
> you
> > should:
> >
> > 1. Get a +1 from a contributor who can review and test your change
> > 2. Get a +1 from one of committers who are familiar with in-jvm dtests
> (we
> > have enough, I just don't want to volunteer anyone)
> >
> > This will guard us from unnecessary changes, and add an extra pair of
> eyes
> > for things that influence moore than one branch, but leave us flexible
> > enough to be able to move forward without conducting a vote.
> >
> > Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> > for production purposes, this is a low-risk change in procedure.
> Moreover,
> > even if we package in-jvm-dtest-api with some Cassandra release, there
> will
> > be an additional vote on the release, where anyone who has concerns about
> > in-jvm-dtest-api changes can still voice them.
> >
> > Please let me know if you'd like more information about in-jvm-dtest API,
> > or have comments about this change in procedure.
> >
> > Thank you,
> > -- Alex
> > [1] https://github.com/apache/cassandra-in-jvm-dtest-api
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Simplify voting rules for in-jvm-dtest-api releases

[Brandon Williams]

+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
> active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
> that allows creating clusters and running tests, much like Python dtests,
> just with a potential to run and develop them faster. Previously, anyone
> could break API compatibility by committing to only one of the branches and
> not updating the other one, which has happened on several occasions and has
> went unnoticed, and has added work for people who had to bring changes to
> more than one branch. This unified API and tests are particularly useful
> for upgrade tests, but are also good for any kind of testing.
>
> Since this project was made to simplify contributions to in-jvm dtests,
> it'd be great if making changes to this project would actually be simple.
> Before that, in order to make changes in in-jvm-dtest API, we required
> only +1 from a contributor and a committer could just commit the change.
>
> I would say that in order to cut a (minor) release of in-jvm-dtest-api you
> should:
>
> 1. Get a +1 from a contributor who can review and test your change
> 2. Get a +1 from one of committers who are familiar with in-jvm dtests (we
> have enough, I just don't want to volunteer anyone)
>
> This will guard us from unnecessary changes, and add an extra pair of eyes
> for things that influence moore than one branch, but leave us flexible
> enough to be able to move forward without conducting a vote.
>
> Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> for production purposes, this is a low-risk change in procedure. Moreover,
> even if we package in-jvm-dtest-api with some Cassandra release, there will
> be an additional vote on the release, where anyone who has concerns about
> in-jvm-dtest-api changes can still voice them.
>
> Please let me know if you'd like more information about in-jvm-dtest API,
> or have comments about this change in procedure.
>
> Thank you,
> -- Alex
> [1] https://github.com/apache/cassandra-in-jvm-dtest-api

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Simplify voting rules for in-jvm-dtest-api releases

[sankalp kohli]

+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
>
> > 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
> > active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
> > that allows creating clusters and running tests, much like Python dtests,
> > just with a potential to run and develop them faster. Previously, anyone
> > could break API compatibility by committing to only one of the branches
> and
> > not updating the other one, which has happened on several occasions and
> has
> > went unnoticed, and has added work for people who had to bring changes to
> > more than one branch. This unified API and tests are particularly useful
> > for upgrade tests, but are also good for any kind of testing.
> >
> > Since this project was made to simplify contributions to in-jvm dtests,
> > it'd be great if making changes to this project would actually be simple.
> > Before that, in order to make changes in in-jvm-dtest API, we required
> > only +1 from a contributor and a committer could just commit the change.
> >
> > I would say that in order to cut a (minor) release of in-jvm-dtest-api
> you
> > should:
> >
> > 1. Get a +1 from a contributor who can review and test your change
> > 2. Get a +1 from one of committers who are familiar with in-jvm dtests
> (we
> > have enough, I just don't want to volunteer anyone)
> >
> > This will guard us from unnecessary changes, and add an extra pair of
> eyes
> > for things that influence moore than one branch, but leave us flexible
> > enough to be able to move forward without conducting a vote.
> >
> > Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> > for production purposes, this is a low-risk change in procedure.
> Moreover,
> > even if we package in-jvm-dtest-api with some Cassandra release, there
> will
> > be an additional vote on the release, where anyone who has concerns about
> > in-jvm-dtest-api changes can still voice them.
> >
> > Please let me know if you'd like more information about in-jvm-dtest API,
> > or have comments about this change in procedure.
> >
> > Thank you,
> > -- Alex
> > [1] https://github.com/apache/cassandra-in-jvm-dtest-api
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Simplify voting rules for in-jvm-dtest-api releases

[Yifan Cai]

+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,
>
> 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 interfaces
> that allows creating clusters and running tests, much like Python dtests,
> just with a potential to run and develop them faster. Previously, anyone
> could break API compatibility by committing to only one of the branches and
> not updating the other one, which has happened on several occasions and has
> went unnoticed, and has added work for people who had to bring changes to
> more than one branch. This unified API and tests are particularly useful
> for upgrade tests, but are also good for any kind of testing.
>
> Since this project was made to simplify contributions to in-jvm dtests,
> it'd be great if making changes to this project would actually be simple.
> Before that, in order to make changes in in-jvm-dtest API, we required
> only +1 from a contributor and a committer could just commit the change.
>
> I would say that in order to cut a (minor) release of in-jvm-dtest-api you
> should:
>
> 1. Get a +1 from a contributor who can review and test your change
> 2. Get a +1 from one of committers who are familiar with in-jvm dtests (we
> have enough, I just don't want to volunteer anyone)
>
> This will guard us from unnecessary changes, and add an extra pair of eyes
> for things that influence moore than one branch, but leave us flexible
> enough to be able to move forward without conducting a vote.
>
> Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> for production purposes, this is a low-risk change in procedure. Moreover,
> even if we package in-jvm-dtest-api with some Cassandra release, there will
> be an additional vote on the release, where anyone who has concerns about
> in-jvm-dtest-api changes can still voice them.
>
> Please let me know if you'd like more information about in-jvm-dtest API,
> or have comments about this change in procedure.
>
> Thank you,
> -- Alex
> [1] https://github.com/apache/cassandra-in-jvm-dtest-api


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Simplify voting rules for in-jvm-dtest-api releases

[Sam Tunnicliffe]

+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
> active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
> that allows creating clusters and running tests, much like Python dtests,
> just with a potential to run and develop them faster. Previously, anyone
> could break API compatibility by committing to only one of the branches and
> not updating the other one, which has happened on several occasions and has
> went unnoticed, and has added work for people who had to bring changes to
> more than one branch. This unified API and tests are particularly useful
> for upgrade tests, but are also good for any kind of testing.
> 
> Since this project was made to simplify contributions to in-jvm dtests,
> it'd be great if making changes to this project would actually be simple.
> Before that, in order to make changes in in-jvm-dtest API, we required
> only +1 from a contributor and a committer could just commit the change.
> 
> I would say that in order to cut a (minor) release of in-jvm-dtest-api you
> should:
> 
> 1. Get a +1 from a contributor who can review and test your change
> 2. Get a +1 from one of committers who are familiar with in-jvm dtests (we
> have enough, I just don't want to volunteer anyone)
> 
> This will guard us from unnecessary changes, and add an extra pair of eyes
> for things that influence moore than one branch, but leave us flexible
> enough to be able to move forward without conducting a vote.
> 
> Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> for production purposes, this is a low-risk change in procedure. Moreover,
> even if we package in-jvm-dtest-api with some Cassandra release, there will
> be an additional vote on the release, where anyone who has concerns about
> in-jvm-dtest-api changes can still voice them.
> 
> Please let me know if you'd like more information about in-jvm-dtest API,
> or have comments about this change in procedure.
> 
> Thank you,
> -- Alex
> [1] https://github.com/apache/cassandra-in-jvm-dtest-api


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Simplify voting rules for in-jvm-dtest-api releases

[e . dimitrova]

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 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 interfaces
>>> that allows creating clusters and running tests, much like Python dtests,
>>> just with a potential to run and develop them faster. Previously, anyone
>>> could break API compatibility by committing to only one of the branches
>> and
>>> not updating the other one, which has happened on several occasions and
>> has
>>> went unnoticed, and has added work for people who had to bring changes to
>>> more than one branch. This unified API and tests are particularly useful
>>> for upgrade tests, but are also good for any kind of testing.
>>> 
>>> Since this project was made to simplify contributions to in-jvm dtests,
>>> it'd be great if making changes to this project would actually be simple.
>>> Before that, in order to make changes in in-jvm-dtest API, we required
>>> only +1 from a contributor and a committer could just commit the change.
>>> 
>>> I would say that in order to cut a (minor) release of in-jvm-dtest-api
>> you
>>> should:
>>> 
>>> 1. Get a +1 from a contributor who can review and test your change
>>> 2. Get a +1 from one of committers who are familiar with in-jvm dtests
>> (we
>>> have enough, I just don't want to volunteer anyone)
>>> 
>>> This will guard us from unnecessary changes, and add an extra pair of
>> eyes
>>> for things that influence moore than one branch, but leave us flexible
>>> enough to be able to move forward without conducting a vote.
>>> 
>>> Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
>>> for production purposes, this is a low-risk change in procedure.
>> Moreover,
>>> even if we package in-jvm-dtest-api with some Cassandra release, there
>> will
>>> be an additional vote on the release, where anyone who has concerns about
>>> in-jvm-dtest-api changes can still voice them.
>>> 
>>> Please let me know if you'd like more information about in-jvm-dtest API,
>>> or have comments about this change in procedure.
>>> 
>>> Thank you,
>>> -- Alex
>>> [1] https://github.com/apache/cassandra-in-jvm-dtest-api
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Simplify voting rules for in-jvm-dtest-api releases

[Jon Haddad]

+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].
> >
> > 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 interfaces
> > that allows creating clusters and running tests, much like Python dtests,
> > just with a potential to run and develop them faster. Previously, anyone
> > could break API compatibility by committing to only one of the branches
> and
> > not updating the other one, which has happened on several occasions and
> has
> > went unnoticed, and has added work for people who had to bring changes to
> > more than one branch. This unified API and tests are particularly useful
> > for upgrade tests, but are also good for any kind of testing.
> >
> > Since this project was made to simplify contributions to in-jvm dtests,
> > it'd be great if making changes to this project would actually be simple.
> > Before that, in order to make changes in in-jvm-dtest API, we required
> > only +1 from a contributor and a committer could just commit the change.
> >
> > I would say that in order to cut a (minor) release of in-jvm-dtest-api
> you
> > should:
> >
> > 1. Get a +1 from a contributor who can review and test your change
> > 2. Get a +1 from one of committers who are familiar with in-jvm dtests
> (we
> > have enough, I just don't want to volunteer anyone)
> >
> > This will guard us from unnecessary changes, and add an extra pair of
> eyes
> > for things that influence moore than one branch, but leave us flexible
> > enough to be able to move forward without conducting a vote.
> >
> > Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> > for production purposes, this is a low-risk change in procedure.
> Moreover,
> > even if we package in-jvm-dtest-api with some Cassandra release, there
> will
> > be an additional vote on the release, where anyone who has concerns about
> > in-jvm-dtest-api changes can still voice them.
> >
> > Please let me know if you'd like more information about in-jvm-dtest API,
> > or have comments about this change in procedure.
> >
> > Thank you,
> > -- Alex
> > [1] https://github.com/apache/cassandra-in-jvm-dtest-api
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Simplify voting rules for in-jvm-dtest-api releases

[Aleksey Yeshchenko]

+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
> active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
> that allows creating clusters and running tests, much like Python dtests,
> just with a potential to run and develop them faster. Previously, anyone
> could break API compatibility by committing to only one of the branches and
> not updating the other one, which has happened on several occasions and has
> went unnoticed, and has added work for people who had to bring changes to
> more than one branch. This unified API and tests are particularly useful
> for upgrade tests, but are also good for any kind of testing.
> 
> Since this project was made to simplify contributions to in-jvm dtests,
> it'd be great if making changes to this project would actually be simple.
> Before that, in order to make changes in in-jvm-dtest API, we required
> only +1 from a contributor and a committer could just commit the change.
> 
> I would say that in order to cut a (minor) release of in-jvm-dtest-api you
> should:
> 
> 1. Get a +1 from a contributor who can review and test your change
> 2. Get a +1 from one of committers who are familiar with in-jvm dtests (we
> have enough, I just don't want to volunteer anyone)
> 
> This will guard us from unnecessary changes, and add an extra pair of eyes
> for things that influence moore than one branch, but leave us flexible
> enough to be able to move forward without conducting a vote.
> 
> Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> for production purposes, this is a low-risk change in procedure. Moreover,
> even if we package in-jvm-dtest-api with some Cassandra release, there will
> be an additional vote on the release, where anyone who has concerns about
> in-jvm-dtest-api changes can still voice them.
> 
> Please let me know if you'd like more information about in-jvm-dtest API,
> or have comments about this change in procedure.
> 
> Thank you,
> -- Alex
> [1] https://github.com/apache/cassandra-in-jvm-dtest-api


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Simplify voting rules for in-jvm-dtest-api releases

[Oleksandr Petrov]

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 interfaces
that allows creating clusters and running tests, much like Python dtests,
just with a potential to run and develop them faster. Previously, anyone
could break API compatibility by committing to only one of the branches and
not updating the other one, which has happened on several occasions and has
went unnoticed, and has added work for people who had to bring changes to
more than one branch. This unified API and tests are particularly useful
for upgrade tests, but are also good for any kind of testing.

Since this project was made to simplify contributions to in-jvm dtests,
it'd be great if making changes to this project would actually be simple.
Before that, in order to make changes in in-jvm-dtest API, we required
only +1 from a contributor and a committer could just commit the change.

I would say that in order to cut a (minor) release of in-jvm-dtest-api you
should:

1. Get a +1 from a contributor who can review and test your change
2. Get a +1 from one of committers who are familiar with in-jvm dtests (we
have enough, I just don't want to volunteer anyone)

This will guard us from unnecessary changes, and add an extra pair of eyes
for things that influence moore than one branch, but leave us flexible
enough to be able to move forward without conducting a vote.

Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
for production purposes, this is a low-risk change in procedure. Moreover,
even if we package in-jvm-dtest-api with some Cassandra release, there will
be an additional vote on the release, where anyone who has concerns about
in-jvm-dtest-api changes can still voice them.

Please let me know if you'd like more information about in-jvm-dtest API,
or have comments about this change in procedure.

Thank you,
-- Alex
[1] https://github.com/apache/cassandra-in-jvm-dtest-api