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

2020-04-16 Thread 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

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

2020-04-16 Thread J. D. Jordan
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

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

2020-04-16 Thread 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

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

2020-04-16 Thread 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'

Re: server side describe

2020-04-16 Thread Dinesh Joshi
I'll volunteer. Dinesh > On Apr 16, 2020, at 12:47 AM, Benjamin Lerer > wrote: > > 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 developer

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

2020-04-16 Thread 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

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

2020-04-16 Thread 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 person

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

2020-04-16 Thread 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 co

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

2020-04-16 Thread 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, "Gr

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

2020-04-16 Thread 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 e

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

2020-04-16 Thread 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 > simpl

Re: Opinions about removal of deprecated code for upcoming 4.0

2020-04-16 Thread 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. > > Th

Re: Opinions about removal of deprecated code for upcoming 4.0

2020-04-16 Thread 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 che

Re: server side describe

2020-04-16 Thread 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