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: Shorter vote for a test side-project of Apache Cassandra

[Greg Stein]

On Thu, Apr 16, 2020 at 8:34 AM Benedict Elliott Smith 
wrote:

> Constructive feedback about incorrect use of language is rarely best done
> on a public forum; this is commonly interpreted as rude, and a form of
> public shaming.  A mild one, admittedly, but one nonetheless.  Since Greg
> has not contributed meaningfully to any discussions that I recall,


I've meaningfully contributed to a few discussions, in my time ...

I chose the public forum dev@cassandra rather than a more narrowly-tailored
recipient list because I have seen the misuse of "PMC" in several
communities. My hope was to share the feedback with the entire Cassandra
community, and hopefully feed that to other communities through overlaps
with Cassandra. It was not intended as "shaming" at all, precisely because
I addressed the community's use of the term, rather than individuals.

Cheers,
-g

Re: Shorter vote for a test side-project of Apache Cassandra

[Benedict Elliott Smith]

Constructive feedback about incorrect use of language is rarely best done on a 
public forum; this is commonly interpreted as rude, and a form of public 
shaming.  A mild one, admittedly, but one nonetheless.  Since Greg has not 
contributed meaningfully to any discussions that I recall, his personal 
interpretation of the sentence is fairly irrelevant, and he furthermore 
mentions it's an intervention based on his own internal pet peeve.  So the 
justification for any perceived rudeness is weak.  I think it is no less 
justified to suggest that such an intervention - even if well intentioned - 
still appears rude and unjustified, and should be reconsidered in future, just 
as Greg suggested the community reconsider its use of language.  

To your point about ambiguity: reading a sentence twice to understand its 
meaning is not the end of the world, and does not imply it is ambiguous, only 
that it was not perfectly crafted.


 
On 16/04/2020, 14:24, "Christopher"  wrote:

Benedict,

Please consider the possibility that Greg was offering constructive
criticism. He used polite wording, such as "Please", and clearly
explained why the misuse of the term could be confusing (specifically,
he explained that it could lead one to misunderstand how many
different PMCs were consulted).

I did not read his post to be a "snipe" against non-native English
speakers, and in fact, disagree with you that the usage was
unambiguous. On initial reading, I was thrown off by the incorrect
usage and had to read a second time to understand. I am a native
English speaker.

From my perspective, Greg offered constructive feedback on the correct
usage, and why it mattered. Please accept it as such and do not assume
negative intent.

On Thu, Apr 16, 2020 at 9:18 AM Benedict Elliott Smith
 wrote:
>
> This is a silly pet peeve.  In this context it was unambiguous what was 
meant, and to snipe at people who do not have English as their first language 
in such an irrelevant context is a waste of everyone's time and energy.
>
> Please update your approach to the community.
>
>
> On 16/04/2020, 10:35, "Greg Stein"  wrote:
>
> Off-topic, but this is a serious pet peeve of mine. Gotta respond. See
> below:
>
> On Thu, Apr 16, 2020 at 3:44 AM Oleksandr Petrov 

> wrote:
> >...
>
> > Before posting here, these options were discussed on Apache 
Cassandra
> > mailing list, and many PMCs, committers, and contributors were in 
favour of
> > simplifying this process, as long as we comply to Apache rules.
> >
>
> "PMC" stands for Project Management Committee. I have seen this usage
> before, where you intend it to mean "PMC **Member**" ... your usage is
> incorrect.
>
> You did not consult "many PMCs". Just the single Cassandra PMC, and 
its
> *Members*.
>
> Please update the terminology used by the community.
> -g
>
>
>
>
> -
> To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org
> For additional commands, e-mail: legal-discuss-h...@apache.org
>

-
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: Shorter vote for a test side-project of Apache Cassandra

[Christopher]

Benedict,

Please consider the possibility that Greg was offering constructive
criticism. He used polite wording, such as "Please", and clearly
explained why the misuse of the term could be confusing (specifically,
he explained that it could lead one to misunderstand how many
different PMCs were consulted).

I did not read his post to be a "snipe" against non-native English
speakers, and in fact, disagree with you that the usage was
unambiguous. On initial reading, I was thrown off by the incorrect
usage and had to read a second time to understand. I am a native
English speaker.

>From my perspective, Greg offered constructive feedback on the correct
usage, and why it mattered. Please accept it as such and do not assume
negative intent.

On Thu, Apr 16, 2020 at 9:18 AM Benedict Elliott Smith
 wrote:
>
> This is a silly pet peeve.  In this context it was unambiguous what was 
> meant, and to snipe at people who do not have English as their first language 
> in such an irrelevant context is a waste of everyone's time and energy.
>
> Please update your approach to the community.
>
>
> On 16/04/2020, 10:35, "Greg Stein"  wrote:
>
> Off-topic, but this is a serious pet peeve of mine. Gotta respond. See
> below:
>
> On Thu, Apr 16, 2020 at 3:44 AM Oleksandr Petrov 
> 
> wrote:
> >...
>
> > Before posting here, these options were discussed on Apache Cassandra
> > mailing list, and many PMCs, committers, and contributors were in 
> favour of
> > simplifying this process, as long as we comply to Apache rules.
> >
>
> "PMC" stands for Project Management Committee. I have seen this usage
> before, where you intend it to mean "PMC **Member**" ... your usage is
> incorrect.
>
> You did not consult "many PMCs". Just the single Cassandra PMC, and its
> *Members*.
>
> Please update the terminology used by the community.
> -g
>
>
>
>
> -
> To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org
> For additional commands, e-mail: legal-discuss-h...@apache.org
>

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

Re: Shorter vote for a test side-project of Apache Cassandra

[Benedict Elliott Smith]

This is a silly pet peeve.  In this context it was unambiguous what was meant, 
and to snipe at people who do not have English as their first language in such 
an irrelevant context is a waste of everyone's time and energy.

Please update your approach to the community.


On 16/04/2020, 10:35, "Greg Stein"  wrote:

Off-topic, but this is a serious pet peeve of mine. Gotta respond. See
below:

On Thu, Apr 16, 2020 at 3:44 AM Oleksandr Petrov 

wrote:
>...

> Before posting here, these options were discussed on Apache Cassandra
> mailing list, and many PMCs, committers, and contributors were in favour 
of
> simplifying this process, as long as we comply to Apache rules.
>

"PMC" stands for Project Management Committee. I have seen this usage
before, where you intend it to mean "PMC **Member**" ... your usage is
incorrect.

You did not consult "many PMCs". Just the single Cassandra PMC, and its
*Members*.

Please update the terminology used by the community.
-g




-
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

[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: Shorter vote for a test side-project of Apache Cassandra

[Greg Stein]

Off-topic, but this is a serious pet peeve of mine. Gotta respond. See
below:

On Thu, Apr 16, 2020 at 3:44 AM Oleksandr Petrov 
wrote:
>...

> Before posting here, these options were discussed on Apache Cassandra
> mailing list, and many PMCs, committers, and contributors were in favour of
> simplifying this process, as long as we comply to Apache rules.
>

"PMC" stands for Project Management Committee. I have seen this usage
before, where you intend it to mean "PMC **Member**" ... your usage is
incorrect.

You did not consult "many PMCs". Just the single Cassandra PMC, and its
*Members*.

Please update the terminology used by the community.
-g

Re: Opinions about removal of deprecated code for upcoming 4.0

[Stefan Miklosovic]

That sounds all good to me. I ll check if there are some leftovers
from 2.x as Jeff is describing.

On Thu, 16 Apr 2020 at 10:24, Benjamin Lerer
 wrote:
>
> A lot of those methods if I am not wrong have been marked as deprecated in
> 4.0. So they should not be removed yet, as Jeff mentioned.
>
> The problem I see is that those deprecations have not been mentioned in the
> deprecation section of the NEWS.txt. As they are MBeans methods,  unless
> people have checked the interface they might not realize that those methods
> have been deprecated and it might come as a surprise when we remove them.
>
> So, we should not remove them but we should mark them as deprecated in the
> NEWS.txt to.
>
>
> On Thu, Apr 16, 2020 at 12:41 AM Jeff Jirsa  wrote:
>
> > I havent reviewed that code, but it's not surprising there would be
> > deprecated annotations in a major release. We *SHOULD* be deprecating
> > things that worked in 3.0/3.11 in 4.0, and removing them in a future
> > verison. We should only be removing them in 4.0 if they were originally
> > supported in 2.1/2.2, deprecated in 3.0/3.11, and then become eligible for
> > removal in 4.0+
> >
> > So of the 30, how many of them are newly deprecated (removal in the future)
> > vs already deprecated (eligible for removal now)?
> >
> >
> >
> > On Wed, Apr 15, 2020 at 3:06 PM Stefan Miklosovic <
> > stefan.mikloso...@instaclustr.com> wrote:
> >
> > > Hi,
> > >
> > > I was going over StorageServiceMBean and I was quite surprised how
> > > many deprecated methods there are. Only in that interface itself there
> > > are 30 deprecation annotations. What is the general feeling about this
> > > as 4.0 is getting more real? One would say that 4.0 is "breaking
> > > change" release so I guess that deleting deprecated methods at least
> > > in these interfaces is worth doing?
> > >
> > > Regards
> > >
> > > -
> > > 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: Opinions about removal of deprecated code for upcoming 4.0

[Benjamin Lerer]

A lot of those methods if I am not wrong have been marked as deprecated in
4.0. So they should not be removed yet, as Jeff mentioned.

The problem I see is that those deprecations have not been mentioned in the
deprecation section of the NEWS.txt. As they are MBeans methods,  unless
people have checked the interface they might not realize that those methods
have been deprecated and it might come as a surprise when we remove them.

So, we should not remove them but we should mark them as deprecated in the
NEWS.txt to.


On Thu, Apr 16, 2020 at 12:41 AM Jeff Jirsa  wrote:

> I havent reviewed that code, but it's not surprising there would be
> deprecated annotations in a major release. We *SHOULD* be deprecating
> things that worked in 3.0/3.11 in 4.0, and removing them in a future
> verison. We should only be removing them in 4.0 if they were originally
> supported in 2.1/2.2, deprecated in 3.0/3.11, and then become eligible for
> removal in 4.0+
>
> So of the 30, how many of them are newly deprecated (removal in the future)
> vs already deprecated (eligible for removal now)?
>
>
>
> On Wed, Apr 15, 2020 at 3:06 PM Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
> > Hi,
> >
> > I was going over StorageServiceMBean and I was quite surprised how
> > many deprecated methods there are. Only in that interface itself there
> > are 30 deprecation annotations. What is the general feeling about this
> > as 4.0 is getting more real? One would say that 4.0 is "breaking
> > change" release so I guess that deleting deprecated methods at least
> > in these interfaces is worth doing?
> >
> > Regards
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: server side describe

[Benjamin Lerer]

Now that there is an agreement on having this patch on 4.0. I would like to
see it done as soon as possible. It would minimize the risks by giving us
more testing time. It will also give the driver developers a chance to use
it and provide feedback if they hit some issues.

Robert rebased his patch yesterday and I started to review it. If somebody
else want to give another look to the patch, I am 100% for it.




On Wed, Apr 15, 2020 at 7:48 PM Jon Haddad  wrote:

> I don't think we need to vote on this.  A few folks have expressed (very
> justified) concern, but nobody has gone nuclear.
>
> I intended on cleaning up the patch and getting it ready for another
> review, but haven't had it in my brain and have been busy with other
> things.  I don't claim exclusive rights to the clean up patch, if someone
> was motivated to do it I'd be 100% fine with it. :)
>
>
>
>
> On Wed, Apr 15, 2020 at 10:15 AM sankalp kohli 
> wrote:
>
> > What are the next steps? Do we hold a vote as I see few initial emails
> > which dont seem to agree and have not replied based on future
> discussions.
> >
> > On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi  wrote:
> >
> > > +1 let's keep moving forward.
> > >
> > > Dinesh
> > >
> > > > On Apr 9, 2020, at 4:07 PM, Nate McCall  wrote:
> > > >
> > > > Ok cool. It sounds like we are moving this towards a consensus? (at
> > least
> > > > agreeing to disagree and moving forward).
> > > >
> > > > I very much the different inputs on this thread - thanks for a
> largely
> > > > healthy discussion folks.
> > > >
> > > > On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink 
> > > wrote:
> > > >
> > > >> I'd be in favor of going with the newer DESCRIBE option. The
> original
> > > patch
> > > >> was mostly focused on just getting the CQL correct and used virtual
> > > tables
> > > >> because its what the initial feedback was to do. Robert added a lot
> of
> > > >> functionality on top of what was there which is what people were
> > > starting
> > > >> to ask for. I am in favor of just going off of his patch and moving
> > > >> forward. I initially heard post 4.0 so I know I haven't been focused
> > on
> > > it
> > > >> but if theres desire to put it in 4.0 I am +1 on it and would like
> to
> > > see
> > > >> just going off of the Robert's latest patch.
> > > >>
> > > >> Chris
> > > >>
> > > >> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <
> > > benjamin.le...@datastax.com
> > > >>>
> > > >> wrote:
> > > >>
> > > >>> Thanks for your answer Alex.
> > > >>>
> > > >>> Some of the things we
> > >  have explicitly (as a community) agreed to commit are still in
> > > >> progress,
> > >  including several client protocol changes. And, to my
> understanding,
> > > if
> > >  those are committed, it'll be what community has agreed upon.
> > > 
> > > >>>
> > > >>> If the understanding of the community was that this patch was
> > expected
> > > to
> > > >>> go in 4.0 then it makes sense to commit it there.
> > > >>>
> > > >>>
> > >  If the discussion is about whether or not to include _some_
> version
> > of
> > > >>> the
> > >  patch, I think including it makes sense, especially given the
> patch
> > > was
> > >  there for a while and was not committed for non-technical reasons.
> > If
> > > >>> we're
> > >  trying to decide _which_ patch to commit, I'd personally focus on
> > the
> > >  original patch (to foster recognition), get it reviewed, and pick
> > any
> > >  changes that make it better from the follow-up one (to foster
> > >  collaboration).
> > > 
> > > >>>
> > > >>> I am fine going through both patches and figuring out a way to
> merge
> > > them
> > > >>> into one if Jon or somebody else is willing to review the output of
> > > that
> > > >>> merge
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
> > > >>> bened...@apache.org>
> > > >>> wrote:
> > > >>>
> > >  +1 all of this
> > > 
> > >  On 09/04/2020, 10:23, "Oleksandr Petrov" <
> > oleksandr.pet...@gmail.com
> > > >
> > >  wrote:
> > > 
> > > > My understanding is that a majority of people ended up in favor
> > > >> of
> > > a DESCRIBE approach. Robert made a patch for that approach
> > > >> (according
> > >  to
> > > his comment it was discussed with Chris beforehand).
> > > 
> > > This sounds like just a switch of API (in other words, you use
> > the
> > > >>> same
> > > string generation, but return it via different means). From the
> > >  (little)
> > > time I've spent looking at the patch, I remember that there
> > wasn't
> > > >>> much
> > > common code between the two (sorry if I'm remembering it
> wrong).
> > > 
> > > If the discussion is about whether or not to include _some_
> > version
> > > >>> of
> > >  the
> > > patch, I think including it makes sense, especially given the
> > patch
> > > >>> was
> > > there for a while