Re: Should we change 4.1 to G1 and offheap_objects ?

[Michael Shuler]

On 1/13/23 05:50, Mick Semb Wever wrote:
Thanks for the support Brad, you're definitely not alone. Alas the 
project works in a consensus model, i.e. off the objections made - which 
have been all sound. A good compromise has been offered that I will move 
forward on, and I'll also update the commented out G1 settings in 4.1.1 
to match those becoming the default in trunk.


+1 to G1 default in trunk and a recommendation in 4.1.1 NEWS.txt. I 
agree with Aleksey and others, trunk is the right place to change defaults.


Kind regards,
Michael

Re: [VOTE] CEP-30 ANN Vector Search

[Michael Shuler]

+1, this is cool.

On 5/25/23 10:45, Jonathan Ellis wrote:

Let's make this official.

CEP: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes 


POC that demonstrates all the big rocks, including distributed queries: 
https://github.com/datastax/cassandra/tree/cep-vsearch 



--
Jonathan Ellis
co-founder, http://www.datastax.com 
@spyced

Re: [VOTE] CEP-8 Datastax Drivers Donation

[Michael Shuler]

+1

On 6/13/23 09:14, Jeremy Hanna wrote:

Calling for a vote on CEP-8 [1].

To clarify the intent, as Benjamin said in the discussion thread [2], 
the goal of this vote is simply to ensure that the community is in favor 
of the donation. Nothing more.
The plan is to introduce the drivers, one by one. Each driver donation 
will need to be accepted first by the PMC members, as it is the case for 
any donation. Therefore the PMC should have full control on the pace at 
which new drivers are accepted.


If this vote passes, we can start this process for the Java driver under 
the direction of the PMC.


Jeremy

1. 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation 
2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp 

Re: [VOTE] Accept java-driver

[Michael Shuler]

+1

(late to the vote, but wanted to publicly note my support)

Kind regards,
Michael

On 10/2/23 23:52, Mick Semb Wever wrote:

The donation of the java-driver is ready for its IP Clearance vote.
https://incubator.apache.org/ip-clearance/cassandra-java-driver.html 



The SGA has been sent to the ASF.  This does not require acknowledgement 
before the vote.


Once the vote passes, and the SGA has been filed by the ASF Secretary, 
we will request ASF Infra to move the datastax/java-driver as-is to 
apache/java-driver


This means all branches and tags, with all their history, will be kept.  
A cleaning effort has already cleaned up anything deemed not needed.


Background for the donation is found in CEP-8: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation 


PMC members, please take note of (and check) the IP Clearance 
requirements when voting.


The vote will be open for 72 hours (or longer). Votes by PMC members are 
considered binding. A vote passes if there are at least three binding 
+1s and no -1's.


regards,
Mick

Re: Plans for switching to logback 1.3.x/1.4.x?

[Michael Shuler]

Although I have not searched jira, I'd bet plans could use help, if they 
exist. I recall the jog4j -> logback transition, and it was not super 
complex, and reading through the logback docs, some defaults were 
updated and the project gained a nice feature bump. I would think a 
minor version rev of logback should be straightforward. I would suggest 
dropping in a new version, fix what needs fixing (if anything, read the 
upstream changelog), and if you get it to work, push a branch for a pull 
request. License updates, etc can get updated with a reviewer, if you 
miss any details. Sounds like a good contribution :)


Kind regards,
Michael

On 1/15/24 03:22, Alexander Shusherov wrote:

Hello Cassandra Developers!

Recently we explored the behavior of logback in Cassandra 4.1 (there
was a hypothesis about a bug in SizeAndTimeBasedRollingPolicy, however
it was not confirmed).

As part of this activity it was noticed that there exist some logback
issues that were fixed in 1.3.x/1.4.x, but still present in 1.2.x
(e.g. https://jira.qos.ch/browse/LOGBACK-1361)

At this moment Cassandra 4.1 and 5.0 still use logback 1.2.x and I
haven't found any tickets addressing switching to logback 1.3.x/1.4.x.
Could you please share if there are any plans for switching to logback
1.3.x/1.4.x?


Regards,
   Alexander

Re: CI's working, and repeatable !!

[Michael Shuler]

💯! Amazing work - thanks so much for posting the details, Mick, and Josh
is right on. Kinda bummed I haven't been following C* CI dev, being more on
the ops side lately. Posting this up has me intrigued, so I may just have
to go poke around some and scratch an itch :)

Warm regards,
Michael


On Sun, Apr 28, 2024 at 9:08 PM Josh McKenzie  wrote:

> A huge amount of work and time went into this and it's going to have a big
> impact on the project. I want to offer a heartfelt thanks to all involved
> for the focus and energy that went into this!
>
> As the author of the system David lovingly dubbed "JoshCI" (/sigh), I
> definitely want to see us all move to converge as much as possible on the
> CI code we're running. While I remain convinced something like
> CASSANDRA-18731 is vital for hygiene in the long run (unit testing our CI,
> declaratively defining atoms of build logic independently from flow), I
> also think there'd be significant value in more of us moving towards using
> the JenkinsFile where at all possible.
>
> Seriously - thanks again for all this work everyone. CI on Cassandra is a
> Big Data Problem, and not an easy one.
>
> On Sun, Apr 28, 2024, at 10:22 AM, Mick Semb Wever wrote:
>
>
> Good news.
>
> CI on 5.0 and trunk is working again, after an unexpected 6 weeks
> hiatus (and a string of general problems since last year).
> This includes pre-commit for 5.0 and trunk working again.
>
>
> More info…
>
> From 5.0 we now have in-tree a Jenkinsfile that only relies on the in-tree
> scripts – it does not depend upon cassandra-builds and all the individual
> dsl created stage jobs. This aligns how pre-commit and post-commit works.
> More importantly, it makes our CI repeatable regardless of the fork/branch
> of the code, or the jenkins installation.
>
> For 5.0+ pre-commit use the Cassandra-devbranch-5 and make sure your patch
> is after sha 3c85def
> The jenkinsfile now comes with pre-defined profiles, it's recommended to
> use "skinny" until you need the final "pre-commit".  You can also use the
> custom profile with a regexp when you need just specific test types.
> See https://ci-cassandra.apache.org/job/Cassandra-devbranch-5/build
>
> For pre-commit on older branches, you now use Cassandra-devbranch-before-5
>
> For both pre- and post-commit builds, each build now creates two new
> sharable artefacts: ci_summary.html and results_details.tar.xz
> These are based on what apple contributors were sharing from builds from
> their internal CI system.  The format and contents of these files is
> expected to evolve.
>
> Each build now archives its results and logs all under one location in
> nightlies.
>
> e.g. https://nightlies.apache.org/cassandra/Cassandra-5.0/227/
>
>
>
> The post-commit pipeline profile remains *very* heavy, at 130k+ tests.
> These were previously ramped up to include everything in their pipelines,
> given everything that's happening in both branches.   So they take time and
> saturate everything they touch.  We need to re-evaluate what we need to be
> testing to alleviate this.  There'll also be a new pattern of timeouts and
> infra/script -related flakies, as happens whenever there's such a
> significant change, all the patience and help possible is appreciated!
>
>
>
> Now that the jenkinsfile can now be used on any jenkins server for any
> fork/branch, the next work-in-progress is CASSANDRA-18145, to be able to
> run the full pipeline with a single command line (given a k8s context
> (~/.kube/config)).
>
> We already have most of this working – it's possible to make a clone
> ci-cassandra.apache.org on k8s using this wip helm chart:
> https://github.com/thelastpickle/Cassius
> And we are already using this on an auto-scaling gke k8s cluster – you
> might have seen me posting the ci_summary.html and results_details.tar.xz
> files to tickets for pre-commit CI instead of using the ci-cassandra.a.o or
> circleci pre-commit liks.  Already, we have a full pipeline time down to
> two hours and less than a third of the cost of CircleCI, and there's lhf to
> further improve this.  For serious pre-commit testing we are still missing
> and need repeatable test runs, ref CASSANDRA-18942.  On all this I'd like
> to give a special shout out to Aleksandr Volochnev who was instrumental in
> the final (and helm based) work of 18145 which was needed to be able to
> test its prerequisite ticket CASSANDRA-18594 – ci-cassandra.a.o would not
> be running again today without his recent time spent on it.
>
> On a separate note, this new jenkinsfile is designed in preparation for
> CASSANDRA-18731 ('Add declarative root CI structure'), to make it easier to
> define profiles, tests, and their infrastructural requirements.
>
>
> To the community…
>   We are now in a place where we are looking and requesting further
> donations of servers to the ci-cassandra.apache.org jenkins cluster.  We
> can now also use cloud/instance credits to host auto-scaling k8s-based
> ci-cassandra.a.o clones that would b

Re: [VOTE] CEP-24 Password validation / generation

[Michael Shuler]

+1

Michael

On 6/17/24 04:32, Štefan Miklošovič wrote:

Hi everyone,

I would like to start the voting for CEP-24 as all feedback in the 
discussion threads seem to be addressed.


Proposal: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146 
JIRA under which it will be delivered: 
https://issues.apache.org/jira/browse/CASSANDRA-17457 

Draft implementation: 
https://github.com/instaclustr/cassandra/tree/CEP-24-simplified 



Discuss threads:

https://lists.apache.org/thread/1hs27lx2pw9lmp7rw499vn0m7vl2bgt1 

https://lists.apache.org/thread/1hs27lx2pw9lmp7rw499vn0m7vl2bgt1 



The reason there are two threads is that I replied to the first one 
after that CEP was dormant for a very long time and it just created new 
thread for that, most probably an issue with my e-mail client ...


The vote will be open for 72 hours (longer if needed). A vote passes if 
there are at least 3 binding +1s and no binding vetoes.


Thanks,

Stefan Miklosovic

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Michael Shuler]

+1

Kind regards,
Michael

On 6/25/24 12:29, Mick Semb Wever wrote:


Please vote on the acceptance of the GoCQL driver and its IP Clearance:
https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html 



All consent from original authors of the donation, and tracking of 
collected CLAs, is found in:
  - https://github.com/gocql/gocql/issues/1751 

  - 
https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485 

These do not require acknowledgement before thevote.

The code is prepared for donation at https://github.com/gocql/gocql 



Once thisvotepasses we will request ASF Infra to move the gocql/gocql 
as-is to apache/cassandra-gocql-driver  . The master branch and tags, 
with all their history, will be kept.  Because consent and CLAs were not 
received from all original authors the source files keep additional 
reference to their earlier copyright authors and license.


This will become part of the Drivers subproject, ref CEP-8: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation 


PMC members, please check carefully the IP Clearance requirements 
beforevoting.


Thevotewill be open for 72 hours (or longer).Votesby PMC members are 
considered binding. Avotepasses if there are at least three binding +1s 
and no -1's.


regards,
Mick

Re: Hi-Rez of Apache Cassandra logo??

[Michael Shuler]

Nice, thanks!

I went ahead and committed the files to SVN. I hope that was OK, Scott :)

https://svn.apache.org/repos/asf/cassandra/logo/


r1831825 | mshuler | 2018-05-18 00:53:54 -0500 (Fri, 18 May 2018) | 5 lines

Add Apache Cassandra logos provided by Scott Andreas

Since Scott uploaded them to a temporary location, let's add them here.
https://lists.apache.org/thread.html/981adf13e8d483d9de41bf5ab30328aafe8544da6b36036e64744046@%3Cdev.cassandra.apache.org%3E

--
Kind regards,
Michael

On 05/18/2018 12:23 AM, Scott Andreas wrote:

Hi Nate,

Here are vectorized versions of the logo reading "Apache Cassandra":
– http://paradoxica.net/img/cassandra/apache-cassandra.pdf
– http://paradoxica.net/img/cassandra/apache-cassandra.eps

This is not an official graphic, but for the sake of provenance:

– The image is sourced from: 
https://svn.apache.org/repos/asf/cassandra/logo/cassandra.svg
– I've replaced "cassandra" with "apache cassandra" set in Cronos Pro Bold 
Italic (which I believe is the original typeface).
– And exported as a vector PDF and EPS, which should be scalable to any size 
you need.

The above URLs are not permanent; since the list allows max-1MB attachments, 
I've uploaded them to a temporary location.

Happy to make changes or to share in another format if that works better.

– Scott


From: Nate McCall 
Sent: Thursday, May 17, 2018 9:45:18 PM
To: dev
Subject: Hi-Rez of Apache Cassandra logo??

I'm looking for a hi-rez source of 'the eye' with "Apache Cassandra"
(that last part is important) basically what we have on the website.
I'm gonna run off some laptop stickers on sticker mule.

Provided I can track that down, you can have one if you show up here:
https://www.meetup.com/Apache-Cassandra-Bay-Area/events/250901453/

Once I get this squared away, i'll create a template and share it
somewhere (maybe check it in?) so anyone can print "Apache Cassandra"
stuff provided they follow the merchandising guidelines:
https://www.apache.org/foundation/marks/merchandise

-
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




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

Re: 3.11.3

[Michael Shuler]

+1 for all the active branches. It will also be a good chance to review 
the release doc addition Mick so graciously wrote up.

https://github.com/apache/cassandra/pull/230

--
Michael

On 06/06/2018 07:30 AM, Jason Brown wrote:

wrt releasing 3.11, +1 to this ... and additionally, 3.0 and 2.2.

I'd propose we cut early next week (Monday) and anything that can get
reviewed/committed from Kurt's list would be great.

On Wed, Jun 6, 2018 at 5:22 AM, kurt greaves  wrote:


We probably need to release 3.11.3 at some point soon because there's some
pretty major bug fixes in there and interest has been expressed multiple
times now for a release.

Currently the only tickets marked for 3.11.3 that aren't complete are:
https://issues.apache.org/jira/browse/CASSANDRA-14355 - No work has
started
on this yet.
https://issues.apache.org/jira/browse/CASSANDRA-13929 - A lot of work has
been done here... just need a final review

However we've got quite a few tickets with patches that should probably be
considered - can't say all are necessary to get into 3.11.3 but seeing as
they all have patch available and have been around :
for a while they are worth considering for anyone who could kindly review:
https://issues.apache.org/jira/browse/CASSANDRA-14242 - Inconsistent
indexing on static columns :(. needs review
https://issues.apache.org/jira/browse/CASSANDRA-14415 - performance
regression fix for DISTINCT
https://issues.apache.org/jira/browse/CASSANDRA-14204 - Straightforward
fix
for nodetool garbagecollect
https://issues.apache.org/jira/browse/CASSANDRA-14167 - Pretty much ready
for commit - has been given +1 by Sylvain
https://issues.apache.org/jira/browse/CASSANDRA-14099 - Needs only a unit
test
https://issues.apache.org/jira/browse/CASSANDRA-14085 - performance fix,
small patch needs review
https://issues.apache.org/jira/browse/CASSANDRA-13935 - Simple fix to CQL
output for indexes when dumping schema
https://issues.apache.org/jira/browse/CASSANDRA-13917 - Needs review, fix
for compact storage inserts.
https://issues.apache.org/jira/browse/CASSANDRA-13843 - Needs review.
Small
debian packaging fix for heapdump location.
https://issues.apache.org/jira/browse/CASSANDRA-13834 - Needs an
"official"
reviewer and probably a test.
https://issues.apache.org/jira/browse/CASSANDRA-13618 - Can likely be
committed. Jeff has already done all the work for it just need to verify
tests.
https://issues.apache.org/jira/browse/CASSANDRA-11479 - Waiting for review
for quite a long time.. unit test fix but seems to include changes to the
server

Handy JQL:
project = CASSANDRA AND ((fixVersion = 3.11.x and status = "Patch
Available" ) OR (fixVersion = 3.11.3 AND status != Resolved)) and Type =
Bug






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

Re: Small improvement on website

[Michael Shuler]

On 06/13/2018 02:50 PM, Roy Lenferink wrote:

Hi folks,

Yesterday I got a message through the Apache Software Foundation Facebook
page containing a small point of feedback.
It's about a missing space after a period, on the index.html page of the
website: "mission-critical data.Cassandra's..."


Thanks! Fixed.


If necessary, I am able to create a JIRA for this ;)


Nah :)

--
Kind regards,
Michael

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

[VOTE] Release Apache Cassandra 2.2.13

[Michael Shuler]

I propose the following artifacts for release as 2.2.13.

sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
Git: 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.13-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1159/org/apache/cassandra/apache-cassandra/2.2.13/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1159/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler/


The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt) 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
[2]: (NEWS.txt) 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.13-tentative


--
Michael

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

[VOTE] Release Apache Cassandra 3.0.17

[Michael Shuler]

I propose the following artifacts for release as 3.0.17.

sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2
Git: 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.17-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1160/org/apache/cassandra/apache-cassandra/3.0.17/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1160/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler/


The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt) 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
[2]: (NEWS.txt) 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.17-tentative


--
Michael

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

[VOTE] Release Apache Cassandra 3.11.3

[Michael Shuler]

I propose the following artifacts for release as 3.11.3.

sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd
Git: 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.3-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1161/org/apache/cassandra/apache-cassandra/3.11.3/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1161/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler/


The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt) 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
[2]: (NEWS.txt) 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.3-tentative


--
Michael

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

[VOTE FAILED] Release Apache Cassandra 3.11.3

[Michael Shuler]

Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252
from the cassandra-3.0/3.11 branches, I'm also a -1 for release.

Kind regards,
Michael

On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote:
> -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
> effect on streaming is verified.  The concern is that the snitch change
> could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
> this.
> 
> 
> On 3 July 2018 at 04:02, Nate McCall  wrote:
> 
>> +1
>>
>> On Tue, Jul 3, 2018 at 8:11 AM, Michael Shuler 
>> wrote:
>>> I propose the following artifacts for release as 3.11.3.
>>>
>>> sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd
>>> Git:
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> shortlog;h=refs/tags/3.11.3-tentative
>>> Artifacts:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1161/org/apache/cassandra/apache-cassandra/3.11.3/
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1161/
>>>
>>> The Debian and RPM packages are available here:
>>> http://people.apache.org/~mshuler/
>>>
>>> The vote will be open for 72 hours (longer if needed).
>>>
>>> [1]: (CHANGES.txt)
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
>>> [2]: (NEWS.txt)
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> blob_plain;f=NEWS.txt;hb=refs/tags/3.11.3-tentative
>>>
>>> --
>>> Michael

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

[VOTE FAILED] Release Apache Cassandra 3.0.17

[Michael Shuler]

Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252
from the cassandra-3.0/3.11 branches, I'm also a -1 for release.

Kind regards,
Michael

On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote:
> -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
> effect on streaming is verified.  The concern is that the snitch change
> could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
> this.
> 
> 
> On 3 July 2018 at 04:02, Nate McCall  wrote:
> 
>> +1
>>
>> On Tue, Jul 3, 2018 at 8:10 AM, Michael Shuler 
>> wrote:
>>> I propose the following artifacts for release as 3.0.17.
>>>
>>> sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2
>>> Git:
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> shortlog;h=refs/tags/3.0.17-tentative
>>> Artifacts:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1160/org/apache/cassandra/apache-cassandra/3.0.17/
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1160/
>>>
>>> The Debian and RPM packages are available here:
>>> http://people.apache.org/~mshuler/
>>>
>>> The vote will be open for 72 hours (longer if needed).
>>>
>>> [1]: (CHANGES.txt)
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
>>> [2]: (NEWS.txt)
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> blob_plain;f=NEWS.txt;hb=refs/tags/3.0.17-tentative
>>>
>>> --
>>> Michael


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

[VOTE FAILED - VETO] Release Apache Cassandra 2.2.13

[Michael Shuler]

This sha fails to build JDK7. If built on JDK8, which is what I did
erroneously, the release fails with JDK7 runtime in AntiCompactionTest.

In going through a round of test builds, it appears we have a problem
with the CASSANDRA-14423 commit calling a JDK8-only String.join().

I'm vetoing this release.

Kind regards,
Michael

On 07/04/2018 06:18 AM, kurt greaves wrote:
> Actually taking back my +1, seems like we've got a fair amount of dtests
> (at least 7) failing consistently on 2.2, and another one that's very flaky.
> Last completed runs are here:
> https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-2.2-dtest/116/testReport/
> https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-2.2-dtest-large/68/testReport/
> 
> Seeing as we committed to green tests at some point we should probably look
> into these.
> 
> Also yay for the test results analyzer not working.
> 
> On 4 July 2018 at 09:06, Stefan Podkowinski  wrote:
> 
>> +1
>>
>> On 02.07.2018 22:10, Michael Shuler wrote:
>>> I propose the following artifacts for release as 2.2.13.
>>>
>>> sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
>>> Git:
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> shortlog;h=refs/tags/2.2.13-tentative
>>>
>>> Artifacts:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1159/org/apache/cassandra/apache-cassandra/2.2.13/
>>>
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1159/
>>>
>>> The Debian and RPM packages are available here:
>>> http://people.apache.org/~mshuler/
>>>
>>> The vote will be open for 72 hours (longer if needed).
>>>
>>> [1]: (CHANGES.txt)
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
>>>
>>> [2]: (NEWS.txt)
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> blob_plain;f=NEWS.txt;hb=refs/tags/2.2.13-tentative
>>>
>>>
>>
>> -
>> 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: [VOTE] Branching Change for 4.0 Freeze

[Michael Shuler]

+0

There are pros and cons. I do hope the pros work out and the cons aren't
too impactful. I thought about just abstaining, but figured a "meh,
whatever" vote was at least worth voicing.

Michael

On 07/11/2018 04:46 PM, sankalp kohli wrote:
> Hi,
> As discussed in the thread[1], we are proposing that we will not branch
> on 1st September but will only allow following merges into trunk.
> 
> a. Bug and Perf fixes to 4.0.
> b. Critical bugs in any version of C*.
> c. Testing changes to help test 4.0
> 
> If someone has a change which does not fall under these three, we can
> always discuss it and have an exception.
> 
> Vote will be open for 72 hours.
> 
> Thanks,
> Sankalp
> 
> [1]
> https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E
> 


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

Re: reroll the builds?

[Michael Shuler]

On 07/16/2018 11:27 PM, Jason Brown wrote:
> Hey all,
> 
> The recent builds were -1'd, but it appears the issues have been resolved
> (2.2.13 with CASSANDRA-14423, and 3.0.17 / 3.11.3 reverting
> CASSANDRA-14252). Can we go ahead and reroll now?

Could someone run through the tests on 2.2, 3.0, 3.11 branches and link
them?  Thanks!

Michael

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

[VOTE] Release Apache Cassandra 3.11.3 (Take 2)

[Michael Shuler]

I propose the following artifacts for release as 3.11.3.

sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.3-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1164/org/apache/cassandra/apache-cassandra/3.11.3/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1164/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
[2]: NEWS.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative

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

[VOTE] Release Apache Cassandra 3.0.17 (Take 2)

[Michael Shuler]

I propose the following artifacts for release as 3.0.17.

sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.17-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1165/org/apache/cassandra/apache-cassandra/3.0.17/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1165/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
[2]: NEWS.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative

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

[VOTE] Release Apache Cassandra 2.2.13

[Michael Shuler]

I propose the following artifacts for release as 2.2.13.

sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.13-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1167/org/apache/cassandra/apache-cassandra/2.2.13/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1167/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
[2]: NEWS.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative

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

Re: [VOTE] Release Apache Cassandra 2.2.13

[Michael Shuler]

With 9 binding +1, 2 non-binding +1, and no other votes, this vote
passed. I'll get the artifacts uploaded as soon as I can.

-- 
Warm regards,
Michael

On 07/25/2018 12:17 AM, Michael Shuler wrote:
> I propose the following artifacts for release as 2.2.13.
> 
> sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.13-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1167/org/apache/cassandra/apache-cassandra/2.2.13/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1167/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
> [2]: NEWS.txt:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
> 


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

Re: [VOTE] Release Apache Cassandra 3.0.17 (Take 2)

[Michael Shuler]

With 9 binding +1, 3 non-binding +1, and no other votes, this vote
passed. I'll get the artifacts uploaded as soon as I can.

-- 
Warm regards,
Michael


On 07/25/2018 12:17 AM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.0.17.
> 
> sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.17-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1165/org/apache/cassandra/apache-cassandra/3.0.17/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1165/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
> [2]: NEWS.txt:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
> 


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

Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

[Michael Shuler]

With 9 binding +1, 4 non-binding +1, and no other votes, this vote
passed. I'll get the artifacts uploaded as soon as I can.

-- 
Warm regards,
Michael


On 07/25/2018 12:16 AM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.11.3.
> 
> sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.3-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1164/org/apache/cassandra/apache-cassandra/3.11.3/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1164/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
> [2]: NEWS.txt:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
> 


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

[RELEASE] Apache Cassandra 2.2.13 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.2.13.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.2 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: CHANGES.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.2.13
[2]: NEWS.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-2.2.13
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

[RELEASE] Apache Cassandra 3.0.17 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.0.17.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.0 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: CHANGES.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.17
[2]: NEWS.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.17
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

[RELEASE] Apache Cassandra 3.11.3 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.11.3.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.11 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: CHANGES.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.11.3
[2]: NEWS.txt:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.11.3
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

Re: Side Car New Repo vs not

[Michael Shuler]

+1 for a separate repository.

Michael

On 08/23/2018 07:30 PM, Murukesh Mohanan wrote:
> FWIW, I think it's possible to merge in a separate repository into a
> subdirectory while keeping git history, but I don't know if the other way
> will be possible if commits span other parts of the repo as well\* (which
> will likely happen sooner or later). So a separate repo is a choice we can
> backtrack from if it proves problematic later.
> 
> 
> \* it may be possible, but the commit messages might not make much sense
> after that.
> 
> On Fri, 24 Aug 2018, 09:12 Benedict Elliott Smith, 
> wrote:
> 
>> +1 also for separate repo
>>
>>> On 24 Aug 2018, at 01:11, Jeff Jirsa  wrote:
>>>
>>> +1 for separate repo
>>>
>>>
>>> --
>>> Jeff Jirsa
>>>
>>>
 On Aug 23, 2018, at 1:00 PM, sankalp kohli 
>> wrote:

 Separate repo is in a majority so far. Please reply to this thread with
 your responses.

 On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh <
>> rahul.xavier.si...@gmail.com>
 wrote:

> +1 for separate repo. Especially on git. Maybe make it a submodule.
>
> Rahul
> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski ,
> wrote:
>> I'm also currently -1 on the in-tree option.
>>
>> Additionally to what Aleksey mentioned, I also don't see how we could
>> make this work with the current build and release process. Our scripts
>> [0] for creating releases (tarballs and native packages), would need
>> significant work to add support for an independent side-car. Our ant
>> based build process is also not a great start for adding new tasks,
>> let
>> alone integrating other tool chains for web components for a potential
> UI.
>>
>> [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
>>
>>
>>> On 21.08.18 19:20, Aleksey Yeshchenko wrote:
>>> Sure, allow me to elaborate - at least a little bit. But before I do,
> just let me note that this wasn’t a veto -1, just a shorthand for “I
>> don’t
> like this option”.
>>>
>>> It would be nice to have sidecar and C* version and release cycles
> fully decoupled. I know it *can* be done when in-tree, but the way we
>> vote
> on releases with tags off current branches would have to change
>> somehow.
> Probably painfully. It would be nice to be able to easily enforce
>> freezes,
> like the upcoming one, on the whole C* repo, while allowing feature
> development on the sidecar. It would be nice to not have sidecar
>> commits in
> emails from commits@ mailing list. It would be nice to not have C* CI
> trigger necessarily on sidecar commits. Groups of people working on
>> the two
> repos will mostly be different too, so what’s the point in sharing the
>> repo?
>>>
>>> Having an extra repo with its own set of branches is cheap and easy -
> we already do that with dtests. I like cleanly separated things when
> coupling is avoidable. As such I would prefer the sidecar to live in a
> separate new repo, while still being part of the C* project.
>>>
>>> —
>>> AY
>>>
>>> On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com
>> )
> wrote:
>>>
>>> Hi Aleksey,
>>> Can you please elaborate on the reasons for your -1? This
>>> way we can make progress towards any one approach.
>>> Thanks,
>>> Sankalp
>>>
>>> On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko <
>> alek...@apple.com>
>>> wrote:
>>>
 FWIW I’m strongly -1 on in-tree approach, and would much prefer a
> separate
 repo, dtest-style.

 —
 AY

 On 21 August 2018 at 16:36:02, Jeremiah D Jordan (
 jeremiah.jor...@gmail.com) wrote:

 I think the following is a very big plus of it being in tree:
>> * Faster iteration speed in general. For example when we need to
> add a
>> new
>> JMX endpoint that the sidecar needs, or change something from
> JMX to a
>> virtual table (e.g. for repair, or monitoring) we can do all
> changes
>> including tests as one commit within the main repository and
> don't
 have
>> to
>> commit to main repo, sidecar repo,

 I also don’t see a reason why the sidecar being in tree means it
> would not
 work in a mixed version cluster. The nodes themselves must work in a
> mixed
 version cluster during a rolling upgrade, I would expect any
> management
 side car to operate in the same manor, in tree or not.

 This tool will be pretty tightly coupled with the server, and as
> someone
 with experience developing such tightly coupled tools, it is *much*
> easier
 to make sure you don’t accidentally break them if they are in tree.
> How
 many times has someone updated some JMX interface, updated nodetool,
>>>

FYI: builds.apache.org is down

[Michael Shuler]

https://status.apache.org/
https://lists.apache.org/thread.html/53e9cf7ded15f2e348be2fd36a11fd3aa4dc43462d6aa5a197dbd337@%3Cbuilds.apache.org%3E

-- 
Kind regards,
Michael

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

Re: [Discuss] Accept GoCQL driver donation

[Michael Shuler]

On 08/31/2018 09:34 AM, Jay Zhuang wrote:
> That's great. Could that be in the same repo as Cassandra or a
> separate repo?

For similar reasons as discussed for an admin tool, separate
repositories are quick and simple to create, as well as allow handling
contribution, CI, build, release, etc. mechanics more flexibly. I see
little to no advantage to including allthethings in-tree. If there comes
a time that particular contrib items do make sense to include in the
main repository, dropping them in would be no problem.

-- 
Michael

> On Fri, Aug 31, 2018 at 7:14 AM Nate McCall  wrote:
> 
>> Hi folks,
>> So I was recently talking with, Chris Bannister  the gocql [0]
>> maintainer, and he expressed an interest in donating the driver to the
>> ASF.
>>
>> We could accept this along the same lines as how we took in the dtest
>> donation - going through the incubator IP clearance process [1], but
>> in this case it's much simpler as an individual (Chris) owns the
>> copyright.
>>
>> I think the end goal here is to have a reference protocol
>> implementation controlled by the project at the least, potentially
>> replace cqlsh with a GoLang statically compiled binary eventually (?).
>>
>> What are other folks' thoughts about this? (we are discussing, not voting).
>>
>> [0] https://github.com/gocql/gocql
>> [1] https://incubator.apache.org/guides/ip_clearance.html
>>
>> -
>> 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: [Discuss] Accept GoCQL driver donation

[Michael Shuler]

On 08/31/2018 05:20 PM, Brandon Williams wrote:
> On Fri, Aug 31, 2018 at 4:24 PM Gary Dusbabek  wrote:
> 
>> At what point is the project comfortable/trusting with granting commit bits
>> to someone who is very familiar with a facet of the project (say, a go
>> client, or dtests), but hasn't made substantial contributions to the core
>> project? I think I'd be fine with it, but I'm curious what others think.
>>
> 
> I believe we already did this for our release maintainer.

Yep! I was going to comment similarly. I would be in full support of a
committer who focused purely on documentation and website content, for
instance. It's a matter of trusting a contributor to know what and where
to commit, as well as where/what/when not to.

-- 
Kind regards,
Michael

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

Re: Request for post-freeze merge exception

[Michael Shuler]

+1 to merge.

-- 
Michael

On 09/04/2018 01:05 PM, Sam Tunnicliffe wrote:
> Hey all,
> 
> On 2018-31-08 CASSANDRA-14145 had been +1'd by two reviewers and CI was
> green, and so it was marked Ready To Commit. This was before the 4.0
> feature freeze but before it landed, CASSANDRA-14408, which touched a few
> common areas of the code, was merged. I didn't have chance to finish the
> rebase over the weekend but in the end it turned out that most of the
> conflicts were in test code and were straightforward to resolve. I'd like
> to commit this now; the rebase is done (& has been re-reviewed), and the CI
> is still green so I suspect most of the community would probably be ok with
> that. We did vote for a freeze though and I don't want to subvert or
> undermine that decision, so I wanted to check and give a chance for anyone
> to raise objections before I did.
> 
> I'll wait 24 hours, and if nobody objects before then I'll merge to trunk.
> 
> Thanks,
> Sam
> 


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

Re: Moving tickets out of 4.0 post freeze

[Michael Shuler]

On 9/24/18 7:09 AM, Joshua McKenzie wrote:
> I propose we move all new features and improvements to 4.0.x to keep the
> surface area of change for the major stable.

It occurs to me that we should probably update the version in trunk to
4.0.0, if we're following semantic versions. I suppose this also means
all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc.

-- 
Michael

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

Re: Moving tickets out of 4.0 post freeze

[Michael Shuler]

On 9/24/18 12:21 PM, Aleksey Yeshchenko wrote:
> We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with
> minor forever fixed to 0.
> 
> But I’m also struggling with how to justify the existence of that
> unused digit. We have never really done semantic versioning, we’ve
> arbitrarily flipped the major whenever we felt like “it was the right
> time” and/or for marketing reasons. Might as well drop the charade,
> and C*4 seems as good time as any to do that.

It doesn't have to stay 0. I like your idea of doing meaningful major
release number changes. We could also fix our minor version handling
behavior.

We could use the minor version number to provide meaning for things like
upgrade issues, which in the past have been a random .. version number, buried in NEWS.txt somewhere.
Sometimes people have wished to add new metrics, as an example
improvement, and those have been pushed to the next major. This could be
4.1.0: all the 4.0.x bug fixes, along with "your perf monitoring thing
may break" messaging to users. Still 4.x, but improvements on 4.0 we're
calling 4.1, so beware.

I'm totally spitballing here on possible uses of meaningful minors.

> Perhaps we should discuss this in a separate thread, maybe closer to
> 4.0 release time, so that it doesn’t distract us from more important
> current issues.

Doing this early in the cycle is way better, imo - tests may^Wwill
break, third-party things parsing versions may break. Now would be the
time to make version changes, instead of waiting until the last minute.

Regardless, the OP's statement that new features and improvements should
go to 4.0.x seems wrong - shouldn't that be 5.x? (where version numbers
could/would be 5.0.x, etc.)

Sure, we can create another thread, but since versions break tests and
drivers and such, and were all about making sure tests are clean, it's
relevant, along with deciding what version to move new feature tickets
out to.


Michael

>> On 24 Sep 2018, at 17:55, Jeremiah D Jordan 
>> wrote:
>> 
>> So as to not confuse people, even if we never put out a 4.1, I
>> think we should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x.
>> And yes our .. versioning of the past
>> never followed semver.
>> 
>> -Jeremiah
>> 
>>> On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith
>>>  wrote:
>>> 
>>> I’d like to propose we don’t do Semver.  Back when we did this
>>> before, there wasn’t any clear distinction between a major and a
>>> minor release.  They were both infrequent, both big, and were
>>> treated as majors for EOL'ing support for older releases.  This
>>> must surely have been confusing for users, and I’m not sure what
>>> we got from it?
>>> 
>>> Why don’t we keep it simple, and just have major.patch?  So we
>>> would release simply ‘4’ now, and the next feature release would
>>> be ‘5'.
>>> 
>>> 
>>> 
>>> 
>>>> On 24 Sep 2018, at 17:34, Michael Shuler
>>>>  wrote:
>>>> 
>>>> On 9/24/18 7:09 AM, Joshua McKenzie wrote:
>>>>> I propose we move all new features and improvements to 4.0.x
>>>>> to keep the surface area of change for the major stable.
>>>> 
>>>> It occurs to me that we should probably update the version in
>>>> trunk to 4.0.0, if we're following semantic versions. I suppose
>>>> this also means all the tickets for 4.x should be updated to
>>>> 4.0.x, 4.0 to 4.0.0, etc.
>>>> 
>>>> -- Michael
>>>> 
>>>> -
>>>>
>>>> 
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
>> 
> 
> 
> -
>
> 
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: CASSANDRA-13241 lower default chunk_length_in_kb

[Michael Shuler]

On 10/19/18 9:16 AM, Joshua McKenzie wrote:
> 
> At the risk of hijacking this thread, when are we going to transition from
> "no new features, change whatever else you want including refactoring and
> changing years-old defaults" to "ok, we think we have something that's
> stable, time to start testing"?

Creating a cassandra-4.0 branch would allow trunk to, for instance, get
a default config value change commit and get more testing. We might
forget again, from what I understand of Benedict's last comment :)

-- 
Michael

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

Re: Cassandra 4.0 on Windows 10 crashing upon startup with Java 11

[Michael Shuler]

On 11/12/18 4:01 AM, Steinmaurer, Thomas wrote:
> Hello,
> 
> on Windows 10, Cassandra 4.0 (trunk Nov 12) is crashing upon startup with 
> Java 11, SIGAR related. Startup with Java8 works fine. Is this a known issue?
> 
> First part of the hs_err_pid file.
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, 
> pid=14472, tid=13316
> #
> # JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
> # Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, 
> compressed oops, concurrent mark sweep gc, windows-amd64)
> # Problematic frame:
> # C  [sigar-amd64-winnt.dll+0x14ed4]

Looks a lot like:
https://bugs.openjdk.java.net/browse/JDK-8191547 - closed as Not an
Issue with upstream links to:
https://github.com/hyperic/sigar/issues/77
https://comm.support.ca.com/kb/devtest-9x-server-component-fails-to-start-error-sigaramd64winntdll0x14ed4/kb41311

Michael




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

Re: RES: Implicit Casts for Arithmetic Operators

[Michael Shuler]

On 11/20/18 9:53 AM, Versátil wrote:
> 
> PLEASE TAKE MY EMAIL FROM THIS SHIT !!

FYI, mailing list subscriptions (and unsubscriptions) are self-serve. In
general, you subscribed yourself, so you are responsible to unsubscribe.
The email address to do so is appended to every plain text message to
the list.

You will still have to follow the approval link you'll get from the list
moderation removal CC here, sent on your behalf...

-- 
Kind regards,
Michael

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

Re: RES: RES: Implicit Casts for Arithmetic Operators

[Michael Shuler]

On 11/20/18 10:15 AM, Versátil wrote:
> 
> I already requested as you said and it did not help. And I NEVER asked to 
> enter into this discussion. Please request to withdraw my email 

 | | | | | | | | | |
\/\/\/\/\/\/\/\/\/\/

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


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

Re: [VOTE] Change Jira Workflow

[Michael Shuler]

+1

-- 
Michael

On 12/17/18 9:19 AM, Benedict Elliott Smith wrote:
> I propose these changes 
> *
>  to the Jira Workflow for the project.  The vote will be open for 72 hours**.
> 
> I am, of course, +1.
> 
> * With the addendum of the mailing list discussion 
> ;
>  in case of any conflict arising from a mistake on my part in the wiki, the 
> consensus reached by polling the mailing list will take precedence.
> ** I won’t be around to close the vote, as I will be on vacation.  Everyone 
> is welcome to ignore the result until I get back in a couple of weeks, or if 
> anybody is eager feel free to close the vote and take some steps towards 
> implementation.
> 


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

Re: Git Repo Migration

[Michael Shuler]

This change will be forced on Feb 7, so a vote isn't really relevant :)

I'm in favor of sooner is better. Things are relatively quiet right now,
post-holidays. Let's do it Monday, for example, and we can work through
the config changes while most people are fresh from a break.

The longer we wait, the more things people have in flight and they get
bothered about being interrupted. Just interrupt ASAP, IMO.

Michael

On 1/4/19 4:49 AM, Sam Tunnicliffe wrote:
> As per the announcement on 7th December 2018[1], ASF infra are
> planning to shutdown the service behind git-wip-us.apache.org and
> migrate all existing repos to gitbox.apache.org
> 
> There are further details in the original mail, but apparently one of
> the benefits of the migration is that we'll have full write access
> via Github, including the ability finally to close PRs. This affects
> the cassandra, cassandra-dtest and cassandra-build repos (but not the
> new cassandra-sidecar repo).
> 
> A pre-requisite of the migration is to demonstrate consensus within
> the community, so to satisfy that formality I'm starting this thread
> to gather any objections or specific requests regarding the timing of
> the move.
> 
> I'll collate responses in a week or so and file the necessary INFRA
> Jira.
> 
> Thanks, Sam
> 
> [1]
> https://lists.apache.org/thread.html/667772efdabf49a0a23d585539c127f335477e033f1f9b6f5079aced@%3Cdev.cassandra.apache.org%3E
>
> 
> 
> -
>
> 
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: Git Repo Migration

[Michael Shuler]

Patches:
cassandra - https://github.com/apache/cassandra/pull/297
cassandra-builds - https://github.com/apache/cassandra-builds/pull/8
cassandra-dtest - no git-wip usage found.

URL update for the DSL seed job repo should be the only change needed
there, after the above cassandra-builds commit.
- https://builds.apache.org/job/Cassandra-Job-DSL/

The only other consideration I can think of after migration is checking
the git.a.o bare and github mirror post-commit hooks work as expected.
- http://git.apache.org/cassandra.git/

Michael

On 1/4/19 2:00 PM, Jonathan Haddad wrote:
> Silence can be interpreted either as non-awareness or implicit approval.
> 
> I interpreted (and meant) +1 as "go for it now".
> 
> On Fri, Jan 4, 2019 at 8:48 AM Sam Tunnicliffe  wrote:
> 
>> Yeah, I wasn’t really proposing a vote as like you said, it’s happening
>> anyway. I was just going to give a few days for people to chime in about
>> timings, seeing as some may still be afk after holidays etc. I’ll give it a
>> little while to at least maintain the illusion of waiting for consensus,
>> but filing the JIRA early next week SGTM.
>>
>> Thanks,
>> Sam
>>
>>> On 4 Jan 2019, at 16:24, Michael Shuler  wrote:
>>>
>>> This change will be forced on Feb 7, so a vote isn't really relevant :)
>>>
>>> I'm in favor of sooner is better. Things are relatively quiet right now,
>>> post-holidays. Let's do it Monday, for example, and we can work through
>>> the config changes while most people are fresh from a break.
>>>
>>> The longer we wait, the more things people have in flight and they get
>>> bothered about being interrupted. Just interrupt ASAP, IMO.
>>>
>>> Michael
>>>
>>> On 1/4/19 4:49 AM, Sam Tunnicliffe wrote:
>>>> As per the announcement on 7th December 2018[1], ASF infra are
>>>> planning to shutdown the service behind git-wip-us.apache.org and
>>>> migrate all existing repos to gitbox.apache.org
>>>>
>>>> There are further details in the original mail, but apparently one of
>>>> the benefits of the migration is that we'll have full write access
>>>> via Github, including the ability finally to close PRs. This affects
>>>> the cassandra, cassandra-dtest and cassandra-build repos (but not the
>>>> new cassandra-sidecar repo).
>>>>
>>>> A pre-requisite of the migration is to demonstrate consensus within
>>>> the community, so to satisfy that formality I'm starting this thread
>>>> to gather any objections or specific requests regarding the timing of
>>>> the move.
>>>>
>>>> I'll collate responses in a week or so and file the necessary INFRA
>>>> Jira.
>>>>
>>>> Thanks, Sam
>>>>
>>>> [1]
>>>>
>> https://lists.apache.org/thread.html/667772efdabf49a0a23d585539c127f335477e033f1f9b6f5079aced@%3Cdev.cassandra.apache.org%3E

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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

Mick and I have discussed this previously, but I don't recall if it was
email or irc. Apologies if I was unable to describe the problem to a
point of general understanding.

To reiterate the problem, changing gpg signature keys screws our debian
and redhat package repositories for all users. Tarballs are not
installed with a client that checks signatures in a known trust
database. When gpg key signer changes, users need to modify their trust
on every node, importing new key(s), in order for packages to
install/upgrade with apt or yum.

I don't understand how adding keys changes release frequency. Did
someone request a release to be made or are we on some assumed date
interval?

Michael

On 1/7/19 2:30 PM, Jonathan Haddad wrote:
> That's a good point.  Looking at the ASF docs I had assumed the release
> manager was per-project, but on closer inspection it appears to be
> per-release.  You're right, it does say that it can be any committer.
> 
> http://www.apache.org/dev/release-publishing.html#release_manager
> 
> We definitely need more frequent releases, if this is the first step
> towards that goal, I think it's worth it.
> 
> Glad you brought this up!
> Jon
> 
> 
> On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever  wrote:
> 
>>
>>
>>> I don't see any reason to have any keys in there, except from release
>>> managers who are signing releases.
>>
>>
>> Shouldn't any PMC (or committer) should be able to be a release manager?
>>
>> The release process should be reliable and reproducible enough to be safe
>> for rotating release managers every release. I would have thought security
>> concerns were better addressed by a more tested process? And AFAIK no other
>> asf projects are as restrictive on who can be the release manager role (but
>> i've only checked a few projects).
>>
>>
>>
>> -
>> 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: Who should be in our distribution KEYS file?

[Michael Shuler]

To-do items that might further the goal of getting more people involved
in releases, here are a couple tickets on this:

https://issues.apache.org/jira/browse/CASSANDRA-14962
https://issues.apache.org/jira/browse/CASSANDRA-14963

#14962 is really a "we're doing it wrong" ticket on release artifacts.
There are also some comments in the details of
http://cassandra.apache.org/doc/latest/development/release_process.html
that could be streamlined and include fixing the steps, temporary upload
problems, etc. Work on temporary uploads for staging the artifacts could
be useful for #14963.

Michael

On 1/7/19 3:15 PM, Michael Shuler wrote:
> Mick and I have discussed this previously, but I don't recall if it was
> email or irc. Apologies if I was unable to describe the problem to a
> point of general understanding.
> 
> To reiterate the problem, changing gpg signature keys screws our debian
> and redhat package repositories for all users. Tarballs are not
> installed with a client that checks signatures in a known trust
> database. When gpg key signer changes, users need to modify their trust
> on every node, importing new key(s), in order for packages to
> install/upgrade with apt or yum.
> 
> I don't understand how adding keys changes release frequency. Did
> someone request a release to be made or are we on some assumed date
> interval?
> 
> Michael
> 
> On 1/7/19 2:30 PM, Jonathan Haddad wrote:
>> That's a good point.  Looking at the ASF docs I had assumed the release
>> manager was per-project, but on closer inspection it appears to be
>> per-release.  You're right, it does say that it can be any committer.
>>
>> http://www.apache.org/dev/release-publishing.html#release_manager
>>
>> We definitely need more frequent releases, if this is the first step
>> towards that goal, I think it's worth it.
>>
>> Glad you brought this up!
>> Jon
>>
>>
>> On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever  wrote:
>>
>>>
>>>
>>>> I don't see any reason to have any keys in there, except from release
>>>> managers who are signing releases.
>>>
>>>
>>> Shouldn't any PMC (or committer) should be able to be a release manager?
>>>
>>> The release process should be reliable and reproducible enough to be safe
>>> for rotating release managers every release. I would have thought security
>>> concerns were better addressed by a more tested process? And AFAIK no other
>>> asf projects are as restrictive on who can be the release manager role (but
>>> i've only checked a few projects).
>>>
>>>
>>>
>>> -
>>> 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: Who should be in our distribution KEYS file?

[Michael Shuler]

Also, in case someone brings it up, there's an ongoing relevant
discussion on the builds@a.o list on automating releases, which includes
lots of good thoughts on the topic.

https://lists.apache.org/thread.html/af4b2a5d73fde5ab76a376549f645404da7865a8b002145435b2359c@%3Cbuilds.apache.org%3E

Michael

On 1/7/19 3:32 PM, Michael Shuler wrote:
> To-do items that might further the goal of getting more people involved
> in releases, here are a couple tickets on this:
> 
> https://issues.apache.org/jira/browse/CASSANDRA-14962
> https://issues.apache.org/jira/browse/CASSANDRA-14963
> 
> #14962 is really a "we're doing it wrong" ticket on release artifacts.
> There are also some comments in the details of
> http://cassandra.apache.org/doc/latest/development/release_process.html
> that could be streamlined and include fixing the steps, temporary upload
> problems, etc. Work on temporary uploads for staging the artifacts could
> be useful for #14963.
> 
> Michael
> 
> On 1/7/19 3:15 PM, Michael Shuler wrote:
>> Mick and I have discussed this previously, but I don't recall if it was
>> email or irc. Apologies if I was unable to describe the problem to a
>> point of general understanding.
>>
>> To reiterate the problem, changing gpg signature keys screws our debian
>> and redhat package repositories for all users. Tarballs are not
>> installed with a client that checks signatures in a known trust
>> database. When gpg key signer changes, users need to modify their trust
>> on every node, importing new key(s), in order for packages to
>> install/upgrade with apt or yum.
>>
>> I don't understand how adding keys changes release frequency. Did
>> someone request a release to be made or are we on some assumed date
>> interval?
>>
>> Michael
>>
>> On 1/7/19 2:30 PM, Jonathan Haddad wrote:
>>> That's a good point.  Looking at the ASF docs I had assumed the release
>>> manager was per-project, but on closer inspection it appears to be
>>> per-release.  You're right, it does say that it can be any committer.
>>>
>>> http://www.apache.org/dev/release-publishing.html#release_manager
>>>
>>> We definitely need more frequent releases, if this is the first step
>>> towards that goal, I think it's worth it.
>>>
>>> Glad you brought this up!
>>> Jon
>>>
>>>
>>> On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever  wrote:
>>>
>>>>
>>>>
>>>>> I don't see any reason to have any keys in there, except from release
>>>>> managers who are signing releases.
>>>>
>>>>
>>>> Shouldn't any PMC (or committer) should be able to be a release manager?
>>>>
>>>> The release process should be reliable and reproducible enough to be safe
>>>> for rotating release managers every release. I would have thought security
>>>> concerns were better addressed by a more tested process? And AFAIK no other
>>>> asf projects are as restrictive on who can be the release manager role (but
>>>> i've only checked a few projects).
>>>>
>>>>
>>>>
>>>> -
>>>> 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: Who should be in our distribution KEYS file?

[Michael Shuler]

Yeah, I asked if someone made a request thinking I totally missed it!
Since the last couple tick-tock releases, which were time based, every
release has been initiated by someone commenting in IRC or dev@ that
"there are a lot of things in CHANGES.txt" or "important fix foo has
been committed, let's release". It looks like the interval on releases
has been about 4-6 months, so we're due :)

More packaging / GPG key tickets, if someone wants to take them on:
https://issues.apache.org/jira/browse/CASSANDRA-14966
https://issues.apache.org/jira/browse/CASSANDRA-14967
https://issues.apache.org/jira/browse/CASSANDRA-14968

I see other Debian and RPM type repositories configured in the Apache
bintray project, so perhaps signing of the package repositories can be
done using their signing feature(?).

I just really wish to cause users installation/upgrade difficulty as
little as possible. If we're going to change up to something that allows
more people to do maven and tarball releases, great, I don't care, since
there's no tar-install-client that cares. I absolutely don't want
deb/rpm package repository users to constantly need to update GPG keys
every release, that's not nice to our users. If there is a way to get
the repos set up correctly in bintray, and it's OK with INFRA to use the
bintray key signing feature, great. We should set up a new package
signing key and configure bintray to sign the metadata. One change for a
long-term solution.

Michael

On 1/7/19 4:34 PM, Jeff Jirsa wrote:
> I dont think it's awkward, I think a lot of us know there are serious bugs
> and we need a release, but we keep finding other bugs and it's super
> tempting to say "one more fix"
> 
> We should probably just cut next 3.0.x and 3.11.x though, because there are
> some nasty bugs hiding in there that the testing for 4.0 has uncovered.
> 
> 
> On Mon, Jan 7, 2019 at 2:14 PM Jonathan Haddad  wrote:
> 
>>> I don't understand how adding keys changes release frequency. Did
>> someone request a release to be made or are we on some assumed date
>> interval?
>>
>> I don't know if it would (especially by itself), I just know that if more
>> people are able to do releases that's more opportunity to do so.
>>
>> I think getting more folks involved in the release process is a good idea
>> for other reasons.  People take vacations, there's job conflicts, there's
>> life stuff (kids usually take priority), etc.
>>
>> The last release of 3.11 was almost half a year ago, and there's 30+ bug
>> fixes in the 3.11 branch.
>>
>>> Did someone request a release to be made or are we on some assumed date
>> interval?
>>
>> I can't recall (and a search didn't find) anyone asking for a 3.11.4
>> release, but I think part of the point is that requesting a release from a
>> static release manager is a sign of a flaw in the release process.
>>
>> On a human, note, it feels a little awkward asking for a release.  I might
>> be alone on this though.
>>
>> Jon
>>
>>
>> On Mon, Jan 7, 2019 at 1:16 PM Michael Shuler 
>> wrote:
>>
>>> Mick and I have discussed this previously, but I don't recall if it was
>>> email or irc. Apologies if I was unable to describe the problem to a
>>> point of general understanding.
>>>
>>> To reiterate the problem, changing gpg signature keys screws our debian
>>> and redhat package repositories for all users. Tarballs are not
>>> installed with a client that checks signatures in a known trust
>>> database. When gpg key signer changes, users need to modify their trust
>>> on every node, importing new key(s), in order for packages to
>>> install/upgrade with apt or yum.
>>>
>>> I don't understand how adding keys changes release frequency. Did
>>> someone request a release to be made or are we on some assumed date
>>> interval?
>>>
>>> Michael
>>>
>>> On 1/7/19 2:30 PM, Jonathan Haddad wrote:
>>>> That's a good point.  Looking at the ASF docs I had assumed the release
>>>> manager was per-project, but on closer inspection it appears to be
>>>> per-release.  You're right, it does say that it can be any committer.
>>>>
>>>> http://www.apache.org/dev/release-publishing.html#release_manager
>>>>
>>>> We definitely need more frequent releases, if this is the first step
>>>> towards that goal, I think it's worth it.
>>>>
>>>> Glad you brought this up!
>>>> Jon
>>>>
>>>>

Re: [DISCUSS] releasing next 3.0 & 3.11

[Michael Shuler]

No problem, thanks for asking :)

Michael

On 1/7/19 6:20 PM, Jonathan Haddad wrote:
> It's been 5 months and 30+ bug fixes to each branch.
> 
> Here's the two changelogs:
> 
> https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt
> https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt
> 
> How's everyone feel about getting a release out this week / early next
> week?  Some of these bugs are show stoppers, causing OOMs and data loss.
> 


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

EOL 2.1 series?

[Michael Shuler]

It came to my attention on IRC a week or so ago, and following up on the
ticket that someone asked if they should commit to 2.1, that developers
have been actively ignoring the 2.1 branch. If we're not committing
critical fixes there, even when we know they exist, I think it's time to
just call it EOL an do one last release of the few fixes that did get
committed. Comments?

Michael

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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

For Debian, Fedora, etc. to package Cassandra at the OS level, first all
dependencies (and deps of deps) must be packaged and uploaded, so they
can be depended on by Cassandra. This means Hadoop. It has been
attempted and abandoned by multiple people, myself included.

A little digging on one example Apache project hosting deb/rpm repos at
bintray, Apache Ignite, there are multiple repo problems that can be
solved by the tickets I listed below.

Details:
https://issues.apache.org/jira/browse/CASSANDRA-14968?focusedCommentId=16738342&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16738342

tl;dr:
- I think we can use the bintray key to sign the repos, there's precedent
- using bintray to build the deb/rpm repos, all version in each suite
(22x, 30x, ..) will be installable, instead of just the latest version

Michael

On 1/9/19 8:06 AM, Stefan Podkowinski wrote:
> If creating native deb/rpm package signatures and repo metadata
> signatures is the only issue that stops us from releasing more often and
> sharing the burden in doing so, then I'd be happy to discuss dropping
> this altogether. We can always distribute binary packages along with
> checksums and a detached gpg signature by any KEYS person, just as we do
> with the tarballs.
> 
> Having an Apache hosted Cassandra yum/deb repo may be convenient, but I
> wonder how many users will still download the packages and host them in
> their own internal repo. Even if it's just to have the option to pin the
> package to a specific version, which we currently don't offer, as only
> the latest package is included in the repo metadata. It might also
> encourage distros to keep downstream repos updated as well, since that
> would be the ideal way of creating and distributing package, i.e. having
> a Debian/Fedora/Ubuntu maintainer taking care of that and only have
> users come back to us for the vanilla rpm in case their downstream
> version is outdated.
> 
> 
> On 08.01.19 02:48, Michael Shuler wrote:
>> Yeah, I asked if someone made a request thinking I totally missed it!
>> Since the last couple tick-tock releases, which were time based, every
>> release has been initiated by someone commenting in IRC or dev@ that
>> "there are a lot of things in CHANGES.txt" or "important fix foo has
>> been committed, let's release". It looks like the interval on releases
>> has been about 4-6 months, so we're due :)
>>
>> More packaging / GPG key tickets, if someone wants to take them on:
>> https://issues.apache.org/jira/browse/CASSANDRA-14966
>> https://issues.apache.org/jira/browse/CASSANDRA-14967
>> https://issues.apache.org/jira/browse/CASSANDRA-14968
>>
>> I see other Debian and RPM type repositories configured in the Apache
>> bintray project, so perhaps signing of the package repositories can be
>> done using their signing feature(?).
>>
>> I just really wish to cause users installation/upgrade difficulty as
>> little as possible. If we're going to change up to something that allows
>> more people to do maven and tarball releases, great, I don't care, since
>> there's no tar-install-client that cares. I absolutely don't want
>> deb/rpm package repository users to constantly need to update GPG keys
>> every release, that's not nice to our users. If there is a way to get
>> the repos set up correctly in bintray, and it's OK with INFRA to use the
>> bintray key signing feature, great. We should set up a new package
>> signing key and configure bintray to sign the metadata. One change for a
>> long-term solution.
>>
>> Michael
>>
>> On 1/7/19 4:34 PM, Jeff Jirsa wrote:
>>> I dont think it's awkward, I think a lot of us know there are serious
>>> bugs
>>> and we need a release, but we keep finding other bugs and it's super
>>> tempting to say "one more fix"
>>>
>>> We should probably just cut next 3.0.x and 3.11.x though, because
>>> there are
>>> some nasty bugs hiding in there that the testing for 4.0 has uncovered.
>>>
>>>
>>> On Mon, Jan 7, 2019 at 2:14 PM Jonathan Haddad 
>>> wrote:
>>>
>>>>> I don't understand how adding keys changes release frequency. Did
>>>> someone request a release to be made or are we on some assumed date
>>>> interval?
>>>>
>>>> I don't know if it would (especially by itself), I just know that if
>>>> more
>>>> people are able to do releases that's more opportunity to do so.
>>>>
>>>> I think getting more folks involved in the rel

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

Sorry, I forgot to include the most important feature for potentially
using bintray deb/rpm repos, signed by the bintray key:

- New gpg keys could be added to KEYS for interested new release
managers, and releases could be done by those interested new Cassandra
release managers, requiring only one key change for deb/rpm repository
users.

Michael

On 1/9/19 11:13 AM, Michael Shuler wrote:
> For Debian, Fedora, etc. to package Cassandra at the OS level, first all
> dependencies (and deps of deps) must be packaged and uploaded, so they
> can be depended on by Cassandra. This means Hadoop. It has been
> attempted and abandoned by multiple people, myself included.
> 
> A little digging on one example Apache project hosting deb/rpm repos at
> bintray, Apache Ignite, there are multiple repo problems that can be
> solved by the tickets I listed below.
> 
> Details:
> https://issues.apache.org/jira/browse/CASSANDRA-14968?focusedCommentId=16738342&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16738342
> 
> tl;dr:
> - I think we can use the bintray key to sign the repos, there's precedent
> - using bintray to build the deb/rpm repos, all version in each suite
> (22x, 30x, ..) will be installable, instead of just the latest version
> 
> Michael
> 
> On 1/9/19 8:06 AM, Stefan Podkowinski wrote:
>> If creating native deb/rpm package signatures and repo metadata
>> signatures is the only issue that stops us from releasing more often and
>> sharing the burden in doing so, then I'd be happy to discuss dropping
>> this altogether. We can always distribute binary packages along with
>> checksums and a detached gpg signature by any KEYS person, just as we do
>> with the tarballs.
>>
>> Having an Apache hosted Cassandra yum/deb repo may be convenient, but I
>> wonder how many users will still download the packages and host them in
>> their own internal repo. Even if it's just to have the option to pin the
>> package to a specific version, which we currently don't offer, as only
>> the latest package is included in the repo metadata. It might also
>> encourage distros to keep downstream repos updated as well, since that
>> would be the ideal way of creating and distributing package, i.e. having
>> a Debian/Fedora/Ubuntu maintainer taking care of that and only have
>> users come back to us for the vanilla rpm in case their downstream
>> version is outdated.
>>
>>
>> On 08.01.19 02:48, Michael Shuler wrote:
>>> Yeah, I asked if someone made a request thinking I totally missed it!
>>> Since the last couple tick-tock releases, which were time based, every
>>> release has been initiated by someone commenting in IRC or dev@ that
>>> "there are a lot of things in CHANGES.txt" or "important fix foo has
>>> been committed, let's release". It looks like the interval on releases
>>> has been about 4-6 months, so we're due :)
>>>
>>> More packaging / GPG key tickets, if someone wants to take them on:
>>> https://issues.apache.org/jira/browse/CASSANDRA-14966
>>> https://issues.apache.org/jira/browse/CASSANDRA-14967
>>> https://issues.apache.org/jira/browse/CASSANDRA-14968
>>>
>>> I see other Debian and RPM type repositories configured in the Apache
>>> bintray project, so perhaps signing of the package repositories can be
>>> done using their signing feature(?).
>>>
>>> I just really wish to cause users installation/upgrade difficulty as
>>> little as possible. If we're going to change up to something that allows
>>> more people to do maven and tarball releases, great, I don't care, since
>>> there's no tar-install-client that cares. I absolutely don't want
>>> deb/rpm package repository users to constantly need to update GPG keys
>>> every release, that's not nice to our users. If there is a way to get
>>> the repos set up correctly in bintray, and it's OK with INFRA to use the
>>> bintray key signing feature, great. We should set up a new package
>>> signing key and configure bintray to sign the metadata. One change for a
>>> long-term solution.
>>>
>>> Michael
>>>
>>> On 1/7/19 4:34 PM, Jeff Jirsa wrote:
>>>> I dont think it's awkward, I think a lot of us know there are serious
>>>> bugs
>>>> and we need a release, but we keep finding other bugs and it's super
>>>> tempting to say "one more fix"
>>>>
>>>> We should probably just cut next 3.0.x and 3.11.x though, because
>>>

Re: [DISCUSS] releasing next 3.0 & 3.11

[Michael Shuler]

On 1/16/19 1:05 PM, Jonathan Haddad wrote:
> Ping on this.

https://issues.apache.org/jira/browse/CASSANDRA-14970

I could just punt and use what we've got with md5,sha1 checksums, then
toss sha256,sha512 checksums in dist repo, when we're done. It's not
pretty, but would work for me. That method would mean zero sharing of
release duty, since the artifacts live on one person's workstation,
instead of published where they can be downloaded.

I would appreciate some help with the ant targets. (it might be
something simple with mvn-install/publish target fixes, but I don't have
a massive amount of time to troubleshoot more. I did commit the release
target fix.

-- 
Michael

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

[VOTE] Release Apache Cassandra 2.2.14

[Michael Shuler]

I propose the following artifacts for release as 2.2.14.

sha1: af91658353ba601fc8cd08627e8d36bac62e936a
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1172/org/apache/cassandra/apache-cassandra/2.2.14/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1172/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative



signature.asc
Description: OpenPGP digital signature

[VOTE] Release Apache Cassandra 3.0.18

[Michael Shuler]

I propose the following artifacts for release as 3.0.18.

sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1171/org/apache/cassandra/apache-cassandra/3.0.18/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1171/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative



signature.asc
Description: OpenPGP digital signature

[VOTE] Release Apache Cassandra 2.1.21

[Michael Shuler]

*EOL* release for the 2.1 series. There will be no new releases from the
'cassandra-2.1' branch after this release.



I propose the following artifacts for release as 2.1.21.

sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1173/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative



signature.asc
Description: OpenPGP digital signature

[VOTE] Release Apache Cassandra 3.11.4

[Michael Shuler]

I propose the following artifacts for release as 3.11.4.

sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1170/org/apache/cassandra/apache-cassandra/3.11.4/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1170/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Cassandra 2.1.21

[Michael Shuler]

My first couple sentences in the vote email were intended as a
statement, based on a lack of concerns voiced on EOL of 2.1.

I made a request for comment on EOL of 2.1 series a month ago, in
"Subject: EOL 2.1 series?":
https://lists.apache.org/thread.html/87ee2e3d13ea96744545ed8612496a93f8235747c4f60d0084b37bae@%3Cdev.cassandra.apache.org%3E

Yes, I'm aware our download page states we support 2.1 until 4.0, but we
do not really do so.

The reality is that developers have been actively ignoring the branch,
even when suggested to commit to the 2.1 branch. I can go dig up IRC
logs and commits, but I really don't feel like it adds any value to the
conversation. As Jonathan Haddad says, let's just be honest with users
about what has already been happening independently.

To continue stating we actively support 2.1 until 4.0 and actually
follow through, the project should audit fixed bugs in 2.2+ and see if
they still exist in 2.1, unfixed. I imagine there are a few. I know for
sure of one that was not committed. Alternatively, we sunset the branch,
make that change on the download page, and move on. I don't think it's
right to continue telling users we are doing something, if we aren't and
haven't been.

Michael

On 2/3/19 5:24 PM, Anthony Grasso wrote:
> +1 non-binding, for the release of 2.1.21
> 
> Regarding EOL of 2.1.x, did we announce in the past that 2.1.21 would be
> the final release?
> 
> According to the download <http://cassandra.apache.org/download/> page 2.1
> is meant to be supported with critical fixes only until 4.0 is released. I
> suspect that people may be relying on this, as I have seen a number 2.1.x
> clusters still in production use.
> 
> On Mon, 4 Feb 2019 at 07:09, Jonathan Haddad  wrote:
> 
>> I think having the discussion around EOL is pretty important, in order to
>> set the right expectations for the community.
>>
>> Looking at the commits for 2.1, there's hardly any activity going on,
>> meaning it's effectively been EOL'ed for a long time now.  I think it's
>> better that we be honest with folks about it.
>>
>> On Sun, Feb 3, 2019 at 9:34 AM Nate McCall  wrote:
>>
>>> +1 on the release of 2.1.21 (let's focus on that in the spirit of
>>> these other votes we have up right now).
>>>
>>> I don't feel the need to be absolutist about something being EOL.
>>>
>>> On Sun, Feb 3, 2019 at 1:47 AM Stefan Podkowinski 
>> wrote:
>>>>
>>>> What are we voting on here? Releasing the 2.1.21 candidate, or that 2.1
>>>> would become EOL? Please let's have separate votes on that, if you want
>>>> to propose putting 2.1 EOL (which I'm strongly -1).
>>>>
>>>>
>>>> On 03.02.19 01:32, Michael Shuler wrote:
>>>>> *EOL* release for the 2.1 series. There will be no new releases from
>>> the
>>>>> 'cassandra-2.1' branch after this release.
>>>>>
>>>>> 
>>>>>
>>>>> I propose the following artifacts for release as 2.1.21.
>>>>>
>>>>> sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
>>>>> Git:
>>>>>
>>>
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
>>>>> Artifacts:
>>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
>>>>> Staging repository:
>>>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1173/
>>>>>
>>>>> The Debian and RPM packages are available here:
>>>>> http://people.apache.org/~mshuler
>>>>>
>>>>> The vote will be open for 72 hours (longer if needed).
>>>>>
>>>>> [1]: CHANGES.txt:
>>>>>
>>>
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
>>>>> [2]: NEWS.txt:
>>>>>
>>>
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
>>>>>
>>>>
>>>> -
>>>> 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
>>>
>>>
>>
>> --
>> Jon Haddad
>> http://www.rustyrazorblade.com
>> twitter: rustyrazorblade
>>
> 


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

Re: [VOTE PASSED] Release Apache Cassandra 3.11.4

[Michael Shuler]

I count 8 binding +1 votes, 3 non-binding +1's, and no other votes, so
this vote passes. I'll get the artifacts published as soon as I can.

Kind regards,
Michael

On 2/2/19 6:31 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.11.4.
> 
> sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/org/apache/cassandra/apache-cassandra/3.11.4/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> 




signature.asc
Description: OpenPGP digital signature

Re: [VOTE PASSED] Release Apache Cassandra 3.0.18

[Michael Shuler]

With 8 binding +1 votes, 3 non-binding +1's, and no other votes, this
vote passed. I'll publish artifacts as soon as I can.

Kind regards,
Michael

On 2/2/19 6:32 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.0.18.
> 
> sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/org/apache/cassandra/apache-cassandra/3.0.18/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
> 




signature.asc
Description: OpenPGP digital signature

Re: [VOTE PASSED] Release Apache Cassandra 2.2.14

[Michael Shuler]

With 7 binding +1 votes, 2 non-binding +1, and no others, this vote
passed. I'll upload the artifacts as soon as possible.

Kind regards,
Michael

On 2/2/19 6:32 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 2.2.14.
> 
> sha1: af91658353ba601fc8cd08627e8d36bac62e936a
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/org/apache/cassandra/apache-cassandra/2.2.14/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> 




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Cassandra 2.1.21

[Michael Shuler]

I count 7 binding +1's, 1 non-binding +1 vote, and no others, so this
vote passes. I'll publish the artifacts as soon as I can.

Thanks for the discussion on support life of the 2.1 branch. I will not
be making any changes to the notes on the download page.

Kind regards,
Michael

On 2/2/19 6:32 PM, Michael Shuler wrote:
> *EOL* release for the 2.1 series. There will be no new releases from the
> 'cassandra-2.1' branch after this release.
> 
> 
> 
> I propose the following artifacts for release as 2.1.21.
> 
> sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> 




signature.asc
Description: OpenPGP digital signature

[RELEASE] Apache Cassandra 3.11.4 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.11.4.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.11 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.11.4
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.11.4
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

[RELEASE] Apache Cassandra 3.0.18 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.0.18.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.0 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.18
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.18
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

[RELEASE] Apache Cassandra 2.2.14 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.2.14.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.2 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.2.14
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-2.2.14
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

[RELEASE] Apache Cassandra 2.1.21 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.1.21.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.1 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.1.21
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-2.1.21
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

Re: CASSANDRA-14482

[Michael Shuler]

+0.5

I skimmed the jira and github diff and a few things came to mind:
- There are multiple comments about using an older jar than the latest
version.
- I did not see any performance test results to form an opinion on any
gains/caveats as a user. This was the first thing I looked for.
- I did not see any conf/cassandra.yaml comment in the diff for the
valid class_name configuration option to use.

Seems interesting, and there are comments about 4.0 being in a freeze
and all, but OK on it being non-default.

-- 
Michael

On 2/15/19 11:43 AM, Ariel Weisberg wrote:
> Hi,
> 
> I am +1 since it's an additional compressor and not the default.
> 
> Ariel
> 
> On Fri, Feb 15, 2019, at 11:41 AM, Dinesh Joshi wrote:
>> Hey folks,
>>
>> Just wanted to get a pulse on whether we can proceed with ZStd support. 
>> The consensus on the ticket was that it’s a very valuable addition 
>> without any risk of destabilizing 4.0. It’s ready to go if there aren’t 
>> any objections.
>>
>> Dinesh
>>
>> -
>> 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
> 


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

Re: Looking for common cases in cassandra fit to autoheal

[Michael Shuler]

Your request is not related to the topic of this mailing list, the
development of Apache Cassandra. Your question would be better suited
for the user@ mailing list. Your question is also quite vague, and you
might include some detail or context about what exactly you are looking
for. You may also wish to drop the unenforceable email footer or use a
personal email address, if it's appended by your mail server.

-- 
Kind regards,
Michael
http://www.pbandjelly.org/2011/03/to-whom-it-may-concern/

On 3/1/19 2:33 PM, Sundaramoorthy, Natarajan wrote:
> Can someone please reply? Thanks
>  
>  
> 
> 
> -Original Message-
> From: Sundaramoorthy, Natarajan [mailto:natarajan_sundaramoor...@optum.com] 
> Sent: Wednesday, February 27, 2019 3:17 PM
> To: dev@cassandra.apache.org
> Subject: Looking for common cases in cassandra fit to autoheal
> 
> Can someone please provide some common cases in cassandra which can be 
> candidate for autoheal? Looking for log files and issue..Both from VM and/or 
> pod world welcome...Thanks in advance for help
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 
> 
> -
> 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: Both Java 8 and Java 11 required for producing a tarball

[Michael Shuler]

On 3/6/19 7:10 PM, Stefan Miklosovic wrote:
> I am trying to build 4.0 from sources and prior to this I was doing
> 
> ant artifacts
> 
> in order to get distribution tarball to play with.
> 
> If I understand this right, if I do not run Ant with Java 11,
> java.version.8 will be true so it will skip building tarballs.

Correct. You'll get a JDK8-only jar, but no full tar artifact set.

> 1) Why would one couldnt create a tarball while running on Java 8 only?

The build system needs a dual-JDK install to build the artifacts with
support for each/both.

> 2) What is the current status of Java 11 / Java 8? Is it there just "to try
> it out if it runs with that" or are there different reasons behind it?

JDK8 runtime is the default, JDK11 runtime is optional, but supported.
Here's the JIRA with all the details:
https://issues.apache.org/jira/browse/CASSANDRA-9608

I just pushed a WIP branch to do a dual-JDK build via docker, since we
need to work on this, too. (lines may wrap:)

git clone -b tar-artifact-build
https://gitbox.apache.org/repos/asf/cassandra-builds.git

cd cassandra-builds/

docker build -t cass-build-tars -f docker/buster-image.docker docker/

docker run --rm -v `pwd`/dist:/dist `docker images -f
label=org.cassandra.buildenv=buster -q` /home/build/build-tars.sh trunk

After all that, here's my tar artifacts:

(tar-artifact-build)mshuler@hana:~/git/cassandra-builds$ ls -l dist/
total 94328
-rw-r--r-- 1 mshuler mshuler 50385890 Mar  6 21:16
apache-cassandra-4.0-SNAPSHOT-bin.tar.gz
-rw-r--r-- 1 mshuler mshuler 46198947 Mar  6 21:16
apache-cassandra-4.0-SNAPSHOT-src.tar.gz

Or you could drop a dual-JDK install on your machine, export the env
vars you found and `ant artifacts` should produce the tars :)

-- 
Kind regards,
Michael

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

Re: Cassandra repo keys are revoked

[Michael Shuler]

On 3/11/19 8:36 AM, staticp...@gmail.com wrote:
> Hello,
> 
> It appears the keys listed here are outdated. 
> https://www.apache.org/dist/cassandra/KEYS
> 
> Trying to install Casandra 311x on Ubuntu 18.0.4. The recommendation is to 
> use the keys from the link above however, the one of them is revoked. Others 
> on this page are in the same state as well. Can someone from the dev group 
> clean this up? It's a little unsettling when the official documentation - 
> http://cassandra.apache.org/download/ gives instructions to download revoked 
> keys. 
> 
> apt-key list
> 
> 
> pub   rsa4096 2014-06-16 [SCEA] [revoked: 2016-08-16]
>   7B0A 593A 9795 A964 AD57  D255 D46C 5ECB FE4B 2BDA
> uid   [ revoked] Michael Shuler 
> 
> pub   rsa4096 2009-07-15 [SC]
>   A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
> uid       [ unknown] Michael Shuler 
> uid   [ unknown] Michael Shuler 
> sub   rsa4096 2009-07-15 [E]


These are not the same keys. It looks like you possibly did a short-key
import (FE4B2BDA), as well as the long-key import, as the download
instructions indicate.  Here's my valid key:

mshuler@hana:~$ gpg --list-secret-key --fingerprint FE4B2BDA
gpg: please do a --check-trustdb
sec   rsa4096 2009-07-15 [SC]
  A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
uid   [ unknown] Michael Shuler 
uid   [ unknown] Michael Shuler 
ssb   rsa4096 2009-07-15 [E]

In 2016, someone took a list of the strong key set and uploaded keys
with faked short-key identifiers matching those of existing keys. It's a
joe job to identify the weakness of using short key identifiers. There
are thousands of these fake keys, and they've been revoked.

https://www.zdnet.com/article/pgp-security-weakness-exposed/

Drop that bogus key from apt-keys:

apt-key del D46C5ECBFE4B2BDA

This message is signed with the correct key.

-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature

Re: Cassandra repo keys are revoked

[Michael Shuler]

On 3/11/19 2:41 PM, Michael Shuler wrote:
> On 3/11/19 8:36 AM, staticp...@gmail.com wrote:
>> Hello,
>>
>> It appears the keys listed here are outdated. 
>> https://www.apache.org/dist/cassandra/KEYS
>>
>> Trying to install Casandra 311x on Ubuntu 18.0.4. The recommendation is to 
>> use the keys from the link above however, the one of them is revoked. Others 
>> on this page are in the same state as well. Can someone from the dev group 
>> clean this up? It's a little unsettling when the official documentation - 
>> http://cassandra.apache.org/download/ gives instructions to download revoked 
>> keys. 
>>
>> apt-key list
>>
>> 
>> pub   rsa4096 2014-06-16 [SCEA] [revoked: 2016-08-16]
>>   7B0A 593A 9795 A964 AD57  D255 D46C 5ECB FE4B 2BDA
>> uid   [ revoked] Michael Shuler 
>>
>> pub   rsa4096 2009-07-15 [SC]
>>       A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
>> uid   [ unknown] Michael Shuler 
>> uid   [ unknown] Michael Shuler 
>> sub   rsa4096 2009-07-15 [E]
> 
> 
> These are not the same keys. It looks like you possibly did a short-key
> import (FE4B2BDA), as well as the long-key import, as the download
> instructions indicate.  Here's my valid key:
> 
> mshuler@hana:~$ gpg --list-secret-key --fingerprint FE4B2BDA
> gpg: please do a --check-trustdb
> sec   rsa4096 2009-07-15 [SC]
>   A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
> uid   [ unknown] Michael Shuler 
> uid   [ unknown] Michael Shuler 
> ssb   rsa4096 2009-07-15 [E]
> 
> In 2016, someone took a list of the strong key set and uploaded keys
> with faked short-key identifiers matching those of existing keys. It's a
> joe job to identify the weakness of using short key identifiers. There
> are thousands of these fake keys, and they've been revoked.
> 
> https://www.zdnet.com/article/pgp-security-weakness-exposed/
> 
> Drop that bogus key from apt-keys:
> 
> apt-key del D46C5ECBFE4B2BDA
> 
> This message is signed with the correct key.

I forgot to mention that the bogus key you imported from a public key
server is *not* contained in https://www.apache.org/dist/cassandra/KEYS
- feel free to verify that independently.

-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature

Re: Choosing a supported Python 3 major version for cqlsh

[Michael Shuler]

On 3/18/19 9:06 PM, Patrick Bannister wrote:
> I recommend we pick the longest supported stable release available. That
> would be Python 3.7, which is planned to get its last release in 2023, four
> years from now.
> - Python 3.5 was planned to get its last major release yesterday
> - Python 3.6 is planned to get its last major release in December 2021,
> about three years from now
> 
> Any feedback on picking a tested Python version for cqlshlib? I'm inclined
> to focus on Python 3.7 as we push toward finishing the ticket.

The correct method of choosing this would be to target runtime
functionality on the version in the latest LTS release of the likely
most-used OS. Ubuntu 18.04 LTS comes with python-3.6.5. I would think it
highly likely that if it runs properly on 3.6, it should run on 3.7
fine. Using some 3.7-only feature/syntax and making it difficult on
people to install/use on Ubuntu LTS would be user-unfriendly.

https://packages.ubuntu.com/bionic/python3

There is not a similar CentOS package search, but I see a couple docs
say that python-3.6 is available via the SCL repository for this OS. I
do not see a 3.7 installation noted.

Shoot for the lowest common denominator in real world usage, not the
latest release from upstream. Super strong opinion, here.

-- 
Michael

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

Re: Choosing a supported Python 3 major version for cqlsh

[Michael Shuler]

On 3/18/19 9:52 PM, Michael Shuler wrote:
> On 3/18/19 9:06 PM, Patrick Bannister wrote:
>> I recommend we pick the longest supported stable release available. That
>> would be Python 3.7, which is planned to get its last release in 2023, four
>> years from now.
>> - Python 3.5 was planned to get its last major release yesterday
>> - Python 3.6 is planned to get its last major release in December 2021,
>> about three years from now
>>
>> Any feedback on picking a tested Python version for cqlshlib? I'm inclined
>> to focus on Python 3.7 as we push toward finishing the ticket.
> 
> The correct method of choosing this would be to target runtime
> functionality on the version in the latest LTS release of the likely
> most-used OS. Ubuntu 18.04 LTS comes with python-3.6.5. I would think it
> highly likely that if it runs properly on 3.6, it should run on 3.7
> fine. Using some 3.7-only feature/syntax and making it difficult on
> people to install/use on Ubuntu LTS would be user-unfriendly.
> 
> https://packages.ubuntu.com/bionic/python3
> 
> There is not a similar CentOS package search, but I see a couple docs
> say that python-3.6 is available via the SCL repository for this OS. I
> do not see a 3.7 installation noted.

No python-3.7 install in the SCL repos:
https://www.softwarecollections.org/en/scls/?search=python&policy=&repo=&order_by=-create_date&per_page=10

> Shoot for the lowest common denominator in real world usage, not the
> latest release from upstream. Super strong opinion, here.
> 

Michael

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

"4.0: TBD" -> "4.0: Est. Q4 2019"?

[Michael Shuler]

We've had 4.0 listed as TBD release date for a very long time.

Yesterday, Alexander Dejanovski got a "when's 4.0 going to release?" 
question after his repair talk and he suggested possibly Q4 2019. This 
morning Nate McCall hinted at possibly being close by ApacheCon Las 
Vegas in September. These got me thinking..


Think we can we shoot for having a 4.0 alpha/beta/rc ready to 
announce/release at ApacheCon? At that time, we'll have been frozen for 
1 year, and I think we can. We'll GA release when it's ready, but I 
think Q4 could be an realistic target.


With that said, I'd like to change "TBD" on the downloads page to "Est. 
Q4 2019". We can always push or pull the estimate, but I think it's time 
to have a goal line. This lines up with ApacheCon nicely for a preview 
release.


Any concerns or objections to editing the download page? Have some other 
goal timeframe in mind?


--
Warm regards,
Michael

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

Re: Time for a new 3.0/3.11 release?

[Michael Shuler]

On 7/1/19 3:32 PM, Blake Eggleston wrote:

Any objections to doing a new 3.0 and 3.11 release? Both branches
have accumulated a decent number of changes since their last release,
the highlights being improved merkle tree footprint, a gossip race,
and a handful of 2.1 -> 3.x upgrade bugs.


I was looking at these changelogs, recently, and time since last 
releases, when trying to fix the downloads page. Yep, it's time :)


I am about to take some time off for the rest of this week, but can roll 
up some releases & start a vote on July 8th-ish, if there's no 
objections that pop up.


--
Kind regards,
Michael

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

Re: Time for a new 3.0/3.11 release?

[Michael Shuler]

On 7/3/19 1:44 PM, aj...@apache.org wrote:

In fact there is a branch for it noted in the ticket, from which a
patch could be cut instantly, but there doesn't seem to be any point
to doing that until the feature freeze is over. Is there any sense of
timing on that? I've seen a few discussions about release process for
4.x on this list, but I haven't been able to get a sense of how long
it might be.


I see a couple different links to a couple different branches and a 
github compare with conflicts in comments in CASSANDRA-15005. I see no 
PR link, and the project doesn't use PRs in practice. There is no patch 
attached to the jira. I also see a link to an open related jira and 
discussion around that. I don't know the details of the actual 
feature/improvement, but the discussion appears (to me) to still be a 
discussion. It does not look (to me) like a finalized patch with 
completed CI links, etc. ready for someone to review. Regardless, it 
does not appear (to me) to be appropriate for 3.11.x.


The cassandra-3.11 branch is in maintenance mode, which means no new 
features. Improvements require discussion and consensus for inclusion in 
maintenance branches, in order to keep breaking changes to a minimum. 
New features should target the trunk branch (4.0), unless there is a 
previously obtained consensus to include a particular 
improvement/feature in an earlier branch. Indeed, the trunk branch has 
been frozen for new feature inclusion for quite some time, and there 
have been some limited discussions on how long this might be. "When it's 
done" is basically the current answer, while the existing in-flight, 
approved feature jiras are still in progress or under review.


With trunk frozen, this feature may need to simply wait. This is an 
example of a possible problem with a long-frozen trunk branch - new 
things may need to sit in limbo for a while, until cassandra-4.0 is 
branched and there is an opportunity to commit new features to trunk again.


I hope that helps! Some of the above is definitely my understanding and 
some subjective observation of that specific jira.


(An update on the current state of in-progress/review statuses for 4.0 
jiras from the folks working on them would be awesome! hint hint.)


Kind regards,
Michael



On Wed, Jul 3, 2019, 1:28 AM Mick Semb Wever mailto:m...@apache.org>> wrote:


Is there any chance to get CASSANDRA-15005 (ready, with PR) into a 
3.11.5 release?



I doubt it Soroka. It's not a bug and there's no patch for it, so I'd
see no reason why Michael would wait for this when he generously
finds time to cut a release.

Maybe the author and reviewer decides to push it to both 3.11.x and
4.0, but that's irrelevant to this thread.

regards, Mick

-


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

Request for review - 2 jiras for 3.0/3.11

[Michael Shuler]

Resending as a new req-for-review thread for visibility, since they look 
important to my untrained eye:


https://issues.apache.org/jira/browse/CASSANDRA-15097
https://issues.apache.org/jira/browse/CASSANDRA-15098

Michael

 Forwarded Message 
Subject: Re: Time for a new 3.0/3.11 release?
Date: Wed, 3 Jul 2019 10:38:38 -0700
From: Jay Zhuang 
Reply-To: dev@cassandra.apache.org
To: dev@cassandra.apache.org

I'd like to raise some attention for the following 2 tickets, they're
patch-ready and deployed on all our production clusters:
* CASSANDRA-15098: "Endpoints no longer owning tokens are not removed for
vnode"
  For vNode cluster, the replaced node may not be removed from gossiper
(and system.peers, every time a node restart, they will be re-populated
into gossiper from system.peers). The patch is pretty small and
straightforward.
* CASSANDRA-15097: "Avoid updating unchanged gossip state"
  I think this is a bug because it's not only causing large pending gossip
tasks, it's also causing long token-metadata update lock for large vNode
cluster.

Here is another improvement we made for vNode to avoid gossip block during
removeNode: CASSANDRA-15141. But I think it can wait until 4.x. It mostly
causes problem for 1000+ vNode clusters.

Thanks,
Jay

On Tue, Jul 2, 2019 at 10:28 PM Mick Semb Wever  wrote:




> Is there any chance to get CASSANDRA-15005 (ready, with PR) into a
> 3.11.5 release?


I doubt it Soroka. It's not a bug and there's no patch for it, so I'd see
no reason why Michael would wait for this when he generously finds time to
cut a release.

Maybe the author and reviewer decides to push it to both 3.11.x and 4.0,
but that's irrelevant to this thread.

regards,
Mick

-
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: Isn't there a workable cassandra java source for developing as other big data system?

[Michael Shuler]

You have a dirty build environment. Your path of "/cassandra-trunk/src" 
in the error and the suggestion on slack that you are trying to build 
cassandra-3.11.3 shows me you need to start over fresh. Here you go:


build docs:
http://cassandra.apache.org/doc/latest/development/ide.html

build steps pasted in slack:#cassandra:
  cd /tmp/
  git clone https://github.com/apache/cassandra.git
  cd cassandra/
  git checkout cassandra-3.11.3
  ant artifacts

BUILD SUCCESSFUL
Total time: 1 minute 32 seconds

--
Kind regards,
Michael

On 7/16/19 9:01 AM, Benedict Elliott Smith wrote:

3.11.3 compiles just fine, I have just corroborated.  Sir Jeff is in
fact a Cassandra developer, so please feel free to engage with his
question, which was designed to help diagnose your problem.



On 16 Jul 2019, at 14:54, Nimbus Lin  wrote:

To Sir Jeff: your method of "ant realclean" doesn't work, but
delete the needing library in build/jars/.

To other Cassandra's developers: Hi, is there any Cassandra's
developers here ?, would you like to tell me which version
cassandra's java source is really able to be build and run well?
or  how to solve the only  3 compile errors in  AbstractRow.java
for version 3.11.3?   If cassandra's source is not really free for
developing, then maybe it is better for me to change to other big
data system's source  to develop.

Isn't there a workable cassandra java source for developing  as
other big data system?



Thank you!

Sincerely Nimbuslin(Lin JiaXin) Mobile: 0086 180 5986 1565 Mail:
jiaxin...@live.com

-



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




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

Re: Apache Cassandra Virtual meetings

[Michael Shuler]

On 8/19/19 3:40 PM, Dinesh Joshi wrote:

shared Google Calendar


This. I adore simple gcal additions and use quite a few. Thanks for the 
suggestion!


I would also, selfishly, love to get some folks actively posting things 
to #cassandra-dev during NGCC/ApacheCon, since I cannot attend. I'll be 
offshore with no internet access for several days, but just want a way 
to keep up with conversations and presentations.


--
Warm regards,
Michael

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

Re: Contributing cassandra-diff

[Michael Shuler]

CI git polling for changes on a separate repository (if/when CI is 
needed) is probably a better way to go. I don't believe there are any 
issues with INFRA on us having discrete repos, and creating them with 
the self-help web tool is quick and easy.


Thanks for the neat looking utility!

Michael

On 8/22/19 10:33 AM, Sankalp Kohli wrote:

A different repo will be better


On Aug 22, 2019, at 6:16 AM, Per Otterström  wrote:

Very powerful tool indeed, thanks for sharing!

I believe it is best to keep tools like this in different repos since different 
tools will probably have different life cycles and tool chains. Yes, that could 
be handled in a single repo, but with different repos we'd get natural 
boundaries.

-Original Message-
From: Sumanth Pasupuleti 
Sent: den 22 augusti 2019 14:40
To: dev@cassandra.apache.org
Subject: Re: Contributing cassandra-diff

No hard preference on the repo, but just excited about this tool! Looking 
forward to employing this for upgrade testing (very timely :))


On Thu, Aug 22, 2019 at 3:38 AM Sam Tunnicliffe  wrote:

My own weak preference would be for a dedicated repo in the first
instance. If/when additional tools are contributed we should look at
co-locating common stuff, but rushing toward a monorepo would be a
mistake IMO.


On 22 Aug 2019, at 11:10, Jeff Jirsa  wrote:


I weakly prefer contrib.


On Thu, Aug 22, 2019 at 12:09 PM Marcus Eriksson


wrote:



Hi, we are about to open source our tooling for comparing two
cassandra clusters and want to get some feedback where to push it.
I think the options are: (name bike-shedding welcome)

1. create repos/asf/cassandra-diff.git 2. create a generic
repos/asf/cassandra-contrib.git where we can add

more

contributed tools in the future

Temporary location:
https://protect2.fireeye.com/url?k=e8982d07-b412e678-e8986d9c-86717
581b0b5-292bc820a13b7138&q=1&u=https%3A%2F%2Fgithub.com%2Fkrummas%2
Fcassandra-diff

Cassandra-diff is a spark job that compares the data in two
clusters -

it

pages through all partitions and reads all rows for those
partitions in both clusters to make sure they are identical. Based
on the

configuration

variable “reverse_read_probability” the rows are either read
forward or

in

reverse order.

Our main use case for cassandra-diff has been to set up two
identical clusters, transfer a snapshot from the cluster we want to
test to these clusters and upgrade one side. When that is done we
run this tool to

make

sure that 2.1 and 3.0 gives the same results. A few examples of the

bugs we

have found using this tool:

* CASSANDRA-14823: Legacy sstables with range tombstones spanning

multiple

index blocks create invalid bound sequences on 3.0+
* CASSANDRA-14803: Rows that cross index block boundaries can cause
incomplete reverse reads in some cases
* CASSANDRA-15178: Skipping illegal legacy cells can break reverse
iteration of indexed partitions

/Marcus

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



B‹CB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PØ\ÜØ[™˜K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[Ø\ÜØ[™˜K˜\XÚK›Ü™ÃBƒB


-
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: Stability of MaterializedView in 3.11.x | 4.0

[Michael Shuler]

It appears that you found the first message of the chain. I suggest 
reading the linked JIRA and the complete dev@ thread that arrived at 
this conclusion; there are loads of well formed opinions and 
information. Users of MVs *must* determine for themselves, through 
thorough testing and understanding, if they wish to use them.


Linkage:
https://issues.apache.org/jira/browse/CASSANDRA-13959
 (sub-linkage..)
 https://issues.apache.org/jira/browse/CASSANDRA-13595
 https://issues.apache.org/jira/browse/CASSANDRA-13911
 https://issues.apache.org/jira/browse/CASSANDRA-13880
 https://issues.apache.org/jira/browse/CASSANDRA-12872
 https://issues.apache.org/jira/browse/CASSANDRA-13747

Very much worth reading the complete thread:
part1: 
https://lists.apache.org/thread.html/d81a61da48e1b872d7599df4edfa8e244d34cbd591a18539f724796f@
part2: 
https://lists.apache.org/thread.html/19b7fcfd3b47f1526d6e993b3bb97f6c43e5ce204bc976ec0701cdd3@


Quick JQL for open tickets with "mv":
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20text%20~%20mv%20AND%20status%20!%3D%20Resolved

--
Michael

On 8/27/19 5:01 AM, pankaj gajjar wrote:

Hello,



concern about Materialized Views (MVs) in Cassandra. Unfortunately starting
with version 3.11, MVs are officially considered experimental and not ready
for production use, as you can read here:



http://mail-archives.apache.org/mod_mbox/cassandra-user/201710.mbox/%3cetpan.59f24f38.438f4e99.7...@apple.com%3E



Can you please someone give some productive feedback on this ? it would
help us to further implementation around the MVs in Cassandra.



Does anyone facing some critical issue or data lose or synchronization
issue ?



Regards

Pankaj.



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

Re: 4.0 alpha before apachecon?

[Michael Shuler]

Thanks for the reminder :) I have a few days of availability to prep a 
4.0 alpha release. It's an alpha, so I don't have a problem with known 
issues needing work.


I will have an internet-less period of time starting roughly Tuesday 9/3 
through about Friday 9/13. I might get lucky and have a little network 
access in the middle of that time, but I'm not counting on it.


--
Michael

On 8/28/19 10:51 AM, Jon Haddad wrote:

Hey folks,

I think it's time we cut a 4.0 alpha release.  Before I put up a vote
thread, is there a reason not to have a 4.0 alpha before ApacheCon /
Cassandra Summit?

There's a handful of small issues that I should be done for 4.0 (client
list in virtual tables, dynamic snitch improvements, fixing token counts),
I'm not trying to suggest we don't include them, but they're small enough I
think it's OK to merge them in following the first alpha.

Jon



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

Re: Builds email notifications

[Michael Shuler]

On 9/4/19 8:33 AM, Mick Semb Wever wrote:



Jenkins does have this functionality: with "E-mail Notification"
configuration under the "Post-build Actions" section. Emails are sent
when a build fails, becomes unstable or returns to stable, to a
specified ML and the authors of the breakage.

Is there any objection if I configure this for our
`cassandra-*-artifacts` builds?
And if I create a builds@ ML where these get cc'd?



Done.


Was this done by hand in Jenkins? I don't see any new commits to the job 
DSL, so the changes will get overwritten on the next cassandra-build 
push when the job configs are rebuilt.


https://gitbox.apache.org/repos/asf?p=cassandra-builds.git

Job DSL configs are in jenkins-dsl/cassandra_job_dsl_seed.groovy and DSL 
API reference can be viewed in Jenkins at 
https://builds.apache.org/plugin/job-dsl/api-viewer/index.html


This is going to be a job('Cassandra-template-artifacts') {publishers 
...} step in the template, if I recall. Not sure what email plugins are 
installed. I'd be happy to look at a PR.


--
Kind regards,
Michael

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

Re: Builds email notifications

[Michael Shuler]

On 9/4/19 9:01 AM, Mick Semb Wever wrote:



This is going to be a job('Cassandra-template-artifacts') {publishers
...} step in the template, if I recall. Not sure what email plugins are
installed. I'd be happy to look at a PR.



Quick or the dead around here :-)

It has been done manually, and a separate PR opened here: 
https://github.com/apache/cassandra-builds/pull/10

But I need some help on testing and deploying it, so a review/input would be 
most appreciated!


I'm sure we were typing at the same time :) (PR comments went to dev@, 
so we all saw that, too..)


Testing DSL changes is a PITA and needs some sort of non-functional 
meta-DSL job to configure dummy jobs. Just committing, watching for 
errors in the seed job and fixing them isn't very problematic. The 
existing jobs are not touched, if the DSL does not parse correctly, and 
the errors are usually pretty clear where the issue might be. Just do it 
in prod, once it looks about what we want. ;)


--
Michael

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

Re: 4.0 alpha before apachecon?

[Michael Shuler]

Quick update on 4.0-alpha1 builds:

- tar artifacts are published to maven[0] and sha d4054e0c tagged as 
4.0-alpha1-tentative (thanks to Marcus Eriksson for asking this morning 
to look at a cassandra-diff PR for maven publish, which gave me a fresh 
idea on fixing .m2/settings.xml for new-laptop publish problems.. Fix 
worked!)


- debs built locally, but upload to people.a.o failed, which we've 
documented a change for this to go to a new svn pre-release location, 
but I need to work this out in the release prep.


- rpm upload to new svn location, too, once debs are done.

Once I have the packages uploaded, we can start a (quick?) vote! I'll 
have some time to keep banging on the uploads later this afternoon and 
see how far I can get. I'm on a mobile hotspot with a decent connection 
at the moment :)


[0] 
https://repository.apache.org/content/repositories/orgapachecassandra-1174/org/apache/cassandra/apache-cassandra/4.0-alpha1/


Michael

On 8/29/19 2:30 PM, Joseph Lynch wrote:

We hashed this out a bit in slack and I think the current rough
consensus (please speak up if you don't agree) is that we update our
release guidelines [1] to allow API changes between alpha and beta as
the common artifact is useful for testing and we will probably end up
finding API breakage while testing that must be fixed. Benedict helped
out by creating 4.0-alpha [2] and 4.0-beta [3] fix versions so we can
track what tickets are (roughly) blocking the next alpha/beta release.
If you feel that something you're working on should block the alpha or
the beta please help out and tag it with the proper fix version. The
idea is that we know which outstanding tickets exist and are impacting
the next alpha/beta, even if we ignore it and cut anyways at least we
can separate "this has to happen before beta" from "this has to happen
before release candidates".

I think the next decision is should we just cut 4.0-alpha1 now given
that Michael has some cycles regardless of the known issues and start
using the new fix versions for the 4.0-alpha2 release? I personally
feel we should cut 4.0-alpha1 with every imaginable "expect this
release to break" disclaimer and start working towards 4.0-alpha2.

[1] 
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit
[2] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-alpha
[3] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-beta

What do people think?
-Joey

On Wed, Aug 28, 2019 at 10:58 AM Michael Shuler  wrote:


Thanks for the reminder :) I have a few days of availability to prep a
4.0 alpha release. It's an alpha, so I don't have a problem with known
issues needing work.

I will have an internet-less period of time starting roughly Tuesday 9/3
through about Friday 9/13. I might get lucky and have a little network
access in the middle of that time, but I'm not counting on it.

--
Michael

On 8/28/19 10:51 AM, Jon Haddad wrote:

Hey folks,

I think it's time we cut a 4.0 alpha release.  Before I put up a vote
thread, is there a reason not to have a 4.0 alpha before ApacheCon /
Cassandra Summit?

There's a handful of small issues that I should be done for 4.0 (client
list in virtual tables, dynamic snitch improvements, fixing token counts),
I'm not trying to suggest we don't include them, but they're small enough I
think it's OK to merge them in following the first alpha.

Jon



-
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



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

[VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

[Michael Shuler]

I propose the following artifacts for release as 4.0-alpha1.

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 24 hours (longer if needed).

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative


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

Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

[Michael Shuler]

NEWS.txt link was incorrect (fixed in template for next time).
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha1-tentative

--
Michael

On 9/5/19 3:44 PM, Michael Shuler wrote:

I propose the following artifacts for release as 4.0-alpha1.

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 24 hours (longer if needed).

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative 



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

Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

[Michael Shuler]

Thanks a bunch for the test runs. Most of those upgrade tests show 
"RuntimeError: You need to set JAVA8_HOME," so it does look like a 
systemic, generic issue to resolve there somewhere in dtest. Thanks again!


Michael

On 9/5/19 8:08 PM, Joseph Lynch wrote:

Following passed 100%: utest_compression, utests_stress, utests_long,
utests_fqltool, j8_dtests-no-vnodes

j8_unit_tests: 1 failure
- testAcquireReleaseOutbound - org.apache.cassandra.net.ConnectionTest

j11_unit_tests: 1 failure
- testIdleDisconnect - org.apache.cassandra.transport.IdleDisconnectTest

j8_dtests-with-vnodes + j11_dtests-with-vnodes: 1 failure
- test_remote_query - cql_test.TestCQLSlowQuery

j11_dtests-no-vnodes: 1 failure
- test_13595 - consistency_test.TestConsistency

j8_upgradetests-no-vnodes: 3923 failures

Other than the upgradetests (which afaik nobody has looked at for
4.0), this looks somewhat reasonable to me. I'm launching a multi-dc
cluster to do some light load testing.

-Joey


On Thu, Sep 5, 2019 at 4:03 PM Joseph Lynch  wrote:


Running all tests at 
https://circleci.com/workflow-run/79918e2a-ea8e-48a6-a38d-96cf85de27ff

Will report back with results shortly,
-Joey

On Thu, Sep 5, 2019 at 3:55 PM Jon Haddad  wrote:


+1

On Thu, Sep 5, 2019 at 3:44 PM Michael Shuler 
wrote:


I propose the following artifacts for release as 4.0-alpha1.

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative
Artifacts:

https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1177/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 24 hours (longer if needed).

[1]: CHANGES.txt:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative
[2]: NEWS.txt:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative

-
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



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

[VOTE PASSED] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

[Michael Shuler]

In the replies, I counted 2 binding +1 votes, 2 non-binding +1s, a 
non-binding -0, a couple non-binding "seems OK for alpha" affirmations 
with test results and JIRAs, and a binding desire for all the tests to pass.


Thanks for the test runs and feedback, I believe we can call this 
4.0-alpha1 vote successful. I will get the artifacts published as soon 
as I can.


--
Kind regards,
Michael

On 9/5/19 3:44 PM, Michael Shuler wrote:

I propose the following artifacts for release as 4.0-alpha1.

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 24 hours (longer if needed).

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative 



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

[RELEASE] Apache Cassandra 4.0-alpha1 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache 
Cassandra version 4.0-alpha1.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions for 4.0-alpha1:


http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha1/apache-cassandra-4.0-alpha1-bin.tar.gz

http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha1/apache-cassandra-4.0-alpha1-src.tar.gz

Debian and Redhat configurations

 sources.list:
 deb http://www.apache.org/dist/cassandra/debian 40x main

 yum config:
 baseurl=https://www.apache.org/dist/cassandra/redhat/40x/

See http://cassandra.apache.org/download/ for full install instructions. 
Since this is the first alpha release, it will not be present on the 
download page.


This is an ALPHA version! It is not intended for production use, however 
the project would appreciate your testing and feedback to make the final 
release better. As always, please pay attention to the release notes[2] 
and Let us know[3] if you were to encounter any problem.


Enjoy!

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha1
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha1

[3]: JIRA: https://issues.apache.org/jira/browse/CASSANDRA

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

Re: moving the site from SVN to git

[Michael Shuler]

I see no good reason to trash history. There are tools to make moving 
from svn to git (hopefully) painless. We used git-svn for the main c* 
source to retain history of both, which this tool uses to do migrations 
- https://github.com/nirvdrum/svn2git


Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who actually
works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)

-
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: moving the site from SVN to git

[Michael Shuler]

I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site --rootistrunk 
--no-minimize-url


..to see what I get. An svn checkout of the above url says it's only 
69M, so I suppose it's pulling all history of all time for all projects?


I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to the GitBox self service system.

I've attempted to port the site over using the tool Michael suggested, but
after a couple hours it died with this message:

command failed: r922600
git checkout -f master

If either of you (Mick or Michael) want to give svn2git a shot maybe you'll
get a different result.I think it may have been due to the large size
of the repo and the small drive on the VM I was using.  I can try it again
tomorrow with more storage to see if I get a better result.  Mick if you
want to give it a shot in the meantime that would be appreciated.

Jon

On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad  wrote:


I created an INFRA ticket here:
https://issues.apache.org/jira/browse/INFRA-19218.

On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler 
wrote:


I see no good reason to trash history. There are tools to make moving
from svn to git (hopefully) painless. We used git-svn for the main c*
source to retain history of both, which this tool uses to do migrations
- https://github.com/nirvdrum/svn2git

Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who

actually

works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)

-
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






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

Re: moving the site from SVN to git

[Michael Shuler]

I'm making progress through many periodic timeouts to svn.a.o and 
restarts, but it appears that svn2git is smart enough to pick up where 
it left off. The first commit captured at the svn path I'm specifying is 
when Cassandra was moved to a top level project at r922689 (2010-03-13). 
I don't know the old incubator path, and it's probably OK to ignore the 
few older incubator commits? I imagine it would mean starting over the 
entire import to pull in those older incubator svn commits, then 
changing the url and somehow importing the newer path on top?


I tried using a local path as the source to try to speed things up, 
after I got my first few timeouts, but that fails.


Curious if anyone really cares if we lose a few early commits - if so, I 
can try to figure out the old path and start again.


Michael

On 10/3/19 11:14 AM, Jon Haddad wrote:

Thanks for taking a look, Michael.  Hopefully you have better luck than me
:)

On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler 
wrote:


I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site --rootistrunk
--no-minimize-url

..to see what I get. An svn checkout of the above url says it's only
69M, so I suppose it's pulling all history of all time for all projects?

I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to the GitBox self service system.

I've attempted to port the site over using the tool Michael suggested,

but

after a couple hours it died with this message:

command failed: r922600
git checkout -f master

If either of you (Mick or Michael) want to give svn2git a shot maybe

you'll

get a different result.I think it may have been due to the large size
of the repo and the small drive on the VM I was using.  I can try it

again

tomorrow with more storage to see if I get a better result.  Mick if you
want to give it a shot in the meantime that would be appreciated.

Jon

On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad  wrote:


I created an INFRA ticket here:
https://issues.apache.org/jira/browse/INFRA-19218.

On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler 
wrote:


I see no good reason to trash history. There are tools to make moving
from svn to git (hopefully) painless. We used git-svn for the main c*
source to retain history of both, which this tool uses to do migrations
- https://github.com/nirvdrum/svn2git

Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who

actually

works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)

-
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






-
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: moving the site from SVN to git

[Michael Shuler]

committed! :)

https://gitbox.apache.org/repos/asf?p=cassandra-website.git

Michael

On 10/3/19 12:22 PM, Jon Haddad wrote:

I think we can safely ignore them.  Thanks for figuring this out.

On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler 
wrote:


I'm making progress through many periodic timeouts to svn.a.o and
restarts, but it appears that svn2git is smart enough to pick up where
it left off. The first commit captured at the svn path I'm specifying is
when Cassandra was moved to a top level project at r922689 (2010-03-13).
I don't know the old incubator path, and it's probably OK to ignore the
few older incubator commits? I imagine it would mean starting over the
entire import to pull in those older incubator svn commits, then
changing the url and somehow importing the newer path on top?

I tried using a local path as the source to try to speed things up,
after I got my first few timeouts, but that fails.

Curious if anyone really cares if we lose a few early commits - if so, I
can try to figure out the old path and start again.

Michael

On 10/3/19 11:14 AM, Jon Haddad wrote:

Thanks for taking a look, Michael.  Hopefully you have better luck than

me

:)

On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler 
wrote:


I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site --rootistrunk
--no-minimize-url

..to see what I get. An svn checkout of the above url says it's only
69M, so I suppose it's pulling all history of all time for all projects?

I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to the GitBox self service system.

I've attempted to port the site over using the tool Michael suggested,

but

after a couple hours it died with this message:

command failed: r922600
git checkout -f master

If either of you (Mick or Michael) want to give svn2git a shot maybe

you'll

get a different result.I think it may have been due to the large

size

of the repo and the small drive on the VM I was using.  I can try it

again

tomorrow with more storage to see if I get a better result.  Mick if

you

want to give it a shot in the meantime that would be appreciated.

Jon

On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad  wrote:


I created an INFRA ticket here:
https://issues.apache.org/jira/browse/INFRA-19218.

On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler <

mich...@pbandjelly.org>

wrote:


I see no good reason to trash history. There are tools to make moving
from svn to git (hopefully) painless. We used git-svn for the main c*
source to retain history of both, which this tool uses to do

migrations

- https://github.com/nirvdrum/svn2git

Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who

actually

works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)



-

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






-
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






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

Re: Can we kick off a release?

[Michael Shuler]

Will do! I probably won't get this done this evening, so will send out
the emails tomorrow.

Thanks,
Michael

On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
>
> Michael,
>
> Would you mind kicking off builds and starting a vote thread for the latest
> 2.2, 3.0 and 3.11 builds?
>
> Much appreciated,
> Jon

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

Re: Can we kick off a release?

[Michael Shuler]

Thanks Sam, I'm following #15193 and should catch the status change there.

Michael

On Tue, Oct 8, 2019 at 6:17 AM Sam Tunnicliffe  wrote:
>
> CASSANDRA-15193 just got +1’d yesterday and would be good to include in the 
> 3.0 and 3.11 releases. If you don’t mind holding off while I add a cqlsh test 
> and merge it, that’d be good.
>
> Thanks,
> Sam
>
> > On 7 Oct 2019, at 22:54, Michael Shuler  wrote:
> >
> > Will do! I probably won't get this done this evening, so will send out
> > the emails tomorrow.
> >
> > Thanks,
> > Michael
> >
> > On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
> >>
> >> Michael,
> >>
> >> Would you mind kicking off builds and starting a vote thread for the latest
> >> 2.2, 3.0 and 3.11 builds?
> >>
> >> Much appreciated,
> >> Jon
> >
> > -
> > 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
>

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

Re: [VOTE-2] Apache Cassandra Release Lifecycle

[Michael Shuler]

+1

-- 
Kind regards,
Michael

On Wed, Oct 9, 2019 at 9:06 AM Aleksey Yeshchenko
 wrote:
>
> +1 as a rather reasonable starting point; we can make changes to the process 
> in the future if need be.
>
> > On 8 Oct 2019, at 19:00, sankalp kohli  wrote:
> >
> > Hi,
> >We have discussed in the email thread[1] about Apache Cassandra Release
> > Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> > here[3] Please vote on it if you agree with the content of the doc [3].
> >
> > We did not proceed with the previous vote as we want to use confluence for
> > it. Here is the link for that[4]. It also mentions why we are doing this
> > vote.
> >
> > Vote will remain open for 72 hours.
> >
> > Thanks,
> > Sankalp
> >
> > [1]
> > https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > [2]
> > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> > [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> > Attachments area
> > [4]
> > https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> > 
>
>
> -
> 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: Improving our frequency of (patch) releases, and letting committers make releases

[Michael Shuler]

Noted:
https://issues.apache.org/jira/browse/CASSANDRA-14963

Fundamental current docker build flaws:
https://issues.apache.org/jira/browse/CASSANDRA-14962

Distribution changes suggested for deb/rpm:
https://issues.apache.org/jira/browse/CASSANDRA-14966
https://issues.apache.org/jira/browse/CASSANDRA-14967

..which are dependencies of repository sig changes to solve the whole 
KEYS file pain for package users, for ever and ever:

https://issues.apache.org/jira/browse/CASSANDRA-14968

There are other ASF projects using bintray metatdata signing (the repo 
metadata is *not* a release artifact). Artifact sigs uploaded to /dist/ 
and subsequent verification from KEYS seem orthogonal to repo metadata 
signatures to me. I don't see why we cannot do the same as quite a few 
other projects and use automated bintray repo signing, migrating to 
appropriate bintray repository types.


I believe some basic distribution changes would greatly help the entire 
question here, including making release builds easier for other people 
to perform, shortening the cycle times as desired. If there is some 
interest in building releases, I would like some help solving the 
problems that exist and have been in JIRA for quite some time.


--
Kind regards,
Michael

On 10/17/19 8:41 AM, Joshua McKenzie wrote:

Might make sense to split the difference and have a loose reactive policy
of "consider / discuss a potential release when any of the following are
hit":

1. something critical is merged (data loss fix, cluster down fix, etc)
2. there are  changes to the branch
3. it's been  weeks since the last patch

Maybe having triggers at reasonably fat M/N above (30/8?) would be enough
to trigger those conversations and keep momentum on releases while
respecting both the highly variable delta each change can have as well as
our variable resources to commit to release validation across the project
as contributors.


On Thu, Oct 17, 2019 at 8:23 AM Jon Haddad  wrote:


Mick's absolutely right.  Even if we had been doing more frequent releases,
it's a big risk for us to only have one person able to it in the first
place.

I also agree with Benedict. I don't think we need to be crazy strict about
windows.  As long as we tell folks they may need to import keys, I think
we're much better off than we are now.

On Thu, Oct 17, 2019 at 5:08 AM Benedict Elliott Smith <
bened...@apache.org>
wrote:


+1

We need to do something about this, and I don't mind what.  It would be
better if we cut fix releases immediately after a critical fix lands,

much

as we used to.  We've got fairly lazy about producing releases, perhaps
because many of the full-time contributors now work for organisations

that

don't really need them.

We should definitely add any willing volunteers to the KEYS file now.  I
don't personally think we need any kind of a strict policy about

modifying

it in future, except that if our release cadence drops and we have

willing

volunteers we should do it again.


  On 17/10/2019, 07:50, "Mick Semb Wever"  wrote:


 > We're still in the position where only four people in the project:
 > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a
 > release.


 Our current patch release frequency is lacking. It's been 8 months
since 3.11.4.
 This is having an impact on users and their faith in the technology.

 There is currently only one person in the community that is actively
making releases. This really doesn't inspire confidence. We really should
be cutting a patch release every 2 to 6 weeks, if critical fixes apply,
imho. And I for one would certainly like to be helping out with this
situation.

 If we choose to address this issue, there are two facets to it that
come to mind:
   1) This misnomer that committers can't cut and publish releases.
   2) That we can't make changes to the KEYS file (or that it's too
painful to do so).

 Re (1). I'm not sure where this misunderstanding came from in our
community. But the ASF policy does not prevent committers from being the
release manager. By default the only thing in the process a committer

can't

do is publish the successfully voted upon release from stage to public.
This is a one-line svn command and the last and very small action in the
release process at large. A committer can coordinate, cut, stage,

announce,

and initiate the vote on a release, which is the bulk of the work. And

the

committer can also do the final publish command if the PMC has voted that
this is ok in this community. This is all in
http://www.apache.org/legal/release-policy.html


 > Is it time to add more people to our KEYS file?
 > This will have the consequence that debian users will have to

re-add

it.


 Re (2), the problem is that changes to the KEYS file mean that debian
users have to re-import it before pulling new packages. But is that

really

worse than an 8 month or more for an earlier patch version like ".5" ?


 > But ma

Re: Improving our frequency of (patch) releases, and letting committers make releases

[Michael Shuler]

Oh! As an added bonus of migrating to proper bintray package repository 
types, we also cure the pain of users attempting to install older 
versions than the latest release, since all versions in the suite are 
installable.


--
Michael

On 10/17/19 9:47 AM, Michael Shuler wrote:

Noted:
https://issues.apache.org/jira/browse/CASSANDRA-14963

Fundamental current docker build flaws:
https://issues.apache.org/jira/browse/CASSANDRA-14962

Distribution changes suggested for deb/rpm:
https://issues.apache.org/jira/browse/CASSANDRA-14966
https://issues.apache.org/jira/browse/CASSANDRA-14967

..which are dependencies of repository sig changes to solve the whole 
KEYS file pain for package users, for ever and ever:

https://issues.apache.org/jira/browse/CASSANDRA-14968

There are other ASF projects using bintray metatdata signing (the repo 
metadata is *not* a release artifact). Artifact sigs uploaded to /dist/ 
and subsequent verification from KEYS seem orthogonal to repo metadata 
signatures to me. I don't see why we cannot do the same as quite a few 
other projects and use automated bintray repo signing, migrating to 
appropriate bintray repository types.


I believe some basic distribution changes would greatly help the entire 
question here, including making release builds easier for other people 
to perform, shortening the cycle times as desired. If there is some 
interest in building releases, I would like some help solving the 
problems that exist and have been in JIRA for quite some time.




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

[VOTE] Release Apache Cassandra 2.2.15

[Michael Shuler]

I propose the following artifacts for release as 2.2.15.

sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1179/org/apache/cassandra/apache-cassandra/2.2.15/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1179/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.15-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.15-tentative


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

[VOTE] Release Apache Cassandra 3.11.5

[Michael Shuler]

I propose the following artifacts for release as 3.11.5.

sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1184/org/apache/cassandra/apache-cassandra/3.11.5/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1184/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.5-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.5-tentative


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

[VOTE] Release Apache Cassandra 4.0-alpha2

[Michael Shuler]

I propose the following artifacts for release as 4.0-alpha2.

sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1185/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 72 hours (longer if needed).

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha2-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-tentative


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