Re: [VOTE] Release Apache Cassandra 2.2.13

[Aleksey Yeschenko]

+1

—
AY

On 25 July 2018 at 08:49:15, Michael Shuler (mich...@pbandjelly.org) 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.11.3 (Take 2)

[Aleksey Yeschenko]

+1

—
AY

On 25 July 2018 at 20:14:08, Jonathan Haddad (j...@jonhaddad.com) wrote:

+1  

On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa  wrote:  

> +1  
>  
> On Wed, Jul 25, 2018 at 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  
> >  
> >  
>  


--  
Jon Haddad  
http://www.rustyrazorblade.com  
twitter: rustyrazorblade  

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

[Aleksey Yeschenko]

+1

—
AY

On 25 July 2018 at 08:47:40, Michael Shuler (mich...@pbandjelly.org) 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: UDF

[Aleksey Yeschenko]

If this is about inclusion in 4.0, then I support it.

Technically this is *mostly* just a move+donation of some code from java-driver 
to Cassandra. Given how important this seemingly is to the board and PMC for us 
to not have the dependency on the driver, the sooner it’s gone, the better.

I’d be +1 for committing to trunk.

—
AY

On 11 September 2018 at 14:43:29, Robert Stupp (sn...@snazy.de) wrote:

The patch is technically complete - i.e. it works and does its thing.  

It's not strictly a bug fix but targets trunk. That's why I started the  
discussion.  


On 09/11/2018 02:53 PM, Jason Brown wrote:  
> Hi Robert,  
>  
> Thanks for taking on this work. Is this message a heads up that a patch is  
> coming/complete, or to spawn a discussion about including this in 4.0?  
>  
> Thanks,  
>  
> -Jason  
>  
> On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp  wrote:  
>  
>> In an effort to clean up our hygiene and limit the dependencies used by  
>> UDFs/UDAs, I think we should refactor the UDF code parts and remove the  
>> dependency to the Java Driver in that area without breaking existing  
>> UDFs/UDAs.  
>>  
>> A working prototype is in this branch: https://github.com/snazy/  
>> cassandra/tree/feature/remove-udf-driver-dep-trunk <  
>> https://github.com/snazy/cassandra/tree/feature/remove-  
>> udf-driver-dep-trunk> . The changes are rather trivial and provide 100%  
>> backwards compatibility for existing UDFs.  
>>  
>> The prototype copies the necessary parts from the Java Driver into the C*  
>> source tree to org.apache.cassandra.cql3.functions.types and adopts its  
>> usages - i.e. UDF/UDA code plus CQLSSTableWriter + StressCQLSSTableWriter.  
>> The latter two classes have a reference to UDF’s UDHelper and had to be  
>> changed as well.  
>>  
>> Some functionality, like type parsing & handling, is duplicated in the  
>> code base with this prototype - once in the “current” source tree and once  
>> for UDFs. However, unifying the code paths is not trivial, since the UDF  
>> sandbox prohibits the use of internal classes (direct and likely indirect  
>> dependencies).  
>>  
>> Robert  
>>  
>> —  
>> Robert Stupp  
>> @snazy  
>>  
>>  

--  
Robert Stupp  
@snazy  


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

Re: UDF

[Aleksey Yeschenko]

It’s my understanding that the duplicated code is being fully donated - so 
it’ll have all the usual ASF license/copyright headers when it lands in trunk. 
No special steps to take here.

—
AY

On 11 September 2018 at 19:43:58, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

Be careful when pulling in source files from the DataStax Java Driver (or 
anywhere) to make sure and respect its Apache License, Version 2.0 and keep all 
Copyright's etc with said files.  

-Jeremiah  

> On Sep 11, 2018, at 12:29 PM, Jeff Jirsa  wrote:  
>  
> +1 as well.  
>  
> On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko   
> wrote:  
>  
>> If this is about inclusion in 4.0, then I support it.  
>>  
>> Technically this is *mostly* just a move+donation of some code from  
>> java-driver to Cassandra. Given how important this seemingly is to the  
>> board and PMC for us to not have the dependency on the driver, the sooner  
>> it’s gone, the better.  
>>  
>> I’d be +1 for committing to trunk.  
>>  
>> —  
>> AY  
>>  
>> On 11 September 2018 at 14:43:29, Robert Stupp (sn...@snazy.de) wrote:  
>>  
>> The patch is technically complete - i.e. it works and does its thing.  
>>  
>> It's not strictly a bug fix but targets trunk. That's why I started the  
>> discussion.  
>>  
>>  
>> On 09/11/2018 02:53 PM, Jason Brown wrote:  
>>> Hi Robert,  
>>>  
>>> Thanks for taking on this work. Is this message a heads up that a patch  
>> is  
>>> coming/complete, or to spawn a discussion about including this in 4.0?  
>>>  
>>> Thanks,  
>>>  
>>> -Jason  
>>>  
>>> On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp  wrote:  
>>>  
>>>> In an effort to clean up our hygiene and limit the dependencies used  
>> by  
>>>> UDFs/UDAs, I think we should refactor the UDF code parts and remove  
>> the  
>>>> dependency to the Java Driver in that area without breaking existing  
>>>> UDFs/UDAs.  
>>>>  
>>>> A working prototype is in this branch: 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM&s=6lUpmmETCKbmt_zcp_DCLIxCGPjVyf7zdX0UjBVOZX4&e=
>>>>   
>>>> cassandra/tree/feature/remove-udf-driver-dep-trunk <  
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_cassandra_tree_feature_remove-2D&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g&m=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM&s=fBx64l59d8Y9Q7m9j0nNH9VvcaHc3QfoCAx4st5UJDM&e=
>>>>   
>>>> udf-driver-dep-trunk> . The changes are rather trivial and provide  
>> 100%  
>>>> backwards compatibility for existing UDFs.  
>>>>  
>>>> The prototype copies the necessary parts from the Java Driver into the  
>> C*  
>>>> source tree to org.apache.cassandra.cql3.functions.types and adopts  
>> its  
>>>> usages - i.e. UDF/UDA code plus CQLSSTableWriter +  
>> StressCQLSSTableWriter.  
>>>> The latter two classes have a reference to UDF’s UDHelper and had to  
>> be  
>>>> changed as well.  
>>>>  
>>>> Some functionality, like type parsing & handling, is duplicated in the  
>>>> code base with this prototype - once in the “current” source tree and  
>> once  
>>>> for UDFs. However, unifying the code paths is not trivial, since the  
>> UDF  
>>>> sandbox prohibits the use of internal classes (direct and likely  
>> indirect  
>>>> dependencies).  
>>>>  
>>>> Robert  
>>>>  
>>>> —  
>>>> Robert Stupp  
>>>> @snazy  
>>>>  
>>>>  
>>  
>> --  
>> Robert Stupp  
>> @snazy  
>>  
>>  
>> -  
>> 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: Revisit the proposal to use github PR

[Aleksey Yeschenko]

There are some nice benefits to GH PRs, one of them is that we could eventually 
set up CircleCI hooks that would explicitly prevent commits that don’t pass the 
tests.

But handling multiple branches would indeed be annoying. Would have to either 
submit 1 PR per branch - which is both tedious and non-atomic - or do a mixed 
approach, with a PR for the oldest branch, then a manual merge upwards. The 
latter would be kinda meh, especially when commits for different branches 
diverge.

For me personally, the current setup works quite well, and I mostly share 
Sylvain’s opinion above, for the same reasons listed.

—
AY

> On 13 Dec 2018, at 08:15, Sylvain Lebresne  wrote:
> 
> Fwiw, I personally find it very useful to have all discussion, review
> comments included, in the same place (namely JIRA, since for better or
> worse, that's what we use for tracking tickets). Typically, that means
> everything gets consistently pushed to the  commits@ mailing list, which I
> find extremely convenient to keep track of things. I also have a theory
> that the inline-comments type of review github PR give you is very
> convenient for nitpicks, shallow or spur-of-the-moment comments, but
> doesn't help that much for deeper reviews, and that it thus to favor the
> former kind of review.
> 
> Additionally, and to Benedict's point, I happen to have first hand
> experience with a PR-based process for a multi-branch workflow very similar
> to the one of this project, and suffice to say that I hate it with a
> passion.
> 
> Anyway, very much personal opinion here.
> --
> Sylvain
> 
> 
> On Thu, Dec 13, 2018 at 2:13 AM dinesh.jo...@yahoo.com.INVALID
>  wrote:
> 
>> I've been already using github PRs for some time now. Once you specify the
>> ticket number, the comments and discussion are persisted in Apache Jira as
>> work log so it can be audited if desired. However, committers usually
>> squash and commit the changes once the PR is approved. We don't use the
>> merge feature in github. I don't believe github we can merge the commit
>> into multiple branches through the UI. We would need to merge it into one
>> branch and then manually merge that commit into other branches. The big
>> upside of using github PRs is that it makes collaborating a lot easier.
>> Downside is that it makes it very difficult to follow along the progress in
>> Apache Jira. The messages that github posts back include huge diffs and are
>> aweful.
>> Dinesh
>> 
>>On Thursday, December 13, 2018, 1:10:12 AM GMT+5:30, Benedict Elliott
>> Smith  wrote:
>> 
>> Perhaps somebody could summarise the tradeoffs?  I’m a little concerned
>> about how it would work for our multi-branch workflow.  Would we open
>> multiple PRs?
>> 
>> Could we easily link with external CircleCI?
>> 
>> It occurs to me, in JIRA proposal mode, that an extra required field for a
>> permalink to GitHub for the patch would save a lot of time I spend hunting
>> for a branch in the comments.
>> 
>> 
>> 
>> 
>>> On 12 Dec 2018, at 19:20, jay.zhu...@yahoo.com.INVALID wrote:
>>> 
>>> It was discussed 1 year's ago:
>> https://www.mail-archive.com/dev@cassandra.apache.org/msg11810.html
>>> As all Apache projects are moving to gitbox:
>> https://reference.apache.org/committer/github, should we revisit that and
>> change our review/commit process to use github PR?A good example is
>> Spark:"Changes to Spark source code are proposed, reviewed and committed
>> via Github pull requests" (https://spark.apache.org/contributing.html).
>>> /jay
>> 
>> 
>> -
>> 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

Stabilising Internode Messaging in 4.0

[Aleksey Yeschenko]

I would like to propose CASSANDRA-15066 [1] - an important set of bug fixes
and stability improvements to internode messaging code that Benedict, I,
and others have been working on for the past couple of months.

First, some context.   This work started off as a review of CASSANDRA-14503
(Internode connection management is race-prone [2]), CASSANDRA-13630
(Support large internode messages with netty) [3], and a pre-4.0
confirmatory review of such a major new feature.

However, as we dug in, we realized this was insufficient. With more than 50
bugs uncovered [4] - dozens of them critical to correctness and/or
stability of the system - a substantial rework was necessary to guarantee a
solid internode messaging subsystem for the 4.0 release.

In addition to addressing all of the uncovered bugs [4] that were unique to
trunk + 13630 [3] + 14503 [2], we used this opportunity to correct some
long-existing, pre-4.0 bugs and stability issues. For the complete list of
notable bug fixes, read the comments to CASSANDRA-15066 [1]. But I’d like
to highlight a few.

# Lack of message integrity checks

It’s known that TCP checksums are too weak [5] and Ethernet CRC cannot be
relied upon [6] for integrity. With sufficient scale or time, you will hit
bit flips. Sadly, most of the time these go undetected.  Cassandra’s
replication model makes this issue much more serious, as the faulty data
can infect the cluster.

We recognised this problem, and recently introduced a fix for server-client
messages, implementing CRCs in CASSANDRA-13304 (Add checksumming to the
native protocol) [7].

But until CASSANDRA-15066 [1] lands, this is also a critical flaw
internode. We have addressed it by ensuring that no matter what, whether
you use SSL or not, whether you use internode compression or not, a
protocol level CRC is always present, for every message frame. It’s our
deep and sincere belief that shipping a new implementation of the messaging
protocol without application-level data integrity checks would be
unacceptable for a modern database.

# Lack of back-pressure and memory usage constraints

As it stands today, it’s far too easy for a single slow node to become
overwhelmed by messages from its peers.  Conversely, multiple coordinators
can be made unstable by the backlog of messages to deliver to just one
struggling node.

To address this problem, we have introduced strict memory usage constraints
that apply TCP-level back-pressure, on both outbound and inbound.  It is
now impossible for a node to be swamped on inbound, and on outbound it is
made significantly harder to overcommit resources.  It’s a simple, reliable
mechanism that drastically improves cluster stability under load, and
especially overload.

Cassandra is a mature system, and introducing an entirely new messaging
implementation without resolving this fundamental stability issue is
difficult to justify in our view.

# State of the patch, feature freeze and 4.0 timeline concerns

The patch is essentially complete, with much improved unit tests all
passing, dtests green, and extensive fuzz testing underway - with initial
results all positive.  We intend to further improve in-code documentation
and test coverage in the next week or two, and do some minor additional
code review, but we believe it will be basically good to commit in a couple
weeks.

The patch could also use some performance testing. We are hoping that our
colleagues at Netflix and new Cassandra committers Joey and Vinay will help
us with this aspect.  However, this work needs to be done regardless, so
provides no significant delay.

I would classify absolutely most of the work done in this patch as
necessary bug fixes and stability improvements - in line with the stated
goals of the feature freeze.

The only clear “feature” introduced is the expanded metrics, and virtual
tables to observe them.  If the freeze is to be strictly interpreted these
can be removed, but we think this would be unwise.

We hope that the community will appreciate and welcome these changes.
We’ve worked hard to deliver this promptly, to minimise delays to 4.0 were
these issues to be addressed piecemeal, and we sincerely believe this work
will have a positive impact on stability and performance of Cassandra
clusters for years to come.

P.S. I believe that once it’s committed, we should cut our first 4.0 alpha.
It’s about time we started this train (:

[1] https://issues.apache.org/jira/browse/CASSANDRA-15066
[2] https://issues.apache.org/jira/browse/CASSANDRA-14503
[3] https://issues.apache.org/jira/browse/CASSANDRA-13630
[4] https://gist.github.com/belliottsmith/0d12df678d8e9ab06776e29116d56b91
(incomplete list)
[5] https://www.evanjones.ca/tcp-checksums.html
[6] https://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html
[7] https://issues.apache.org/jira/browse/CASSANDRA-13304

Re: [VOTE] Release Apache Cassandra 3.11.10

[Aleksey Yeschenko]

+1

> On 29 Jan 2021, at 14:30, Ekaterina Dimitrova  wrote:
> 
> +1(nb)
> 
> On Fri, 29 Jan 2021 at 8:04, Mick Semb Wever  wrote:
> 
>>> 
>>> The vote will be open for 72 hours (longer if needed). Everyone who has
>>> tested the build is invited to vote. Votes by PMC members are considered
>>> binding. A vote passes if there are at least three binding +1s and no
>> -1's.
>>> 
>> 
>> 
>> +1
>> 
>> 
>> Checks
>> - signing correct
>> - checksums are correct
>> - source artefact builds
>> - binary artefact runs
>> - debian package runs
>> - redhat package runs
>> 
>> ( used https://github.com/apache/cassandra-builds/pull/32 )
>> 


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

[CVE-2020-17516] Apache Cassandra internode encryption enforcement vulnerability

[Aleksey Yeschenko]

CVE-2020-17516: Apache Cassandra doesn't enforce encryption setting on inbound 
internode connections

Severity:
Important

Vendor:
The Apache Software Foundation

Versions Affected:
Cassandra 2.1.0 to 2.1.22
Cassandra 2.2.0 to 2.2.19
Cassandra 3.0.0 to 3.0.23
Cassandra 3.11.0 to 3.11.9

Description:
When using ‘dc’ or ‘rack’ internode_encryption setting, a Cassandra instance 
allows both encrypted
and unencrypted connections. A misconfigured node or a malicious user can use 
the unencrypted
connection despite not being in the same rack or dc, and bypass mutual TLS 
requirement.

Mitigation:
Users of ALL versions should switch from ‘dc’ or ‘rack’ to ‘all’ 
internode_encryption setting, as they are inherently insecure
3.0.x users should additionally upgrade to 3.0.24
3.11.x users should additionally upgrade to 3.11.24

Credit:
This issue was discoverd by Jon Meredith
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [CVE-2020-17516] Apache Cassandra internode encryption enforcement vulnerability

[Aleksey Yeschenko]

Correction: 3.11.x users should upgrade to 3.11.10. 3.11.24 doesn’t exist. Yet.

> On 1 Feb 2021, at 18:22, Aleksey Yeschenko  wrote:
> 
> CVE-2020-17516: Apache Cassandra doesn't enforce encryption setting on 
> inbound internode connections
> 
> Severity:
> Important
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> Cassandra 2.1.0 to 2.1.22
> Cassandra 2.2.0 to 2.2.19
> Cassandra 3.0.0 to 3.0.23
> Cassandra 3.11.0 to 3.11.9
> 
> Description:
> When using ‘dc’ or ‘rack’ internode_encryption setting, a Cassandra instance 
> allows both encrypted
> and unencrypted connections. A misconfigured node or a malicious user can use 
> the unencrypted
> connection despite not being in the same rack or dc, and bypass mutual TLS 
> requirement.
> 
> Mitigation:
> Users of ALL versions should switch from ‘dc’ or ‘rack’ to ‘all’ 
> internode_encryption setting, as they are inherently insecure
> 3.0.x users should additionally upgrade to 3.0.24
> 3.11.x users should additionally upgrade to 3.11.24
> 
> Credit:
> This issue was discoverd by Jon Meredith
> -
> 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: March 2015 QA retrospective

[Aleksey Yeschenko]

CASSANDRA-8285
<https://issues.apache.org/jira/browse/CASSANDRA-8285> Aleksey Yeschenko
Move
all hints related tasks to hints private executor Pierre's reproducer
represents something we weren't doing, but that users are. Is that now
being tested?

That particular issue will not happen again. That class of issues can only
be tested by a sufficiently long running stress test, with plenty of
chaos-monkeying thrown in. That's essentially how it got caught - by driver
duration tests with chaos-monkeying in. It's still being run exercised by
the driver tests, and we do now run them prior to releasing stuff, so I'd
say yes - it's being tested.

Once we have our own framework, we'll migrate it there, from driver tests.

CASSANDRA-8462
<https://issues.apache.org/jira/browse/CASSANDRA-8462> Aleksey
Yeschenko Upgrading
a 2.0 to 2.1 breaks CFMetaData on 2.0 nodes Have additional dtest coverage,
need to do this in kitchen sink tests

dtests coverage would not help here, not really. It's a tricky race
condition that can only be triggered during upgrade. Would need some kind
of test that repeatedly upgrades the nodes in the cluster, again and again,
to have this caught, or else it'd be flaky at best.

The actual proper fix for that issue is the new, versioned, schema update
exchange protocol - https://issues.apache.org/jira/browse/CASSANDRA-6038 is
the ticket. That one will come with a metric ton of tests.


On Thu, Apr 9, 2015 at 11:45 AM, Ariel Weisberg  wrote:

> Repeated with sort
>*Key* *Assignee* *Summary* *Revisit reason*  CASSANDRA-8285
> <https://issues.apache.org/jira/browse/CASSANDRA-8285> Aleksey Yeschenko
> Move
> all hints related tasks to hints private executor Pierre's reproducer
> represents something we weren't doing, but that users are. Is that now
> being tested?  CASSANDRA-8462
> <https://issues.apache.org/jira/browse/CASSANDRA-8462> Aleksey
> Yeschenko Upgrading
> a 2.0 to 2.1 breaks CFMetaData on 2.0 nodes Have additional dtest coverage,
> need to do this in kitchen sink tests  CASSANDRA-8640
> <https://issues.apache.org/jira/browse/CASSANDRA-8640> Anthony Cozzie
> Paxos
> requires all nodes for CAS If PAXOS is not supposed to require all nodes
> for CAS we should be able to fail nodes or a certain number of nodes and
> still continue to CAS (test availability of CAS under failure conditions).
> No regression test.  CASSANDRA-8677
> <https://issues.apache.org/jira/browse/CASSANDRA-8677> Ariel Weisberg
> rpc_interface
> and listen_interface generate NPE on startup when specified interface
> doesn't exist Missing unit tests checking error messages for
> DatabaseDescriptor  CASSANDRA-8577
> <https://issues.apache.org/jira/browse/CASSANDRA-8577> Artem Aliev Values
> of set types not loading correctly into Pig Full set of interactions with
> PIG not validated  CASSANDRA-7704
> <https://issues.apache.org/jira/browse/CASSANDRA-7704> Benedict
> FileNotFoundException
> during STREAM-OUT triggers 100% CPU usage Streaming testing didn't
> reproduce this before release  CASSANDRA-8383
> <https://issues.apache.org/jira/browse/CASSANDRA-8383> Benedict Memtable
> flush may expire records from the commit log that are in a later memtable
> No
> regression test, no follow up ticket. Could/should this have been
> reproducable as an actual bug?  CASSANDRA-8429
> <https://issues.apache.org/jira/browse/CASSANDRA-8429> Benedict Some keys
> unreadable during compaction Running stress in CI would have caught this,
> and we're going to do that  CASSANDRA-8459
> <https://issues.apache.org/jira/browse/CASSANDRA-8459> Benedict
> "autocompaction"
> on reads can prevent memtable space reclaimation What would have reproduced
> this before release?  CASSANDRA-8499
> <https://issues.apache.org/jira/browse/CASSANDRA-8499> Benedict Ensure
> SSTableWriter cleans up properly after failure Testing error paths? Any way
> to test things in a loop to detect leaks?  CASSANDRA-8513
> <https://issues.apache.org/jira/browse/CASSANDRA-8513> Benedict
> SSTableScanner
> may not acquire reference, but will still release it when closed This had a
> user visible component, what test could have caught it befor erelease?
> CASSANDRA-8619 <https://issues.apache.org/jira/browse/CASSANDRA-8619>
> Benedict using CQLSSTableWriter gives ConcurrentModificationException What
> kind of test would have caught this before release?  CASSANDRA-8632
> <https://issues.apache.org/jira/browse/CASSANDRA-8632> Benedict
> cassandra-stress
> only generating a single unique row We rely on stress for performance
> testing, that might mean it needs real testing that demonstrates it
> generates load that looks like the load it is suppo

Re: [VOTE] Release Apache Cassandra 2.1.5

[Aleksey Yeschenko]

+1

-- 
AY

On April 27, 2015 at 17:47:17, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.5.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/Coam8e (CHANGES.txt)  
[2]: http://goo.gl/ClUkPI (NEWS.txt)  

Re: Fwd: DateTieredCompactionStrategy and static columns

[Aleksey Yeschenko]

How would it be different from creating an actual real extra table instead?

-- 
AY

On May 1, 2015 at 03:07:01, graham sanderson (gra...@vast.com) wrote:

Anyone here have an opinion; how realistic would it be to have a separate 
memtable/sstable for static columns?

Begin forwarded message:

From: Jonathan Haddad 
Subject: Re: DateTieredCompactionStrategy and static columns
Date: April 30, 2015 at 3:55:46 PM CDT
To: u...@cassandra.apache.org
Reply-To: u...@cassandra.apache.org

I suspect this will kill the benefit of DTCS, but haven't tested it to be 100% 
here.

The benefit of DTCS is that sstables are selected for compaction based on the 
age of the data, not their size.  When you mix TTL'ed data and non TTL'ed data, 
you end up screwing with the "drop the entire SSTable" optimization.  I don't 
believe this is any different just because you're mixing in static columns.  
What I think will happen is you'll end up with an sstable that's almost 
entirely TTL'ed with a few static columns that will never get compacted or 
dropped.  Pretty much the worst scenario I can think of.



On Thu, Apr 30, 2015 at 11:21 AM graham sanderson  wrote:
I have a potential use case I haven’t had a chance to prototype yet, which 
would normally be a good candidate for DTCS (i.e. data delivered in order and a 
fixed TTL), however with every write we’d also be updating some static cells 
(namely a few key/values in a static map CQL column). There could 
also be explicit deletes of keys in the static map, though that’s not 100% 
necessary.

Since those columns don’t have TTL, without reading thru the code code and/or 
trying it, I have no idea what effect this has on DTCS (perhaps it needs to use 
separate sstables for static columns). Has anyone tried this. If not I 
eventually will and will report back.

Re: Staging Branches

[Aleksey Yeschenko]

If the goal is to have branches that are always passing all the tests (aka 
‘stable’ branches), then I don’t see any workarounds,
so +1 to this.

I’d go for branch names that are less likely to be confused w/ final 
cassandra-X via autocomplete though: staging-2.0, staging-2.1, staging-trunk.

-- 
AY

On May 7, 2015 at 12:06:36, Benedict Elliott Smith (belliottsm...@datastax.com) 
wrote:

A good practice as a committer applying a patch is to build and run the  
unit tests before updating the main repository, but to do this for every  
branch is infeasible and impacts local productivity. Alternatively,  
uploading the result to your development tree and waiting a few hours for  
CI to validate it is likely to result in a painful cycle of race-to-merge  
conflicts, rebasing and waiting again for the tests to run.  

So I would like to propose a new strategy: staging branches.  

Every major branch would have a parallel branch:  

cassandra-2.0 <- cassandra-2.0_staging  
cassandra-2.1 <- cassandra-2.1_staging  
trunk <- trunk_staging  

On commit, the idea would be to perform the normal merge process on the  
_staging branches only. CI would then run on every single git ref, and as  
these passed we would fast forward the main branch to the latest validated  
staging git ref. If one of them breaks, we go and edit the _staging branch  
in place to correct the problem, and let CI run again.  

So, a commit would look something like:  

patch -> cassandra-2.0_staging -> cassandra-2.1_staging -> trunk_staging  

wait for CI, see 2.0, 2.1 are fine but trunk is failing, so  

git rebase -i trunk_staging   
fix the problem  
git rebase --continue  

wait for CI; all clear  

git checkout cassandra-2.0; git merge cassandra-2.0_staging  
git checkout cassandra-2.1; git merge cassandra-2.1_staging  
git checkout trunk; git merge trunk_staging  

This does introduce some extra steps to the merge process, and we will have  
branches we edit the history of, but the amount of edited history will be  
limited, and this will remain isolated from the main branches. I'm not sure  
how averse to this people are. An alternative policy might be to enforce  
that we merge locally and push to our development branches then await CI  
approval before merging. We might only require this to be repeated if there  
was a new merge conflict on final commit that could not automatically be  
resolved (although auto-merge can break stuff too).  

Thoughts? It seems if we want an "always releasable" set of branches, we  
need something along these lines. I certainly break tests by mistake, or  
the build itself, with alarming regularity. Fixing with merges leaves a  
confusing git history, and leaves the build broken for everyone else in the  
meantime, so patches applied after, and development branches based on top,  
aren't sure if they broke anything themselves.  

Re: Staging Branches

[Aleksey Yeschenko]

> Agreed as far as having staging branches vetoed by CI goes. Less sure about 
> the edit-commit-in-place part as said above.

Right. That’s just an implementation detail (in place vs. extra fix up 
commits). The latter is less annoying for the team in general, let’s do that 
instead.

> If we do this, we should really automate that last part (have the CI 
> environment merge the staging branch to the non-staging ones on success).

This would be nice, but would require a bot with commit access, wouldn’t it?

-- 
AY

On May 7, 2015 at 16:12:31, Sylvain Lebresne (sylv...@datastax.com) wrote:

> If one of them breaks, we go and edit the _staging branch in place to  
correct  
> the problem, and let CI run again.  

I would strongly advise against *in place* edits. If we do it, we'll end up  
in  
weird situations which will be annoying for everyone. Editing commits that  
have  
been shared is almost always a bad idea and that's especially true for  
branch  
that will have some amount of concurrency like those staging branches.  

Even if such problems are rare, better to avoid them in the first place by  
simply  
commit new "fixup" commits as we currently do. Granted this give you a  
slightly  
less clean history but to the best of my knowledge, this hasn't been a pain  
point so far.  

> wait for CI; all clear  
>  
> git checkout cassandra-2.0; git merge cassandra-2.0_staging  
> git checkout cassandra-2.1; git merge cassandra-2.1_staging  
> git checkout trunk; git merge trunk_staging  
>  
> This does introduce some extra steps to the merge process  

If we do this, we should really automate that last part (have the CI  
environment merge the staging branch to the non-staging ones on success).  

> It seems if we want an "always releasable" set of branches, we need  
something  
> along these lines.  

Agreed as far as having staging branches vetoed by CI goes. Less sure about  
the edit-commit-in-place part as said above.  

> I certainly break tests by mistake, or the build itself, with alarming  
regularity.  

I agree running tests is painful, but at least for the build, this should be  
the responsibility of the committer to build before merging. We all forget  
it from  
times to times and that's ok, but it's not ok if it's "alarmingly regular".  

--  
Sylvain  

Re: Staging Branches

[Aleksey Yeschenko]

> The is still the problem of a commit coming into the staging dir after 
> a previous commit that is being tested. 
> When the first commit is merged to the stable branch it will include 
> both tested and untested version. 

How so? We’ll only be merging up to the latest tested ref into the stable 
branch, not all of staging.

-- 
AY

On May 7, 2015 at 16:21:54, Jake Luciani (jak...@gmail.com) wrote:

The is still the problem of a commit coming into the staging dir after  
a previous commit that is being tested.  
When the first commit is merged to the stable branch it will include  
both tested and untested version.  

Let's not take releasable branches to literally, we still need to tag  
and test every "release" if there is a bad merge the CI will catch it  
just like the in your proposal  

On Thu, May 7, 2015 at 5:05 AM, Benedict Elliott Smith  
 wrote:  
> A good practice as a committer applying a patch is to build and run the  
> unit tests before updating the main repository, but to do this for every  
> branch is infeasible and impacts local productivity. Alternatively,  
> uploading the result to your development tree and waiting a few hours for  
> CI to validate it is likely to result in a painful cycle of race-to-merge  
> conflicts, rebasing and waiting again for the tests to run.  
>  
> So I would like to propose a new strategy: staging branches.  
>  
> Every major branch would have a parallel branch:  
>  
> cassandra-2.0 <- cassandra-2.0_staging  
> cassandra-2.1 <- cassandra-2.1_staging  
> trunk <- trunk_staging  
>  
> On commit, the idea would be to perform the normal merge process on the  
> _staging branches only. CI would then run on every single git ref, and as  
> these passed we would fast forward the main branch to the latest validated  
> staging git ref. If one of them breaks, we go and edit the _staging branch  
> in place to correct the problem, and let CI run again.  
>  
> So, a commit would look something like:  
>  
> patch -> cassandra-2.0_staging -> cassandra-2.1_staging -> trunk_staging  
>  
> wait for CI, see 2.0, 2.1 are fine but trunk is failing, so  
>  
> git rebase -i trunk_staging   
> fix the problem  
> git rebase --continue  
>  
> wait for CI; all clear  
>  
> git checkout cassandra-2.0; git merge cassandra-2.0_staging  
> git checkout cassandra-2.1; git merge cassandra-2.1_staging  
> git checkout trunk; git merge trunk_staging  
>  
> This does introduce some extra steps to the merge process, and we will have  
> branches we edit the history of, but the amount of edited history will be  
> limited, and this will remain isolated from the main branches. I'm not sure  
> how averse to this people are. An alternative policy might be to enforce  
> that we merge locally and push to our development branches then await CI  
> approval before merging. We might only require this to be repeated if there  
> was a new merge conflict on final commit that could not automatically be  
> resolved (although auto-merge can break stuff too).  
>  
> Thoughts? It seems if we want an "always releasable" set of branches, we  
> need something along these lines. I certainly break tests by mistake, or  
> the build itself, with alarming regularity. Fixing with merges leaves a  
> confusing git history, and leaves the build broken for everyone else in the  
> meantime, so patches applied after, and development branches based on top,  
> aren't sure if they broke anything themselves.  



--  
http://twitter.com/tjake  

Re: Staging Branches

[Aleksey Yeschenko]

Strictly speaking, the train schedule does demand that trunk, and all other 
branches, must be releasable at all times, whether you like it or not (for the 
record - I *don’t* like it, but here we are).

This, and other annoying things, is what be subscribed to tick-tock vs. 
supported branches experiment.

> We still need to run CI before we release. So what does this buy us?

Ideally (eventually?) we won’t have to run CI, including duration tests, before 
we release, because we’ll never merge anything that hadn’t passed the full 
suit, including duration tests.

That said, perhaps it’s too much change at once. We still have missing pieces 
of infrastructure, and TE is busy with what’s already back-logged. So let’s 
revisit this proposal in a few months, closer to 3.1 or 3.2, maybe?

-- 
AY

On May 7, 2015 at 16:56:07, Ariel Weisberg (ariel.weisb...@datastax.com) wrote:

Hi,  

I don't think this is necessary. If you merge with trunk, test, and someone  
gets in a head of you just merge up and push to trunk anyways. Most of the  
time the changes the other person made will be unrelated and they will  
compose fine. If you actually conflict then yeah you test again but this  
doesn't happen often.  

The goal isn't to have trunk passing every single time it's to have it pass  
almost all the time so the test history means something and when it fails  
it fails because it's broken by the latest merge.  

At this size I don't see the need for a staging branch to prevent trunk  
from ever breaking. There is a size where it would be helpful I just don't  
think we are there yet.  

Ariel  

On Thu, May 7, 2015 at 5:05 AM, Benedict Elliott Smith <  
belliottsm...@datastax.com> wrote:  

> A good practice as a committer applying a patch is to build and run the  
> unit tests before updating the main repository, but to do this for every  
> branch is infeasible and impacts local productivity. Alternatively,  
> uploading the result to your development tree and waiting a few hours for  
> CI to validate it is likely to result in a painful cycle of race-to-merge  
> conflicts, rebasing and waiting again for the tests to run.  
>  
> So I would like to propose a new strategy: staging branches.  
>  
> Every major branch would have a parallel branch:  
>  
> cassandra-2.0 <- cassandra-2.0_staging  
> cassandra-2.1 <- cassandra-2.1_staging  
> trunk <- trunk_staging  
>  
> On commit, the idea would be to perform the normal merge process on the  
> _staging branches only. CI would then run on every single git ref, and as  
> these passed we would fast forward the main branch to the latest validated  
> staging git ref. If one of them breaks, we go and edit the _staging branch  
> in place to correct the problem, and let CI run again.  
>  
> So, a commit would look something like:  
>  
> patch -> cassandra-2.0_staging -> cassandra-2.1_staging -> trunk_staging  
>  
> wait for CI, see 2.0, 2.1 are fine but trunk is failing, so  
>  
> git rebase -i trunk_staging   
> fix the problem  
> git rebase --continue  
>  
> wait for CI; all clear  
>  
> git checkout cassandra-2.0; git merge cassandra-2.0_staging  
> git checkout cassandra-2.1; git merge cassandra-2.1_staging  
> git checkout trunk; git merge trunk_staging  
>  
> This does introduce some extra steps to the merge process, and we will have  
> branches we edit the history of, but the amount of edited history will be  
> limited, and this will remain isolated from the main branches. I'm not sure  
> how averse to this people are. An alternative policy might be to enforce  
> that we merge locally and push to our development branches then await CI  
> approval before merging. We might only require this to be repeated if there  
> was a new merge conflict on final commit that could not automatically be  
> resolved (although auto-merge can break stuff too).  
>  
> Thoughts? It seems if we want an "always releasable" set of branches, we  
> need something along these lines. I certainly break tests by mistake, or  
> the build itself, with alarming regularity. Fixing with merges leaves a  
> confusing git history, and leaves the build broken for everyone else in the  
> meantime, so patches applied after, and development branches based on top,  
> aren't sure if they broke anything themselves.  
>  

Re: Staging Branches

[Aleksey Yeschenko]

I would argue that we must *at least* do the following for now.

If your patch is 2.1-based, you need to create a private git branch for that 
and a merged trunk branch ( and -trunk). And you don’t push anything 
until cassci validates all of those three branches, first.

An issue without a link to cassci for both of those branches passing doesn’t 
qualify as done to me.

That alone will be enough to catch most merge-related regressions.

Going with staging branches would also prevent any issues from concurrent 
pushes, but given the opposition, I’m fine with dropping that requirement, for 
now.

-- 
AY

On May 7, 2015 at 18:04:20, Josh McKenzie (josh.mcken...@datastax.com) wrote:

>  
> Merging is *hard*. Especially 2.1 -> 3.0, with many breaking API changes  
> (this is before 8099, which is going to make a *world* of hurt, and will  
> stick around for a year). It is *very* easy to break things, with even the  
> utmost care.  


While I agree re:merging, I'm not convinced the proportion of commits that  
will benefit from a staging branch testing pipeline is high enough to  
justify the time and complexity overhead to (what I expect are) the vast  
majority of commits that are smaller, incremental changes that won't  
benefit from this.  

On Thu, May 7, 2015 at 9:56 AM, Ariel Weisberg   
wrote:  

> Hi,  
>  
> Sorry didn't mean to blame or come off snarky. I just it is important not  
> to #include our release process from somewhere else. We don't have to do  
> anything unless it is necessary to meet some requirement of what we are  
> trying to do.  
>  
> So the phrase "Trunk is always releasable" definitely has some wiggle room  
> because you have to define what your release process is.  
>  
> If your requirement is that at any time you be able to tag trunk and ship  
> it within minutes then yes staging branches help solve that problem.  
>  
> The reality is that the release process always takes low single digit days  
> because you branch trunk, then wait for longer running automated tests to  
> run against that branch. If there happens to be a failure you may have to  
> update the branch, but you have bounded how much brokeness sits between you  
> and release already. We also don't have a requirement to be able to ship  
> nigh immediately.  
>  
> We can balance the cost of extra steps and process against the cost of  
> having to delay some releases some of the time by a few days and pick  
> whichever is more important. We are stilly reducing the amount of time it  
> takes to get a working release. Reduced enough that we should be able to  
> ship every month without difficulty. I have been on a team roughly our size  
> that shipped every three weeks without having staging branches. Trunk broke  
> infrequently enough it wasn't an issue and when it did break it wasn't hard  
> to address. The real pain point was flapping tests and the diffusion of  
> responsibility that prevented them from getting fixed.  
>  
> If I were trying to sell staging branches I would work the angle that I  
> want to be able to bisect trunk without coming across broken revisions.  
> Then balance the value of that with the cost of the process.  
>  
> Ariel  
>  
> On Thu, May 7, 2015 at 10:41 AM, Benedict Elliott Smith <  
> belliottsm...@datastax.com> wrote:  
>  
> > It's a bit unfair to characterize Aleksey as subscribing to a cargo cult.  
> > *We* agreed to define the new release process as "keeping trunk always  
> > releasable".  
> >  
> > Your own words that catalyzed this: "If we release off trunk it is pretty  
> > much necessary for trunk to be in a releasable state all the time"  
> >  
> > It is possible we have been imprecise in our discussions, and people have  
> > agreed to different things. But it does seem to me we agreed to the  
> > position Aleksey is taking, and he is not blindly following some other  
> > process that is not ours.  
> >  
> > On Thu, May 7, 2015 at 3:25 PM, Ariel Weisberg <  
> > ariel.weisb...@datastax.com>  
> > wrote:  
> >  
> > > Hi,  
> > >  
> > > Whoah. Our process is our own. We don't have to subscribe to any cargo  
> > cult  
> > > book buying seminar giving process.  
> > >  
> > > And whatever we do we can iterate and change until it works for us and  
> > > solves the problems we want solved.  
> > >  
> > > Ariel  
> > >  
> > > On Thu, May 7, 2015 at 10:13 AM, Aleksey Yeschenko  >  
> > > wrote:  
> > >  
> > > > Strictly speaking, the train schedule does demand that trunk, and all  
&g

Re: Requiring Java 8 for C* 3.0

[Aleksey Yeschenko]

The switch will necessarily hurt 3.0 adoption, but I think we’ll live. To me, 
the benefits (mostly access to lambdas and default methods, tbh) slightly 
outweigh the downsides.

+0.1

-- 
AY

On May 7, 2015 at 19:22:53, Gary Dusbabek (gdusba...@gmail.com) wrote:

+1  

On Thu, May 7, 2015 at 11:09 AM, Jonathan Ellis  wrote:  

> We discussed requiring Java 8 previously and decided to remain Java  
> 7-compatible, but at the time we were planning to release 3.0 before Java 7  
> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java  
> 7 EOL, I think it's worth reopening this discussion.  
>  
> If we require 8, then we can use lambdas, LongAdder, StampedLock, Streaming  
> collections, default methods, etc. Not just in 3.0 but over 3.x for the  
> next year.  
>  
> If we don't, then people can choose whether to deploy on 7 or 8 -- but the  
> vast majority will deploy on 8 simply because 7 is no longer supported  
> without a premium contract with Oracle. 8 also has a more advanced G1GC  
> implementation (see CASSANDRA-7486).  
>  
> I think that gaining access to the new features in 8 as we develop 3.x is  
> worth losing the ability to run on a platform that will have been EOL for a  
> couple months by the time we release.  
>  
> --  
> Jonathan Ellis  
> Project Chair, Apache Cassandra  
> co-founder, http://www.datastax.com  
> @spyced  
>  

Re: Staging Branches

[Aleksey Yeschenko]

> Agreed. I would like to wait and see how we do without extra branches for 
> a release or two. That will give us a better idea of how much pain the 
> extra steps will protect us from.

In the meantime can we agree on having cassci to validate personal merged 
branches before pushing either, in case of non-trunk patches?

That doesn’t require any more infra setup, and with the delta between 2.0 and 
2.1, and 2.1 and 3.0, and, sometimes, 2.0 and 3.0, doing so is crucial.

I know that at least Sam does that already, but I want it to be an agreed upon 
procedure.

Oh, ans as Benedict said, it’d be nice for all those commits to start including 
CHANGES.txt and the commit messages, both. With the developers total/committers 
ratio that we have now, it helps the process scale better.

-- 
AY

On May 7, 2015 at 19:02:36, Benedict Elliott Smith (belliottsm...@datastax.com) 
wrote:

>  
> I would argue that we must *at least* do the following for now.  


If we get this right, the extra staging branches can certainly wait to be  
assessed until later.  

IMO, any patch should have a branch in CI for each affected mainline  
branch, and should have the commit completely wired up (CHANGES.txt, commit  
message, the works), so that it can be merged straight in. If it conflicts  
significantly, it can be bumped back to the author/reviewer to refresh.  

On Thu, May 7, 2015 at 4:16 PM, Aleksey Yeschenko   
wrote:  

> I would argue that we must *at least* do the following for now.  
>  
> If your patch is 2.1-based, you need to create a private git branch for  
> that and a merged trunk branch ( and -trunk). And you don’t push  
> anything until cassci validates all of those three branches, first.  
>  
> An issue without a link to cassci for both of those branches passing  
> doesn’t qualify as done to me.  
>  
> That alone will be enough to catch most merge-related regressions.  
>  
> Going with staging branches would also prevent any issues from concurrent  
> pushes, but given the opposition, I’m fine with dropping that requirement,  
> for now.  
>  
> --  
> AY  
>  
> On May 7, 2015 at 18:04:20, Josh McKenzie (josh.mcken...@datastax.com)  
> wrote:  
>  
> >  
> > Merging is *hard*. Especially 2.1 -> 3.0, with many breaking API changes  
> > (this is before 8099, which is going to make a *world* of hurt, and will  
> > stick around for a year). It is *very* easy to break things, with even  
> the  
> > utmost care.  
>  
>  
> While I agree re:merging, I'm not convinced the proportion of commits that  
> will benefit from a staging branch testing pipeline is high enough to  
> justify the time and complexity overhead to (what I expect are) the vast  
> majority of commits that are smaller, incremental changes that won't  
> benefit from this.  
>  
> On Thu, May 7, 2015 at 9:56 AM, Ariel Weisberg <  
> ariel.weisb...@datastax.com>  
> wrote:  
>  
> > Hi,  
> >  
> > Sorry didn't mean to blame or come off snarky. I just it is important not  
> > to #include our release process from somewhere else. We don't have to do  
> > anything unless it is necessary to meet some requirement of what we are  
> > trying to do.  
> >  
> > So the phrase "Trunk is always releasable" definitely has some wiggle  
> room  
> > because you have to define what your release process is.  
> >  
> > If your requirement is that at any time you be able to tag trunk and ship  
> > it within minutes then yes staging branches help solve that problem.  
> >  
> > The reality is that the release process always takes low single digit  
> days  
> > because you branch trunk, then wait for longer running automated tests to  
> > run against that branch. If there happens to be a failure you may have to  
> > update the branch, but you have bounded how much brokeness sits between  
> you  
> > and release already. We also don't have a requirement to be able to ship  
> > nigh immediately.  
> >  
> > We can balance the cost of extra steps and process against the cost of  
> > having to delay some releases some of the time by a few days and pick  
> > whichever is more important. We are stilly reducing the amount of time it  
> > takes to get a working release. Reduced enough that we should be able to  
> > ship every month without difficulty. I have been on a team roughly our  
> size  
> > that shipped every three weeks without having staging branches. Trunk  
> broke  
> > infrequently enough it wasn't an issue and when it did break it wasn't  
> hard  
> > to address. The real pain point was flapping tests and the diffusion of  
> > responsibil

Re: Staging Branches

[Aleksey Yeschenko]

> +100 from me, but why the exception for trunk?

Sorry, just my poor wording again. No exception for trunk. What I meant by 
‘non-trunk’ patches was patches that originated in 2.0 or 2.1 branches. ‘trunk’ 
patches (today) would be 3.0-only features and fixes, and these need no 
upstream merging, b/c trunk is already as upstream as it gets.

Of course you’d still have cassci vet the trunk branch itself - we already 
should be doing that.

-- 
AY

On May 7, 2015 at 20:30:07, Ryan McGuire (r...@datastax.com) wrote:

> In the meantime can we agree on having cassci to validate personal merged  
branches before pushing either, in case of non-trunk patches?  

+100 from me, but why the exception for trunk? Wouldn't it be easier to  
wait for the dev branch tests to pass and then do all the merging at once  
(2.0, 2.1,3.0, trunk)?  

On Thu, May 7, 2015 at 1:21 PM, Aleksey Yeschenko   
wrote:  

> > Agreed. I would like to wait and see how we do without extra branches  
> for  
> > a release or two. That will give us a better idea of how much pain the  
> > extra steps will protect us from.  
>  
> In the meantime can we agree on having cassci to validate personal merged  
> branches before pushing either, in case of non-trunk patches?  
>  
> That doesn’t require any more infra setup, and with the delta between 2.0  
> and 2.1, and 2.1 and 3.0, and, sometimes, 2.0 and 3.0, doing so is crucial.  
>  
> I know that at least Sam does that already, but I want it to be an agreed  
> upon procedure.  
>  
> Oh, ans as Benedict said, it’d be nice for all those commits to start  
> including CHANGES.txt and the commit messages, both. With the developers  
> total/committers ratio that we have now, it helps the process scale better.  
>  
> --  
> AY  
>  
> On May 7, 2015 at 19:02:36, Benedict Elliott Smith (  
> belliottsm...@datastax.com) wrote:  
>  
> >  
> > I would argue that we must *at least* do the following for now.  
>  
>  
> If we get this right, the extra staging branches can certainly wait to be  
> assessed until later.  
>  
> IMO, any patch should have a branch in CI for each affected mainline  
> branch, and should have the commit completely wired up (CHANGES.txt, commit  
> message, the works), so that it can be merged straight in. If it conflicts  
> significantly, it can be bumped back to the author/reviewer to refresh.  
>  
> On Thu, May 7, 2015 at 4:16 PM, Aleksey Yeschenko   
> wrote:  
>  
> > I would argue that we must *at least* do the following for now.  
> >  
> > If your patch is 2.1-based, you need to create a private git branch for  
> > that and a merged trunk branch ( and -trunk). And you don’t push  
> > anything until cassci validates all of those three branches, first.  
> >  
> > An issue without a link to cassci for both of those branches passing  
> > doesn’t qualify as done to me.  
> >  
> > That alone will be enough to catch most merge-related regressions.  
> >  
> > Going with staging branches would also prevent any issues from concurrent  
> > pushes, but given the opposition, I’m fine with dropping that  
> requirement,  
> > for now.  
> >  
> > --  
> > AY  
> >  
> > On May 7, 2015 at 18:04:20, Josh McKenzie (josh.mcken...@datastax.com)  
> > wrote:  
> >  
> > >  
> > > Merging is *hard*. Especially 2.1 -> 3.0, with many breaking API  
> changes  
> > > (this is before 8099, which is going to make a *world* of hurt, and  
> will  
> > > stick around for a year). It is *very* easy to break things, with even  
> > the  
> > > utmost care.  
> >  
> >  
> > While I agree re:merging, I'm not convinced the proportion of commits  
> that  
> > will benefit from a staging branch testing pipeline is high enough to  
> > justify the time and complexity overhead to (what I expect are) the vast  
> > majority of commits that are smaller, incremental changes that won't  
> > benefit from this.  
> >  
> > On Thu, May 7, 2015 at 9:56 AM, Ariel Weisberg <  
> > ariel.weisb...@datastax.com>  
> > wrote:  
> >  
> > > Hi,  
> > >  
> > > Sorry didn't mean to blame or come off snarky. I just it is important  
> not  
> > > to #include our release process from somewhere else. We don't have to  
> do  
> > > anything unless it is necessary to meet some requirement of what we are  
> > > trying to do.  
> > >  
> > > So the phrase "Trunk is always releasable" definitely has some wiggle  
> > room  
> > > because you have to define what your rel

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Aleksey Yeschenko]

Releasing a 2.2 now is indeed a good idea, +1 to that.

Regarding EOLs, however, there I don’t feel like dropping the planned 3.0.x 
stabilisation branch is necessary.

I’d also say that having both 2.1.x and 2.2.x LTS branches is both 1) very 
cheap for us and 2) is not really needed.

Here is why:

1) The new features in 2.2 don’t modify the core heavily - unlike 3.0 would. 
Hence 2.1 patches almost always apply cleanly to trunk, not causing us 
headaches as developers

2) New features being almost entirely opt-in, if you don’t use them, you can 
jump from 2.1 to 2.2 without significant stability degradation. It’s only the 
new features, in this case, that require stabilising. Messaging formats haven’t 
changed, sstable format is the same, the storage engine has had no 
modifications.

So, maintaining both 2.1 and 2.2 LTS branches, while cheap for us, is 
unnecessary, and would cause avoidable fragmentation.

3.0, however, will require a stabilisation period, just by the nature of it. It 
might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if 
you go purely by the feature list, but in fact the opposite is true.

So I’d suggest a third EOL alternative. We leave the planned 3.0.x 
stabilisation branch in place - we are going to need it. And we have the new 
2.2 branch inherit 2.1’s LTS status, and retire 2.1 itself earlier than 
planned. In other words,

1) 2.0.x branch goes EOL when 3.0 is out, as planned
2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage 
engine
3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, 
get the same stability as with 2.1.7, plus a few new features

With that addition, +100 to the idea of having a 2.2 ASAP.

-- 
AY

On May 10, 2015 at 17:28:05, Phil Yang (ud1...@gmail.com) wrote:

How about naming it 2.9 as a development preview version before 3.0? If  
this version and 3.0 are close in functionality, it is not a good idea that  
the two version number have a huge difference. And after 3.0 being shipped,  
I think we should stop maintaining this version because of the similarity  
with 3.0 and still maintain 2.1.x since 2.1.0 was shipped 8 months ago and  
just have a "maybe product ready" version 2.1.5.  


2015-05-10 20:17 GMT+08:00 :  

> To clarify, I'm +1ing the creation of a stable 2.2 branch, prior to  
> 8099, in order to not block certain key features, as mentioned. Neutral  
> on any additional nuances.  
>  
> -Tupshin  
>  
> On Sun, May 10, 2015, at 08:05 AM, tups...@tupshin.com wrote:  
> > +1  
> >  
> > On Sat, May 9, 2015, at 06:38 PM, Jonathan Ellis wrote:  
> > > *With 8099 still weeks from being code complete, and even longer from  
> > > being  
> > > stable, I’m starting to think we should decouple everything that’s  
> > > already  
> > > done in trunk from 8099. That is, ship 2.2 ASAP with - Windows  
> support-  
> > > UDF- Role-based permissions - JSON- Compressed commitlog- Off-heap row  
> > > cache- Message coalescing on by default- Native protocol v4and let 3.0  
> > > ship  
> > > with 8099 and a few things that finish by then (vnode compaction,  
> > > file-based hints, maybe materialized views).Remember that we had 7  
> > > release  
> > > candidates for 2.1. Splitting 2.2 and 3.0 up this way will reduce the  
> > > risk  
> > > in both 2.2 and 3.0 by separating most of the new features from the big  
> > > engine change. We might still have a lot of stabilization to do for  
> > > either  
> > > or both, but at the least this lets us get a head start on testing the  
> > > new  
> > > features in 2.2.This does introduce a new complication, which is that  
> > > instead of 3.0 being an unusually long time after 2.1, it will be an  
> > > unusually short time after 2.2. The “default” if we follow established  
> > > practice would be to*  
> > >  
> > > -  
> > >  
> > > EOL 2.1 when 3.0 ships, and maintain 2.2.x and 3.0.x stabilization  
> > > branches  
> > >  
> > >  
> > > *But, this is probably not the best investment we could make for our  
> > > users  
> > > since 2.2 and 3.0 are relatively close in functionality. I see a  
> couple  
> > > other options without jumping to 3 concurrent stabilization series:*  
> > >  
> > >  
> > >  
> > > * - Extend 2.1.x series and 2.2.x until 4.0, but skip 3.0.x  
> stabilization  
> > > series in favor of tick-tock 3.x- Extend 2.1.x series until 4.0, but  
> stop  
> > > 2.2.x when 3.0 ships in favor of developing 3.0.x insteadThoughts?*  
> > >  
> > > --  
> > > Jonathan Ellis  
> > > Project Chair, Apache Cassandra  
> > > co-founder, http://www.datastax.com  
> > > @spyced  
>  



--  
Thanks,  
Phil Yang  

Re: Wrap around CQL queries for token ranges?

[Aleksey Yeschenko]

That was an intentional decision on our side. Have a look at 
https://issues.apache.org/jira/browse/CASSANDRA-5573 - Sylvain’s comment in 
particular.

-- 
AY

On May 11, 2015 at 20:05:54, Brian O'Neill (b...@alumni.brown.edu) wrote:

Looks like the java-driver supplies the hack I need. (TokenRange.unwrap)  

I¹ll leave it to you guys to decide if it is more elegant to support  
wrapping natively in CQL.  

-brian  

---  
Brian O'Neill  
Chief Technology Officer  
Health Market Science, a LexisNexis Company  
215.588.6024 Mobile € @boneill42   


This information transmitted in this email message is for the intended  
recipient only and may contain confidential and/or privileged material. If  
you received this email in error and are not the intended recipient, or the  
person responsible to deliver it to the intended recipient, please contact  
the sender at the email above and delete this email and any attachments and  
destroy any copies thereof. Any review, retransmission, dissemination,  
copying or other use of, or taking any action in reliance upon, this  
information by persons or entities other than the intended recipient is  
strictly prohibited.  



From: Brian O'Neill   
Date: Monday, May 11, 2015 at 12:32 PM  
To: "dev@cassandra.apache.org"   
Subject: Wrap around CQL queries for token ranges?  


I was doing some testing around data locality today (and adding it to our  
distributed processing layer).  
I retrieved all of the TokenRanges back using:  
tokenRanges = metadata.getTokenRanges(keyspace, localhost)  


And when I spun through the token ranges returned, I ended up missing  
records.  
The root cause was the ³edge case² where the ring wraps around.  

It generated the following CQL query: (using the last token range)  

cqlsh> SELECT token(id),id,name FROM test_keyspace.test_table WHERE  
token(id)>8743874685407455894 AND token(id)<=-8851282698028303387;  

(0 rows)  

cqlsh> SELECT token(id),id,name FROM test_keyspace.test_table WHERE  
token(id)<=-8851282698028303387 AND token(id)>-9223372036854775808;  

token(id) | id | name  
--++  
-9157060164899361011 | 23 | name23  
-9108684050423740263 | 53 | name53  
-9084883821289052775 | 91 | name91  
(3 rows)  

NOTE: If I use Long.MAX_VALUE instead, I get the records.  

I can hack this at the app layer, to issue separate queries for the wrap  
around case, but I wonder if CQL should support wrap around queries???  

-brian  

---  
Brian O'Neill  
Chief Technology Officer  
Health Market Science, a LexisNexis Company  
215.588.6024 Mobile € @boneill42   


This information transmitted in this email message is for the intended  
recipient only and may contain confidential and/or privileged material. If  
you received this email in error and are not the intended recipient, or the  
person responsible to deliver it to the intended recipient, please contact  
the sender at the email above and delete this email and any attachments and  
destroy any copies thereof. Any review, retransmission, dissemination,  
copying or other use of, or taking any action in reliance upon, this  
information by persons or entities other than the intended recipient is  
strictly prohibited.  

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Aleksey Yeschenko]

> So I think EOLing 2.0.x when 2.2 comes 
> out is reasonable, especially considering that 2.2 is realistically a month 
> or two away even if we can get a beta out this week. 

Given how long 2.0.x has been alive now, and the stability of 2.1.x at the 
moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t 
argue here.

> If push comes to shove I'm okay being ambiguous here, but can we just say 
> "when 3.0 is released we EOL 2.1?" 

Under our current projections, that’ll be exactly “a few months after 2.2 is 
released”, so I’m again fine with it.

> P.S. The area I'm most concerned about introducing destabilizing changes in 
> 2.2 is commitlog

So long as you don’t you compressed CL, you should be solid. You are probably 
solid even if you do use compressed CL.

Here are my only concerns:

1. New authz are not opt-in. If a user implements their own custom 
authenticator or authorized, they’d have to upgrade them sooner. The test 
coverage for new authnz, however, is better than the coverage we used to have 
before.

2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In 
practice, however, I highly doubt that anybody using CQL2 is also someone who’d 
already switch to 2.1.x or 2.2.x.


-- 
AY

On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote:

On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko   
wrote:  

> 3.0, however, will require a stabilisation period, just by the nature of  
> it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and  
> 2.2 are, if you go purely by the feature list, but in fact the opposite is  
> true.  
>  

You are probably right. But let me push back on some of the extra work  
you're proposing just a little:  

1) 2.0.x branch goes EOL when 3.0 is out, as planned  
>  

3.0 was, however unrealistically, planned for April. And it's moving the  
goalposts to say the plan was always to keep 2.0.x for three major  
releases; the plan was to EOL with "the next major release after 2.1"  
whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes  
out is reasonable, especially considering that 2.2 is realistically a month  
or two away even if we can get a beta out this week.  

2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new  
> storage engine  
>  

Yes.  


> 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to  
> 2.2, get the same stability as with 2.1.7, plus a few new features  
>  

If push comes to shove I'm okay being ambiguous here, but can we just say  
"when 3.0 is released we EOL 2.1?"  

P.S. The area I'm most concerned about introducing destabilizing changes in  
2.2 is commitlog; I will follow up to make sure we have a solid QA plan  
there.  

--  
Jonathan Ellis  
Project Chair, Apache Cassandra  
co-founder, http://www.datastax.com  
@spyced  

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Aleksey Yeschenko]

The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717 will 
be pushed shortly after 8099, and break things.

-- 
AY

On May 11, 2015 at 23:29:13, Alex Popescu (al...@datastax.com) wrote:

On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  wrote:  

> Instead of labeling it 2.2, I’d like to propose to label it 3.0 (so  
> basically just move 8099 to 3.1).  
> In the end it’s ”only a label”. But there are a lot of new user-facing  
> features in it that justifies a major release.  
>  

+1 on labeling the proposed 2.2 as 3.0 and moving (8099 to 3.1)  

1. Tons of new features that feel more than just a 2.2  
2. The majority of features planned for 3.0 are actually ready for this  
version  
3. in order to avoid compatiblity questions (and version compatibility  
matrices), the drivers developed by DataStax have  
followed the Cassandra versions so far. The Python and C# drivers are  
already at 2.5 as they added some major features.  

Renaming the proposed 2.2 as 3.0 would allow us to continue to use this  
versioning policy until all drivers are supporting  
the latest Cassandra version and continue to not require a user to check  
a compatibility matrix.  


--  
Bests,  

Alex Popescu | @al3xandru  
Sen. Product Manager @ DataStax  

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Aleksey Yeschenko]

Can you not alter the version of the drivers, though? 3.0 to 2.2?

-- 
AY

On May 11, 2015 at 23:38:00, Alex Popescu (al...@datastax.com) wrote:

On Mon, May 11, 2015 at 1:32 PM, Aleksey Yeschenko   
wrote:  

> The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717  
> will be pushed shortly after 8099, and break things.  


Apologies, I didn't mean they are ready today. Version-wise, renaming this  
proposed 2.2 to 3.0 would allow us to maintain a  
versioning policy that made things quite simple for users: Cassandra  
version == driver version.  


--  
Bests,  

Alex Popescu | @al3xandru  
Sen. Product Manager @ DataStax  

Re: [VOTE] Release Apache Cassandra 2.0.15

[Aleksey Yeschenko]

+1

-- 
AY

On May 13, 2015 at 19:00:45, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.0.15.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/1hZh8a (CHANGES.txt)  
[2]: http://goo.gl/weKkFT (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.0-beta1

[Aleksey Yeschenko]

+1

-- 
AY

On May 18, 2015 at 05:35:23, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.0-beta1.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

Since this is beta, the vote will be open for 24 hours.  

[1]: http://goo.gl/YsRffc (CHANGES.txt)  
[2]: http://goo.gl/jFb87y (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.1.6

[Aleksey Yeschenko]

+1

-- 
AY

On June 5, 2015 at 18:07:11, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.6.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/lTrkx1 (CHANGES.txt)  
[2]: http://goo.gl/93P7VA (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.0-rc1

[Aleksey Yeschenko]

+1

-- 
AY

On June 5, 2015 at 18:28:28, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.0-rc1.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/B6LLNm (CHANGES.txt)  
[2]: http://goo.gl/mr638q (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.0.16

[Aleksey Yeschenko]

+1

-- 
AY

On June 19, 2015 at 15:56:38, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.0.16.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/stVnvu (CHANGES.txt)  
[2]: http://goo.gl/nkYblK (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.1.7

[Aleksey Yeschenko]

+1

-- 
AY

On June 19, 2015 at 16:01:04, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.7.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/FuQlgX (CHANGES.txt)  
[2]: http://goo.gl/zeB2Os (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.1.8

[Aleksey Yeschenko]

+1

-- 
AY

On July 6, 2015 at 20:05:47, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.8.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/BFYiEO (CHANGES.txt)  
[2]: http://goo.gl/24XaPp (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.0-rc2

[Aleksey Yeschenko]

+1

-- 
AY

On July 7, 2015 at 01:10:30, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.0-rc2.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/C1QdHh (CHANGES.txt)  
[2]: http://goo.gl/NPABEq (NEWS.txt)  

Re: Discussion: reviewing larger tickets

[Aleksey Yeschenko]

I’m with Sylvain and Sam on this, as a person drinking from the JIRA firehose.

I’m fine with review happening on GH so long as it’s also mirrored on JIRA.

Someone could write a script that would automate this (take a PR, convert it to 
a JIRA-formatted comment).

—
AY

On July 9, 2015 at 15:54:48, Benedict Elliott Smith 
(belliottsm...@datastax.com) wrote:

While that approach optimises for people paying close attention to the JIRA  
firehose, it is less optimal for people trying to figure out after the fact  
what is going on wrt certain tickets. Some of the more complex tickets I  
cannot make head or tails of even when I was one of the main participants.  

It also doesn't promote translating these discussions into code comments  
for the permanent record. From my POV, though, I guess I can stick to my  
current approach and just cut/paste the results into JIRA if we want every  
nuance replicated there.  

On Thu, Jul 9, 2015 at 12:19 PM, Sam Tunnicliffe  wrote:  

> I'm +1 with Sylvain here; keeping the discussions open, accessible to all  
> and persistent seems more valuable than reducing the friction for  
> contributors & reviewers.  
>  
> Personally, my workflow involves following the JIRA firehose, so I tend to  
> be aware (at least to some degree) of both "major" & "minor" comments, a  
> lot of which I would surely miss were they to move GH. I also agree with  
> the point that what seems minor to one viewer may raise red flags with  
> another.  
>  
> That said, I often have offline conversations (from both the  
> reviewer/contributor perspective) around minor-ish things like naming, nits  
> and so forth. At the moment these are a) not recorded & b) marginally more  
> difficult to do asynchronously. So I think in future I may personally start  
> using a GH branch for such remarks, though I don't think that should become  
> a mandated part of The Process.  
>  
> Sam  
>  
> On Thu, Jul 9, 2015 at 11:47 AM, Sylvain Lebresne   
> wrote:  
>  
> > > One downside to that approach is that the extra barrier to entry makes  
> it  
> > > more of a 1-on-1 conversation rather than an open discussion via JIRA  
> > > comments.  
> >  
> > Yes, and I really worry about that. And I (see the "I", that's a totally  
> > personal opinion) value keeping discussions as open as possible much more  
> > than  
> > additional convenience for making and processing review comments. I'll  
> > admit  
> > however that the current use of JIRA comments for reviews has never  
> burden  
> > me  
> > all that much so I don't see all that much convenience to be gained by  
> > changing  
> > that process (but then again, I'm happy using vim for my development, so  
> > your  
> > mileage probably varies).  
> >  
> > Typically, if we talk of work-flow, I personally read JIRA updates fairly  
> > religiously, which allows me to keep vaguely up to date on what's going  
> on  
> > with  
> > reviews even for tickets I'm a priori not involved with. I consider it a  
> > good,  
> > healthy thing. If we move some of the review material outside of JIRA, I  
> > strongly suspect this won't be the case anymore due to the burden of  
> having  
> > to  
> > check multiple places.  
> >  
> > Anyway, I worry a bit that changing for what I perceive as relatively  
> minor  
> > convenience will make us lose more than we get. Just my 2 cents however  
> > really.  
> >  
> > --  
> > Sylvain  
> >  
> > On Wed, Jul 8, 2015 at 11:21 PM, Michael Shuler   
> > wrote:  
> >  
> > > When we set up autojobs for the dev branches, I did some digging around  
> > > the jenkins / githubPR integration, similar to what spark is doing. I'd  
> > be  
> > > completely on board with working through that setup, if it helps this  
> > > workflow.  
> > >  
> > > Michael  
> > >  
> > >  
> > > On 07/08/2015 03:02 PM, Carl Yeksigian wrote:  
> > >  
> > >> Spark has been using the GitHub PRs successfully; they have an  
> > additional  
> > >> mailing list which contains updates from GitHub (  
> > >> http://mail-archives.apache.org/mod_mbox/spark-reviews/), and they  
> also  
> > >> have their PRs linked to JIRA so that going from the ticket to the PR  
> is  
> > >> easily done.  
> > >>  
> > >> If we are going to start using GitHub PRs to conduct reviews, we  
> should  
> > >> follow similar contribution guidelines to what Spark has (  
> > >>  
> > >>  
> >  
> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-PullRequest
>   
> > >> <  
> > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark  
> > >> >),  
> > >> and have Infra set up the same hooks for our repo. We can also hook up  
> > >> cassci to do the same jobs as the AmplabJenkins performs currently.  
> > >>  
> > >>  
> > >> On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie   
> > >> wrote:  
> > >>  
> > >> As some of you might have noticed, Tyler and I tossed around a couple  
> > of  
> > >>> thoughts yesterda

Re: [VOTE] Release Apache Cassandra 2.2.0

[Aleksey Yeschenko]

+1

-- 
AY

On July 17, 2015 at 21:08:06, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.0.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/3FbKhG (CHANGES.txt)  
[2]: http://goo.gl/sMGs53 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 3.0.0-alpha1

[Aleksey Yeschenko]

+1

-- 
AY

On July 31, 2015 at 16:43:25, Jake Luciani (j...@apache.org) wrote:

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

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/oowQCQ (CHANGES.txt)  
[2]: http://goo.gl/s0RHg4 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 3.0.0-beta1

[Aleksey Yeschenko]

+1

-- 
AY

On August 22, 2015 at 06:15:28, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.0-beta1.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/fyezu5 (CHANGES.txt)  
[2]: http://goo.gl/iVuCQU (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.1.9

[Aleksey Yeschenko]

+1

-- 
AY

On August 25, 2015 at 17:01:36, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.9.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/FRGAh2 (CHANGES.txt)  
[2]: http://goo.gl/7HLc2N (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.1

[Aleksey Yeschenko]

+1

-- 
AY

On August 25, 2015 at 20:45:38, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.1.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/3ifmBZ (CHANGES.txt)  
[2]: http://goo.gl/7rQrRR (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.1 (Attempt #2)

[Aleksey Yeschenko]

+1

-- 
AY

On August 28, 2015 at 17:05:05, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.1.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/3ifmBZ (CHANGES.txt)  
[2]: http://goo.gl/7rQrRR (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 3.0.0-beta2

[Aleksey Yeschenko]

+1

-- 
AY

On September 5, 2015 at 01:58:05, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.0-beta2.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/h3McOM (CHANGES.txt)  
[2]: http://goo.gl/WGb5qo (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.0.17

[Aleksey Yeschenko]

+1

-- 
AY

On September 16, 2015 at 19:29:33, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.0.17.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/1g0t58 (CHANGES.txt)  
[2]: http://goo.gl/SHN2y3 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.0.17

[Aleksey Yeschenko]

Changing +1 to -1, since we had to reopen CASSANDRA-10238.

-- 
AY

On September 17, 2015 at 17:43:52, Michael Shuler (mich...@pbandjelly.org) 
wrote:

+1 non-binding  

Commit that CR to cassandra-2.0 branch HEAD, leaving the tag where it is  
and I can build DSC with it included :)  

--  
Michael  

On 09/17/2015 08:48 AM, Jake Luciani wrote:  
> I'm not inclined to re-roll for a missing CR but if others feel strongly  
> about it I will do it.  
>  
> On Wed, Sep 16, 2015 at 10:04 PM, Brandon Williams  wrote:  
>  
>> So, I made a small mistake:  
>>  
>> https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commitdiff;h=718e47f084019f1b22d8a66d911a6cbbcaf6483c
>>   
>>  
>> Obviously this will have no effect on the code, but it's kind of a problem  
>> when you're trying to troubleshoot the type of problem I added that info  
>> for in https://issues.apache.org/jira/browse/CASSANDRA-10330. I don't  
>> think this requires a re-roll, but if we could release with that carriage  
>> return it would be beneficial since there won't be another 2.0 release.  
>>  
>> On Wed, Sep 16, 2015 at 1:29 PM, Jake Luciani  wrote:  
>>  
>>> I propose the following artifacts for release as 2.0.17.  
>>>  
>>> sha1: 3aff44915edbd2bf07955d5b30fd47bf9c4698da  
>>> Git:  
>>>  
>>>  
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.17-tentative
>>   
>>> Artifacts:  
>>>  
>>>  
>> https://repository.apache.org/content/repositories/orgapachecassandra-1078/org/apache/cassandra/apache-cassandra/2.0.17/
>>   
>>> Staging repository:  
>>>  
>> https://repository.apache.org/content/repositories/orgapachecassandra-1078/  
>>>  
>>> The artifacts as well as the debian package are also available here:  
>>> http://people.apache.org/~jake  
>>>  
>>> The vote will be open for 72 hours (longer if needed).  
>>>  
>>> [1]: http://goo.gl/1g0t58 (CHANGES.txt)  
>>> [2]: http://goo.gl/SHN2y3 (NEWS.txt)  
>>>  
>>  
>  
>  
>  

Re: [VOTE] Release Apache Cassandra 2.0.17 (Attempt #2)

[Aleksey Yeschenko]

+1

-- 
AY

On September 18, 2015 at 15:48:18, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.0.17.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/1g0t58 (CHANGES.txt)  
[2]: http://goo.gl/SHN2y3 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 3.0.0-rc1

[Aleksey Yeschenko]

+1

-- 
AY

On September 19, 2015 at 21:42:57, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.0-rc1.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/m3OPOV (CHANGES.txt)  
[2]: http://goo.gl/Z0HNhw (NEWS.txt)  

Re: [RELEASE] Apache Cassandra 3.0.0-rc1 released

[Aleksey Yeschenko]

Compatible version of python-driver (3.0.0a3) and java-driver (3.0.0-alpha3) 
will be published to pypi and maven later today.

In the meantime, you can use the versions bundled with Cassandra 3.0.0-rc1.

-- 
AY

On September 21, 2015 at 09:04:57, Jake Luciani (j...@apache.org) wrote:

The Cassandra team is pleased to announce the release of Apache Cassandra  
version 3.0.0-rc1.  

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 release candidate[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]: http://goo.gl/Oppn3S (CHANGES.txt)  
[2]: http://goo.gl/zQFaj4 (NEWS.txt)  
[3]: https://issues.apache.org/jira/browse/CASSANDRA  

Re: [VOTE] Release Apache Cassandra 2.1.10

[Aleksey Yeschenko]

+1

-- 
AY

On October 1, 2015 at 07:18:10, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.10.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/GLMVLb (CHANGES.txt)  
[2]: http://goo.gl/uFe1VN (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.2

[Aleksey Yeschenko]

+1

-- 
AY

On October 1, 2015 at 07:40:38, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.2.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/wbbE4n (CHANGES.txt)  
[2]: http://goo.gl/EN7MxO (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.1.11

[Aleksey Yeschenko]

+1

-- 
AY

On October 12, 2015 at 19:06:08, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.11.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/cfjxJU (CHANGES.txt)  
[2]: http://goo.gl/nOz2X6 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.3

[Aleksey Yeschenko]

+1

-- 
AY

On October 12, 2015 at 19:28:01, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.3.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/dmpzjR (CHANGES.txt)  
[2]: http://goo.gl/ACOC01 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.3 (Attempt #2)

[Aleksey Yeschenko]

+1

-- 
AY

On October 13, 2015 at 19:59:01, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.3.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/dmpzjR (CHANGES.txt)  
[2]: http://goo.gl/ACOC01 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.1.11 (Attempt #2)

[Aleksey Yeschenko]

+1

-- 
AY

On October 13, 2015 at 18:30:44, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.11.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/cfjxJU (CHANGES.txt)  
[2]: http://goo.gl/nOz2X6 (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 3.0.0-rc2

[Aleksey Yeschenko]

+1

-- 
AY

On 16 October 2015 at 21:34:06, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.0-rc2.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/aOEO0x (CHANGES.txt)  
[2]: http://goo.gl/Im3ydD (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 3.0.0

[Aleksey Yeschenko]

+1

-- 
AY

On 6 November 2015 at 21:35:06, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.0.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/0vghCL (CHANGES.txt)  
[2]: http://goo.gl/xAElQy (NEWS.txt)  

cassandra-3.1 branch and new merge order

[Aleksey Yeschenko]

With 3.0.0 vote to be over soon, tick-tock is officially starting, and we are 
creating a new branch for cassandra-3.1 release.

New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 -> trunk

- cassandra-3.0 branch is going to continue representing the 3.0.x series of 
releases (3.0 bugfixes only, as no new feature are supposed to go into 3.0.x 
release series)
- cassandra-3.1 branch will contain 3.0 bugfixes *only*
- trunk represents the upcoming cassandra-3.2 release (fixes from 3.1 and new 
features)

-- 
AY

Re: cassandra-3.1 branch and new merge order

[Aleksey Yeschenko]

3.0.1 and 3.1 will be identical this time around - that’s just a consequence of 
the transition. Starting with 3.0.2 and 3.2, however, the branches will diverge.

Skipping one or the other would look weird and break continuity, so we are 
still going to release both, despite them containing the same code.

-- 
AY

On 10 November 2015 at 12:14:19, Björn Hegerfors (bj...@spotify.com) wrote:

So there is no reason for an end-user to actually use 3.1, because it will  
have the same features as 3.0.x, but won't be maintained? 3.0.x for high x  
will be 3.1 plus more bug fixes. I'm not saying that's bad. Starting from  
3.2, using any subsequent version will make sense.  

On Tue, Nov 10, 2015 at 12:43 PM, Paulo Motta   
wrote:  

> 3.0.x is an interim branch during the transition to the new tick tock  
> release model, which will receive backported patches from bug-fix releases  
> (3.1, 3.3, etc) that affect 3.0, so no new features will go into 3.0.x. So  
> users can safely go to 3.0 before adopting tick tock, knowing they will be  
> served with bug fixes in the 3.0.x series following the old model.  
>  
> 2015-11-09 22:12 GMT-08:00 Phil Yang :  
>  
> > 2015-11-10 0:35 GMT+08:00 Aleksey Yeschenko :  
> > >  
> > > - cassandra-3.0 branch is going to continue representing the 3.0.x  
> series  
> > > of releases (3.0 bugfixes only, as no new feature are supposed to go  
> into  
> > > 3.0.x release series)  
> > > - cassandra-3.1 branch will contain 3.0 bugfixes *only*  
> > >  
> >  
> > What is the difference between 3.0.x series and 3.1?  
> >  
> >  
> >  
> > > - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1  
> and  
> > > new features)  
> > >  
> > > --  
> > > AY  
> >  
> >  
> >  
> >  
> > --  
> > Thanks,  
> > Phil Yang  
> >  
>  

Re: [VOTE] Release Apache Cassandra 3.0.2

[Aleksey Yeschenko]

+1

-- 
AY

On 17 December 2015 at 19:42:33, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.2.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/Jymb32 (CHANGES.txt)  
[2]: http://goo.gl/2hIFHI (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 3.1.1

[Aleksey Yeschenko]

+1

-- 
AY

On 17 December 2015 at 19:41:25, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.1.1.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/dTQqsb (CHANGES.txt)  
[2]: http://goo.gl/rHhQPO (NEWS.txt)  

Re: Proposal: deprecate Thrift now and remove support in 4.0

[Aleksey Yeschenko]

+1

-- 
AY

On 28 December 2015 at 14:27:26, Jonathan Ellis (jbel...@gmail.com) wrote:

Thrift has been officially frozen for almost two years and unofficially for  
longer. [1] Meanwhile, maintaining Thrift support through changes like  
8099 has been a substantial investment.  

I propose deprecating Thrift now and removing support in 4.0, i.e. Nov 2016  
if tick-tock goes as planned.  

I note that only 7% of our survey respondents [2] are using Thrift-only,  
and and those users are often on old releases (1.1 and 1.2), i.e. unlikely  
to upgrade to 4.x anyway.  

Another 20% of users are using a mix of Thrift and CQL. Some have been  
unable to completely migrate because CQL doesn’t quite provide every  
feature from Thrift. The last such outstanding issue is mixing static and  
dynamic Thrift “columns” in a single table. We have an issue open to  
address this [3].  

I think it is reasonable to either deprecate Thrift immediately in 3.2 or  
to wait until 10857 is committed in 3.4.  

[1]  
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201403.mbox/%3ccaldd-zim6knmr7f_zcpvpqk0b2g919tttathiuofnvlztaw...@mail.gmail.com%3E
  

[2]  
https://docs.google.com/spreadsheets/d/1FegCArZgj2DNAjNkcXi1n2Y1Kfvf6cdZedkMPYQdvC0/edit#gid=0
  

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

--  
Jonathan Ellis  
Project Chair, Apache Cassandra  
co-founder, http://www.datastax.com  
@spyced  

Re: [VOTE] Release Apache Cassandra 3.2

[Aleksey Yeschenko]

+1

-- 
AY

On 8 January 2016 at 21:13:25, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.2.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/T8geYN (CHANGES.txt)  
[2]: http://goo.gl/VDwYyf (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.5

[Aleksey Yeschenko]

+1

-- 
AY

On 3 February 2016 at 16:51:35, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.5.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/GVE9VN (CHANGES.txt)  
[2]: http://goo.gl/kbrReO (NEWS.txt)  
[3]: https://goo.gl/QCHBW3 (DataStax Test Report)  

Re: [VOTE] Release Apache Cassandra 2.1.13

[Aleksey Yeschenko]

+1

-- 
AY

On 3 February 2016 at 16:44:33, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.13.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/ldbtfT (CHANGES.txt)  
[2]: http://goo.gl/yToJdI (NEWS.txt)  
[3]: https://goo.gl/eWXZLZ (DataStax Test Report)  

Re: [VOTE] Release Apache Cassandra 3.3

[Aleksey Yeschenko]

+1

-- 
AY

On 6 February 2016 at 06:11:33, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.3.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/1nZIdi (CHANGES.txt)  
[2]: http://goo.gl/a1UT2s (NEWS.txt)  
[3]: https://goo.gl/aYBtW1 (DataStax Test Report)  

Re: [VOTE] Release Apache Cassandra 3.0.3

[Aleksey Yeschenko]

+1

-- 
AY

On 8 February 2016 at 20:57:00, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.3.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/Xz7gJz (CHANGES.txt)  
[2]: http://goo.gl/Awjozv (NEWS.txt)  
[3]: https://goo.gl/lZKxQa (DataStax Test Report)  

A short guid on how to contribute patches to Cassandra

[Aleksey Yeschenko]

Hello everyone,

I’ve compiled a short guide for contributors (who aren’t committers yet) about 
how to properly contribute Cassandra patches:

https://docs.google.com/document/d/1d_AzYQo74de9utbbpyXxW2w-b0__sFhC7b24ibiJqjw/edit?usp=sharing

Following the outlined recommendations make the lives of committers much 
easier, without adding much hassle to contributor process.

Follow the steps and feel the love.

-- 
AY

Re: A short guid on how to contribute patches to Cassandra

[Aleksey Yeschenko]

Once we have a new wiki, yup, definitely.

-- 
AY

On 9 February 2016 at 16:25:16, Michael Kjellman (mkjell...@internalcircle.com) 
wrote:

Move to Wiki?  

Sent from my iPhone  

> On Feb 9, 2016, at 5:59 AM, Aleksey Yeschenko  wrote:  
>  
> Hello everyone,  
>  
> I’ve compiled a short guide for contributors (who aren’t committers yet) 
> about how to properly contribute Cassandra patches:  
>  
> https://docs.google.com/document/d/1d_AzYQo74de9utbbpyXxW2w-b0__sFhC7b24ibiJqjw/edit?usp=sharing
>   
>  
> Following the outlined recommendations make the lives of committers much 
> easier, without adding much hassle to contributor process.  
>  
> Follow the steps and feel the love.  
>  
> --  
> AY  

Re: Counter values become under-counted when running repair.

[Aleksey Yeschenko]

After repair is over, does the value settle? What CLs do you write to your 
counters with? What CLs are you reading with?

-- 
AY

On 24 March 2016 at 06:17:27, Dikang Gu (dikan...@gmail.com) wrote:

Hello there,  

We are experimenting Counters in Cassandra 2.2.5. Our setup is that we have  
6 nodes, across three different regions, and in each region, the  
replication factor is 2. Basically, each nodes holds a full copy of the  
data.  

When are doing 30k/s counter increment/decrement per node, and at the  
meanwhile, we are double writing to our mysql tier, so that we can measure  
the accuracy of C* counter, compared to mysql.  

The experiment result was great at the beginning, the counter value in C*  
and mysql are very close. The difference is less than 0.1%.  

But when we start to run the repair on one node, the counter value in C*  
become much less than the value in mysql, the difference becomes larger  
than 1%.  

My question is that is it a known problem that the counter value will  
become under-counted if repair is running? Should we avoid running repair  
for counter tables?  

Thanks.  

--  
Dikang  

Re: Counter values become under-counted when running repair.

[Aleksey Yeschenko]

Best open a JIRA ticket and I’ll have a look at what could be the reason.

-- 
AY

On 24 March 2016 at 23:20:55, Dikang Gu (dikan...@gmail.com) wrote:

@Aleksey, we are writing to cluster with CL = 2, and reading with CL = 1.  
And overall we have 6 copies across 3 different regions. Do you have  
comments about our setup?  

During the repair, the counter value become inaccurate, we are still  
playing with the repair, will keep you update with more experiments. But do  
you have any theory around that?  

Thanks a lot!  
Dikang.  

On Thu, Mar 24, 2016 at 11:02 AM, Aleksey Yeschenko   
wrote:  

> After repair is over, does the value settle? What CLs do you write to your  
> counters with? What CLs are you reading with?  
>  
> --  
> AY  
>  
> On 24 March 2016 at 06:17:27, Dikang Gu (dikan...@gmail.com) wrote:  
>  
> Hello there,  
>  
> We are experimenting Counters in Cassandra 2.2.5. Our setup is that we  
> have  
> 6 nodes, across three different regions, and in each region, the  
> replication factor is 2. Basically, each nodes holds a full copy of the  
> data.  
>  
> When are doing 30k/s counter increment/decrement per node, and at the  
> meanwhile, we are double writing to our mysql tier, so that we can measure  
> the accuracy of C* counter, compared to mysql.  
>  
> The experiment result was great at the beginning, the counter value in C*  
> and mysql are very close. The difference is less than 0.1%.  
>  
> But when we start to run the repair on one node, the counter value in C*  
> become much less than the value in mysql, the difference becomes larger  
> than 1%.  
>  
> My question is that is it a known problem that the counter value will  
> become under-counted if repair is running? Should we avoid running repair  
> for counter tables?  
>  
> Thanks.  
>  
> --  
> Dikang  
>  
>  


--  
Dikang  

Re: v2.2.6 release schedule

[Aleksey Yeschenko]

Hey.

Unlike 3.x series, there is no strict cycle for 2.1 and 2.2 updates. Generally 
we go by the gut feeling (changes list is too long, or it’s been a while since 
the last release).

That said, 2.2 list does indeed feel long now. If I were to guess, some time 
this month (April) would be the date.

-- 
AY

On 31 March 2016 at 14:34:45, Emīls Šolmanis (emils.solma...@gmail.com) wrote:

Hey all,  

There's a bugfix that's coming in v.2.2.6 that we need, but not quite  
*that* urgently,  
namely, https://issues.apache.org/jira/browse/CASSANDRA-11302 . Depending  
on when 2.2.6 is scheduled to be released, we're considering doing a  
patched build ourselves, but the recent release history suggests that minor  
version releases happen approximately bimonthly, which would put that in  
early April.  

Is there a scheduled (or even approximate) release date for 2.2.6?  

Kind regards,  
Emils  

Re: [VOTE] Release Apache Cassandra 3.0.5

[Aleksey Yeschenko]

+1

-- 
AY

On 7 April 2016 at 23:11:17, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.5.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/f2b0Di (CHANGES.txt)  
[2]: http://goo.gl/bHIeYj (NEWS.txt)  
[3]: https://goo.gl/noLkHT (DataStax Test Report)  

Re: [VOTE] Release Apache Cassandra 3.5 (Attempt #2)

[Aleksey Yeschenko]

+1

-- 
AY

On 11 April 2016 at 09:41:30, Benjamin Lerer (benjamin.le...@datastax.com) 
wrote:

+1  

On Sun, Apr 10, 2016 at 5:43 PM, Jake Luciani  wrote:  

> I propose the following artifacts for release as 3.5.  
>  
> sha1: 020dd2d1034abc5c729edf1975953614b33c5a8b  
> Git:  
>  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
>   
> Artifacts:  
>  
> https://repository.apache.org/content/repositories/orgapachecassandra-1106/org/apache/cassandra/apache-cassandra/3.5/
>   
> Staging repository:  
> https://repository.apache.org/content/repositories/orgapachecassandra-1106/  
>  
> The artifacts as well as the debian package are also available here:  
> http://people.apache.org/~jake  
>  
> The vote will be open for 72 hours (longer if needed).  
>  
> [1]: http://goo.gl/v1sH4v (CHANGES.txt)  
> [2]: http://goo.gl/ZlHf5z (NEWS.txt)  
>  

Re: Criteria for upgrading to 3.x releases in PROD

[Aleksey Yeschenko]

The answer will depend on how conservative you are.

The most conservative choice overall would be to go with the 2.2.x line.

3.0.x if you want to the new nice and shiny 3.0 things, but can tolerate some 
risk (the branch has a lot of relatively new core code, and hasn’t yet been 
tried out by as many users as the 2.x branch had).

The latest odd 3.x if you want the shiniest (3.5 to be released soon, with 
features like the new SASI secondary indexes support). Also, there hasn’t yet 
been that much divergence between 3.0.x and 3.x, so risk levels are around the 
same, so long as you limit yourself to only the features present in 3.0.x.

Either way, make sure to properly test whatever release you go for in staging 
first, as Michael says, and you’ll be alright.

-- 
AY

On 11 April 2016 at 18:42:31, Anuj Wadehra (anujw_2...@yahoo.co.in.invalid) 
wrote:

Can someone help me with this one?  
ThanksAnuj  

Sent from Yahoo Mail on Android  

On Sun, 10 Apr, 2016 at 11:07 PM, Anuj Wadehra wrote: 
Hi,  
Tick-Tock release strategy in 3.x was a good intiative to ensure frequent & 
stable releases. While odd releases are supposed to get all the bug fixes and 
should be most stable, many people like me, who got used to the comforting 
"production ready/stable" tag on Apache website,  are still reluctant to take 
latest 3.x odd releases into production. I think the hesitation is somewhat 
justified as processes often take time to mature.  
So here I would like to ask the experts, people who know the ground situation, 
people who actively develop it and manage it. Considering the current scenario, 
What should be a resonable criteria for taking 3.x releases in production?   


ThanksAnuj  

Re: [VOTE] Release Apache Cassandra 2.2.6

[Aleksey Yeschenko]

+1

-- 
AY

On 22 April 2016 at 22:16:18, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.6.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/6pLDlq (CHANGES.txt)  
[2]: http://goo.gl/Pqv75l (NEWS.txt)  
[3]: https://goo.gl/v0mlO1 (Datastax Test Report)  

Re: [VOTE] Release Apache Cassandra 2.1.14

[Aleksey Yeschenko]

+1

-- 
AY

On 22 April 2016 at 22:13:19, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.14.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/mMQSCa (CHANGES.txt)  
[2]: http://goo.gl/BsauSg (NEWS.txt)  
[3]: https://goo.gl/mlrNxH (Datastax Test Report)  

Re: cassandra crush when enable hints_compression

[Aleksey Yeschenko]

Hello Weijian,

Please file a ticket with Cassandra JIRA - I’ll ping the person who implemented 
hints compression and they’ll have a look.

-- 
AY

On 26 April 2016 at 10:44:00, weijian lin (linweiji...@gmail.com) wrote:

Hi,  

When I enable hints_compression and set the compression class to  
LZ4Compressor，the  
cassandra (v3.05, V3.5.0) will crush。That is a bug, or any conf is wrong?  


*Exception in V 3.5.0 *  

ERROR [HintsDispatcher:2] 2016-04-26 15:02:56,970  
HintsDispatchExecutor.java:225 - Failed to dispatch hints file  
abc4dda2-b551-427e-bb0b-e383d4a392e1-1461654138963-1.hints: file is  
corrupted ({})  
org.apache.cassandra.io.FSReadError: java.io.EOFException  
at  
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:284)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:254)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatcher.sendHints(HintsDispatcher.java:156)  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:137)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:119)  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:91)  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:259)
  
[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
  
[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:220)
  
[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.run(HintsDispatchExecutor.java:199)
  
[apache-cassandra-3.5.0.jar:3.5.0]  
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
[na:1.8.0_65]  
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_65]  
at  
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 
[na:1.8.0_65]  
at  
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 
[na:1.8.0_65]  
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_65]  
Caused by: java.io.EOFException: null  
at  
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:146)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.io.util.RebufferingInputStream.readPrimitiveSlowly(RebufferingInputStream.java:108)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.io.util.RebufferingInputStream.readInt(RebufferingInputStream.java:188)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNextInternal(HintsReader.java:297)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
at  
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:280)
  
~[apache-cassandra-3.5.0.jar:3.5.0]  
... 15 common frames omitted  



*Exception in V 3.0.5 *  

ERROR [HintsDispatcher:2] 2016-04-26 15:54:46,294  
HintsDispatchExecutor.java:225 - Failed to dispatch hints file  
8603be13-6878-4de3-8bc3-a7a7146b0376-1461657251205-1.hints: file is  
corrupted ({})  
org.apache.cassandra.io.FSReadError: java.io.EOFException  
at  
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:282)
  
~[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsReader$BuffersIterator.computeNext(HintsReader.java:252)
  
~[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)  
~[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsDispatcher.sendHints(HintsDispatcher.java:156)  
~[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsDispatcher.sendHintsAndAwait(HintsDispatcher.java:137)
  
~[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:119)  
~[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsDispatcher.dispatch(HintsDispatcher.java:91)  
~[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.deliver(HintsDispatchExecutor.java:259)
  
[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.java:242)
  
[apache-cassandra-3.0.5.jar:3.0.5]  
at  
org.apache.cassandra.hints.HintsDispatchExecutor$DispatchHintsTask.dispatch(HintsDispatchExecutor.ja

Re: [VOTE] Release Apache Cassandra 3.6

[Aleksey Yeschenko]

+1

-- 
AY

On 11 May 2016 at 02:55:10, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.6.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/Yv15Qz (CHANGES.txt)  
[2]: http://goo.gl/VyR9EG (NEWS.txt)  
[3]: https://goo.gl/raz8ok (DataStax QA Report)  

Re: [VOTE] Release Apache Cassandra 3.0.6

[Aleksey Yeschenko]

+1

-- 
AY

On 11 May 2016 at 02:55:11, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.6.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/IiNyVb (CHANGES.txt)  
[2]: http://goo.gl/ZAr03L (NEWS.txt)  
[3]: https://goo.gl/2jPtss (DataStax QA Report)  

Re: [VOTE] Release Apache Cassandra 3.6

[Aleksey Yeschenko]

Seconding the -1 (binding) for the same reasons.

-- 
AY

On 12 May 2016 at 23:44:46, Tyler Hobbs (ty...@datastax.com) wrote:

Based on CASSANDRA-11613 (and CASSANDRA-11760), I'm changing my vote to a  
(non-binding) -1. There is a legit regression in upgrading non-frozen UDTs  
that needs to be fixed before releasing 3.6.  

On Thu, May 12, 2016 at 12:44 PM, Philip Thompson <  
philip.thomp...@datastax.com> wrote:  

> I've updated the TE report with the results of the upgrade testing we did.  
> We experienced a higher than expected number of test failures, which  
> prompted the filing of:  
>  
> CASSANDRA-11760  
> CASSANDRA-11763  
> CASSANDRA-11765  
> CASSANDRA-11767  
>  
> Two errors were related to handling the legacy hint format after upgrades  
> to 3.6 from either the 2.1 or 2.2 series. This should not affect upgrades  
> from 3.0.x, or new 3.6 clusters. 11760 is an issue handling UDTs in  
> mixed-versions 2.2.5 / 3.6 clusters.  
>  
> These four bugs were accompanied by other existing, known upgrade failures.  
> We do not suspect that these four issues are 3.6 regressions, as we have  
> tested this release with a large number of new upgrade tests, that were not  
> run on previous tick-tock releases. I am re-running these tests against  
> 3.4, to confirm that suspicion.  
>  
> On Tue, May 10, 2016 at 9:54 PM, Jake Luciani  wrote:  
>  
> > I propose the following artifacts for release as 3.6.  
> >  
> > sha1: c17cbe1875a974a00822ffbfad716abde363c8da  
> > Git:  
> >  
> >  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.6-tentative
>   
> > Artifacts:  
> >  
> >  
> https://repository.apache.org/content/repositories/orgapachecassandra-1112/org/apache/cassandra/apache-cassandra/3.6/
>   
> > Staging repository:  
> >  
> https://repository.apache.org/content/repositories/orgapachecassandra-1112/  
> >  
> > The artifacts as well as the debian package are also available here:  
> > http://people.apache.org/~jake  
> >  
> > The vote will be open for 72 hours (longer if needed).  
> >  
> > [1]: http://goo.gl/Yv15Qz (CHANGES.txt)  
> > [2]: http://goo.gl/VyR9EG (NEWS.txt)  
> > [3]: https://goo.gl/raz8ok (DataStax QA Report)  
> >  
>  



--  
Tyler Hobbs  
DataStax   

Re: [VOTE] Release Apache Cassandra 3.6 (Attempt #2)

[Aleksey Yeschenko]

+1

-- 
AY

On 1 June 2016 at 18:30:57, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.6.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/lg9U9a (CHANGES.txt)  
[2]: http://goo.gl/nyDyxk (NEWS.txt)  
[3]: https://goo.gl/hNyrnW (DataStax QA Report)  

Re: Cassandra Java Driver and DataStax

[Aleksey Yeschenko]

As a member of that governing body (Cassandra PMC), I would much prefer not to 
deal with the drivers as well.

And I’m just as certain that java-driver - and other driver communities - would 
much rather prefer to keep their process and organisation instead of being 
forced to conform to ours.

I’m finding it hard to see a single party that would benefit from such a merge, 
and who suffers from the current state of things.

-- 
AY

On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com) wrote:

How does it add more complexity by having one governing body (the PMC)?  
What I am suggesting is that the driver project be somewhat of a subproject  
or a "module". It can still have its own life cycle, just like it does now.  

On Sat, Jun 4, 2016 at 12:44 PM Nate McCall  wrote:  

> It doesnt. But then we add complexity in communicating and managing  
> versions, releases, etc. to the project. Again, from my experience with  
> hector, I just didnt want the hassle of owning that within the project  
> confines.  
>  
> On Sat, Jun 4, 2016 at 11:30 AM, James Carman   
> wrote:  
>  
> > Who said the driver has to be released with the database?  
> >  
> > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > wrote:  
> >  
> > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > ja...@carmanconsulting.com>  
> > > wrote:  
> > >  
> > > > So why not just donate the Java driver and keep that in house?  
> > Cassandra  
> > > is  
> > > > a Java project. Makes sense to me.  
> > > >  
> > > >  
> > > I won't deny there is an argument to be made here, but as a former  
> client  
> > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > community  
> > > member since late 2009, my opinion is that this would be a step  
> > backwards.  
> > >  
> > > Maintaining Hector independently allowed me the freedom to release  
> major  
> > > features with technology that I wanted to use while maintaining  
> backwards  
> > > compatibility without having to be bound to the project's release cycle  
> > and  
> > > process. (And to use a build system that didnt suck).  
> > >  
> > > The initial concern of the use of the word "controls" is *super* not  
> cool  
> > > and I hope that this is being fixed. That said, the reality, from my  
> > > (external to DataStax) perspective, is that this is not the case. I  
> like  
> > > the current project separation the way it is and don't feel like there  
> is  
> > > any attempt at "control" of the java driver's direction and  
> development.  
> > >  
> > > -Nate  
> > >  
> >  
>  
>  
>  
> --  
> -  
> Nate McCall  
> Austin, TX  
> @zznate  
>  
> CTO  
> Apache Cassandra Consulting  
> http://www.thelastpickle.com  
>  

Re: Cassandra Java Driver and DataStax

[Aleksey Yeschenko]

An eloquent and powerful response, but please, reply to my points instead of 
resorting to ad hominem arguments.

In practical terms, who would benefit from such a merge, and who is suffering 
from the current state of affairs?

-- 
AY

On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com) wrote:

"Sr. Software Engineer at DataStax", imagine that.  

On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko  wrote:  

> As a member of that governing body (Cassandra PMC), I would much prefer  
> not to deal with the drivers as well.  
>  
> And I’m just as certain that java-driver - and other driver communities -  
> would much rather prefer to keep their process and organisation instead of  
> being forced to conform to ours.  
>  
> I’m finding it hard to see a single party that would benefit from such a  
> merge, and who suffers from the current state of things.  
>  
> --  
> AY  
>  
> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)  
> wrote:  
>  
> How does it add more complexity by having one governing body (the PMC)?  
> What I am suggesting is that the driver project be somewhat of a subproject  
> or a "module". It can still have its own life cycle, just like it does now.  
>  
> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall   
> wrote:  
>  
> > It doesnt. But then we add complexity in communicating and managing  
> > versions, releases, etc. to the project. Again, from my experience with  
> > hector, I just didnt want the hassle of owning that within the project  
> > confines.  
> >  
> > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <  
> ja...@carmanconsulting.com>  
> > wrote:  
> >  
> > > Who said the driver has to be released with the database?  
> > >  
> > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > > wrote:  
> > >  
> > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > > ja...@carmanconsulting.com>  
> > > > wrote:  
> > > >  
> > > > > So why not just donate the Java driver and keep that in house?  
> > > Cassandra  
> > > > is  
> > > > > a Java project. Makes sense to me.  
> > > > >  
> > > > >  
> > > > I won't deny there is an argument to be made here, but as a former  
> > client  
> > > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > > community  
> > > > member since late 2009, my opinion is that this would be a step  
> > > backwards.  
> > > >  
> > > > Maintaining Hector independently allowed me the freedom to release  
> > major  
> > > > features with technology that I wanted to use while maintaining  
> > backwards  
> > > > compatibility without having to be bound to the project's release  
> cycle  
> > > and  
> > > > process. (And to use a build system that didnt suck).  
> > > >  
> > > > The initial concern of the use of the word "controls" is *super* not  
> > cool  
> > > > and I hope that this is being fixed. That said, the reality, from my  
> > > > (external to DataStax) perspective, is that this is not the case. I  
> > like  
> > > > the current project separation the way it is and don't feel like  
> there  
> > is  
> > > > any attempt at "control" of the java driver's direction and  
> > development.  
> > > >  
> > > > -Nate  
> > > >  
> > >  
> >  
> >  
> >  
> > --  
> > -  
> > Nate McCall  
> > Austin, TX  
> > @zznate  
> >  
> > CTO  
> > Apache Cassandra Consulting  
> > http://www.thelastpickle.com  
> >  
>  

Re: Cassandra Java Driver and DataStax

[Aleksey Yeschenko]

The java-driver is fully Apache licensed. In the implausible scenario something 
like that happens, we can always simply fork it and start maintaining it 
ourselves.

As long as java-driver community are good community citizens - as they are, and 
have been since day one - we are happy to have that non-trivial amount of work 
done by them.

Also, I’m curious to know where/when ‘it has happened before’.

-- 
AY

On 4 June 2016 at 18:10:35, James Carman (ja...@carmanconsulting.com) wrote:

I apologized else-thread about that one. It was a low blow. Anyway, to  
answer your question. The Cassandra community wins! How do we know if they  
won't make you pay for the driver in the future (after all your code is  
written against it)? It has happened before. Also, the rest of the  
community can have a say in the direction (because that's the Apache Way).  
The driver can be more intimate with the database, because it's the same  
people developing it.  

On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko  wrote:  

> An eloquent and powerful response, but please, reply to my points instead  
> of resorting to ad hominem arguments.  
>  
> In practical terms, who would benefit from such a merge, and who is  
> suffering from the current state of affairs?  
>  
> --  
> AY  
>  
> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)  
> wrote:  
>  
> "Sr. Software Engineer at DataStax", imagine that.  
>  
> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko   
> wrote:  
>  
> > As a member of that governing body (Cassandra PMC), I would much prefer  
> > not to deal with the drivers as well.  
> >  
> > And I’m just as certain that java-driver - and other driver communities -  
> > would much rather prefer to keep their process and organisation instead  
> of  
> > being forced to conform to ours.  
> >  
> > I’m finding it hard to see a single party that would benefit from such a  
> > merge, and who suffers from the current state of things.  
> >  
> > --  
> > AY  
> >  
> > On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)  
> > wrote:  
> >  
> > How does it add more complexity by having one governing body (the PMC)?  
> > What I am suggesting is that the driver project be somewhat of a  
> subproject  
> > or a "module". It can still have its own life cycle, just like it does  
> now.  
> >  
> > On Sat, Jun 4, 2016 at 12:44 PM Nate McCall   
> > wrote:  
> >  
> > > It doesnt. But then we add complexity in communicating and managing  
> > > versions, releases, etc. to the project. Again, from my experience with  
> > > hector, I just didnt want the hassle of owning that within the project  
> > > confines.  
> > >  
> > > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <  
> > ja...@carmanconsulting.com>  
> > > wrote:  
> > >  
> > > > Who said the driver has to be released with the database?  
> > > >  
> > > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > > > wrote:  
> > > >  
> > > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > > > ja...@carmanconsulting.com>  
> > > > > wrote:  
> > > > >  
> > > > > > So why not just donate the Java driver and keep that in house?  
> > > > Cassandra  
> > > > > is  
> > > > > > a Java project. Makes sense to me.  
> > > > > >  
> > > > > >  
> > > > > I won't deny there is an argument to be made here, but as a former  
> > > client  
> > > > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > > > community  
> > > > > member since late 2009, my opinion is that this would be a step  
> > > > backwards.  
> > > > >  
> > > > > Maintaining Hector independently allowed me the freedom to release  
> > > major  
> > > > > features with technology that I wanted to use while maintaining  
> > > backwards  
> > > > > compatibility without having to be bound to the project's release  
> > cycle  
> > > > and  
> > > > > process. (And to use a build system that didnt suck).  
> > > > >  
> > > > > The initial concern of the use of the word "controls" is *super*  
> not  
> > > cool  
> > > > > and I hope that this is being fixed. That said, the reality, from  
> my  
> > > > > (external to DataStax) perspective, is that this is not the case. I  
> > > like  
> > > > > the current project separation the way it is and don't feel like  
> > there  
> > > is  
> > > > > any attempt at "control" of the java driver's direction and  
> > > development.  
> > > > >  
> > > > > -Nate  
> > > > >  
> > > >  
> > >  
> > >  
> > >  
> > > --  
> > > -  
> > > Nate McCall  
> > > Austin, TX  
> > > @zznate  
> > >  
> > > CTO  
> > > Apache Cassandra Consulting  
> > > http://www.thelastpickle.com  
> > >  
> >  
>  

Re: [VOTE] Release Apache Cassandra 3.7

[Aleksey Yeschenko]

+1

-- 
AY

On 8 June 2016 at 14:21:58, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.7.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/uA2hU1 (CHANGES.txt)  
[2]: http://goo.gl/e79k5m (NEWS.txt)  
[3]: https://goo.gl/iBt11P (Test Report)  

Re: [VOTE] Release Apache Cassandra 3.0.7

[Aleksey Yeschenko]

+1

-- 
AY

On 8 June 2016 at 16:31:35, Brandon Williams (dri...@gmail.com) wrote:

+1  

On Wed, Jun 8, 2016 at 2:35 PM, Jake Luciani  wrote:  

> I propose the following artifacts for release as 3.0.7.  
>  
> sha1: 040ac666ac5cdf9cd0a01a845f2ea0af3a81a08b  
> Git:  
>  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.7-tentative
>   
> Artifacts:  
>  
> https://repository.apache.org/content/repositories/orgapachecassandra-1115/org/apache/cassandra/apache-cassandra/3.0.7/
>   
> Staging repository:  
> https://repository.apache.org/content/repositories/orgapachecassandra-1115/  
>  
> The artifacts as well as the debian package are also available here:  
> http://people.apache.org/~jake  
>  
> The vote will be open for 72 hours (longer if needed).  
>  
> [1]: http://goo.gl/GYLlrI (CHANGES.txt)  
> [2]: http://goo.gl/gK48Xw (NEWS.txt)  
> [3]: https://goo.gl/fCrUCh (Test Report)  
>  

Re: Possible Bug: bucket_low has no effect in STCS

[Aleksey Yeschenko]

When in doubt, just open a JIRA. Thanks.

-- 
AY

On 15 June 2016 at 13:56:24, Anuj Wadehra (anujw_2...@yahoo.co.in.invalid) 
wrote:

Should I raise JIRA ?? Or some develiper with knowledge of STCS could confirm 
the bug ??  

Anuj  



Sent from Yahoo Mail on Android  

On Tue, 14 Jun, 2016 at 12:52 PM, Anuj Wadehra wrote: 
Can any developer confirm the issue?  

ThanksAnuj  


Sent from Yahoo Mail on Android  

On Mon, 13 Jun, 2016 at 11:15 PM, Anuj Wadehra wrote: 
Hi,  

I am trying to understand the algorithm of STCS. As per my current 
understanding of the code, there seems to be no impact of setting bucket_low in 
the STCS compaction algorithm. Moreover, I see some optimization. I would 
appreciate if some designer can correct me or confirm that it's a bug sonthat I 
can raise a JIRA.  


Details  
--  
getBuckets() method of SizeTieredCompactionStrategy sorts sstables by size in 
ascending order and then iterates over them one by one to associate them to an 
existing/new bucket. When, iterating sstables in ascending order of size, I 
can't find ANY single scenario where the current sstable in the outer loop 
iteration is below the oldAverageSize of any existing bucket. Current sstable 
being iterated will ALWAYS be greater than/equal to the oldAverageSize of ALL 
existing buckets as ALL previous sstables in existing buckets were 
smaller/equal in size to the sstable being iterated.  

So, there is NO scenario when size > (oldAverageSize * bucketLow) and size < 
oldAverageSize, so bucket_low property never comes into play no matter what 
value you set for it.  


Also, while iteraitng over sstables (sortedfiles) by size in ascending order, 
there is no point iterating over all existing buckets. We could just start from 
the LAST bucket where previous sstable was associated.  oldAverageSize of ALL 
other buckets will NEVER allow the sstable being iterated.  

for (Entry> entry : buckets.entrySet())  
            {...}  



Thanks  
Anuj  

Re: Schema Disagreement vs Nodetool resetlocalschema

[Aleksey Yeschenko]

Schema will disagree during the upgrade itself, you can’t really work around 
it. It will converge once you finish the upgrade, however.

-- 
AY

On 20 June 2016 at 04:21:02, Michael Fong (michael.f...@ruckuswireless.com) 
wrote:

Hi,  

We have recently encountered several schema disagreement issue while upgrading 
Cassandra. In one of the cases, the 2-node cluster idled for over 30 minutes 
and their schema remain unsynced. Due to other logic flows, Cassandra cannot be 
restarted, and hence we need to come up an alternative on-the-fly. We are 
thinking to do a nodetool resetlocalschema to force the schema synchronization. 
How safe is this method? Do we need to disable thrift/gossip protocol before 
performing this function, and enable them back after resync completes?  

Thanks in advance!  

Sincerely,  

Michael Fong  

Re: [VOTE] Release Apache Cassandra 2.1.15

[Aleksey Yeschenko]

+1

-- 
AY

On 30 June 2016 at 20:31:11, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.1.15.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/Dah6P4 (CHANGES.txt)  
[2]: http://goo.gl/ZFeiGF (NEWS.txt)  

Re: [VOTE] Release Apache Cassandra 2.2.7

[Aleksey Yeschenko]

+1

-- 
AY

On 1 July 2016 at 15:59:02, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.2.7.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/R37fmZ (CHANGES.txt)  
[2]: http://goo.gl/PaGj7e (NEWS.txt)  
[3]: https://goo.gl/DKoHDw (Test Report)  

Re: [VOTE] Release Apache Cassandra 3.0.8

[Aleksey Yeschenko]

+1

-- 
AY

On 1 July 2016 at 16:41:00, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.8.  

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

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

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

[1]: http://goo.gl/6B1cR3 (CHANGES.txt)  
[2]: http://goo.gl/1IXyg0 (NEWS.txt)  
[3]: https://goo.gl/1o8K6t (Test Report)  

Re: Blockers for 4.0

[Aleksey Yeschenko]

I’d strike CASSANDRA-10383 off the list - there is no way it’s a blocker for 
anything.

As for 9424, unless I die unexpectedly *and* nobody else picks up the work, it 
should be fine for Nov.

Don’t see anything missing from the list.

-- 
AY

On 20 July 2016 at 15:59:34, Jason Brown (jasedbr...@gmail.com) wrote:

CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review  

On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis  wrote:  

> The plan of record has been to ship 4.0 in November, 12 months after 3.0.  
> But, there are a number of features that are going to cause backwards  
> incompatibility and if they miss 4.0 will need to wait for 5.0. Are any of  
> these worth delaying 4.0 for?  
>  
> (Currently the plan is to have all of these ready for November, but let's  
> get our backup plan figured out now, just in case. That way we don't have  
> to make the decision at the last minute when everything feels like an  
> emergency.)  
>  
> Some candidates that might be worth delaying the release for:  
>  
> - "Birch" trees for the primary key index  
> . Changes the  
> format of data on disk so automatically in the "dot zero" category.  
> - Decouple messaging protocol versioning  
> . This would  
> allow us to change the intra-node protocol on a per-message basis, which  
> gives us more flexibility with compatibility. Currently any change  
> drops  
> us into the "no schema changes until everyone is upgraded" world which  
> effectively rules out making any improvements across tick-tock releases.  
> - Allow dropping COMPACT STORAGE flag  
> . This is what  
> makes it possible to remove the deprecated Thrift support.  
> - Schema rearchitecture  
> . Can we live  
> without safe and programatic CREATE and ALTER for another year?  
>  
> --  
> Jonathan Ellis  
> Project Chair, Apache Cassandra  
> co-founder, http://www.datastax.com  
> @spyced  
>  

Re: Reminder: critical fixes only in 2.1

[Aleksey Yeschenko]

+1 from me (and I don’t see any resistance to it either).

-- 
AY

On 18 July 2016 at 18:36:42, Jonathan Ellis (jbel...@gmail.com) wrote:

Except there really wasn't.  

Patch submitter: "I want this in 2.1."  
Reviewer: "Okay."  

That's not exactly the bar we're looking for. To consider a performance  
fix "critical" for example, you really need to show at the very least what  
new workload you found that isn't able to live with it the way everyone  
else did for the previous 15 releases.  

I note that on 10433 the committer even said, "I'm not [sure] I agree this  
is critical for 2.1 at this point, but as it's simple enough and has been  
somewhat vetted on 2.2 by now, not going to argue."  

So consider this me putting on my bad cop hat and opening up the argument.  

On Mon, Jul 18, 2016 at 12:24 PM, Jeremiah D Jordan   
wrote:  

> Looking at those tickets in all three of them the “is this critical to  
> fix” question came up in the JIRA discussion and it was decided that they  
> were indeed critical enough to commit to 2.1.  
>  
> > On Jul 18, 2016, at 11:47 AM, Jonathan Ellis  wrote:  
> >  
> > We're at the stage of the release cycle where we should be committing  
> > critical fixes only to the 2.1 branch. Many people depend on 2.1 working  
> > reliably and it's not worth the risk of introducing regressions for  
> (e.g.)  
> > performance improvements.  
> >  
> > I think some of the patches committed so far for 2.1.16 do not meet this  
> > bar and should be reverted. I include a summary of what people have to  
> > live with if we leave them unfixed:  
> >  
> > https://issues.apache.org/jira/browse/CASSANDRA-11349  
> > Repair suffers false-negative tree mismatches and overstreams data.  
> >  
> > https://issues.apache.org/jira/browse/CASSANDRA-10433  
> > Reduced performance on inserts (and reads?) (for Thrift clients only?)  
> >  
> > https://issues.apache.org/jira/browse/CASSANDRA-12030  
> > Reduced performance on reads for workloads with range tombstones  
> >  
> > Anyone want to make a case that these are more critical than they appear  
> > and should not be reverted?  
> >  
> > --  
> > Jonathan Ellis  
> > Project Chair, Apache Cassandra  
> > co-founder, http://www.datastax.com  
> > @spyced  
>  
>  


--  
Jonathan Ellis  
Project Chair, Apache Cassandra  
co-founder, http://www.datastax.com  
@spyced  

Re: [VOTE] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

+1

-- 
AY

On 20 July 2016 at 22:48:09, Michael Shuler (mshu...@apache.org) wrote:

I propose the following artifacts for release as 3.8.  

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

The debian packages are available here: http://people.apache.org/~mshuler/  

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

[1]: http://goo.gl/oGNH0i (CHANGES.txt)  
[2]: http://goo.gl/KjMtUn (NEWS.txt)  
[3]: https://goo.gl/TxVLKo (3.8 Test Summary)  

Re: Reminder: critical fixes only in 2.1

[Aleksey Yeschenko]

Keep #11349, revert the rest sounds reasonable.

-- 
AY

On 20 July 2016 at 22:27:05, sankalp kohli (kohlisank...@gmail.com) wrote:

+1 on only allowing critical bug fixes.  
I agree with Sylvain that CASSANDRA-11349 is a border line critical bug. I  
would vote for CASSANDRA-11349 as being critical since over streaming is a  
big issue for us as well. I am also fine taking it as an internal patch  
since we already maintain an internal branch with bug fixes.  

On Wed, Jul 20, 2016 at 2:10 PM, Fabien Rousseau   
wrote:  

> Hi,  
>  
> I'm the reporter for CASSANDRA-11349.  
> Just a bit of history:  
>  
> This was a big pain point for us because the over-streaming was really  
> important.  
> Each week, repair increased data size by a few percents.  
> To give an example, one cluster with 12 nodes had a CF with around 250GB of  
> data per node and after compaction, reduced to 80GB.  
> Before fully understanding the problem, we just doubled the cluster size  
> just because of this issue (from 6 nodes to 12 nodes).  
> We spotted the problem in November 2015, in one cluster, without having  
> hints of what was happening at first (we just knew that there was a lot of  
> streaming during repairs, ie a few MB/s of data, and that there was quite a  
> high ratio of mismatch on read repairs)  
> After putting in production more clusters (with completely different data  
> models), we continued to observe this pattern (without finding any  
> correlation).  
> It took some time to identify the issue and fix it.  
> Note that, once we reported the issue, we stopped repairing the affected  
> CFs. (I know it's a bad practice, but this was a temporary solution on  
> bare-metal servers which are quite stable).  
>  
> I'd say that I'm surprised that this was not reported by more people (our  
> data model has nothing particular).  
> (Maybe other people are affected but have not paid attention to this  
> phenomenon)  
>  
> Please note that this patch does not affect how SSTables are serialized,  
> but only how digest are computed thus reduces risks.  
>  
> So, to conclude, it was critical for us, and it may help other people in  
> the wild.  
> Nevertheless, we can live with this patch not being included in 2.1.X (by  
> maintaining our own C* package until we migrate to 3.0.X)  
>  
> 2016-07-20 18:06 GMT+02:00 Sylvain Lebresne :  
>  
> > Definitively agrees that CASSANDRA-10433 and CASSANDRA-12030 aren't  
> > critical. In fact, they are both marked as "improvements" and "minor".  
> I'm  
> > to blame for their commit, so mea culpa. But to my defense, I've long  
> > advocated for being stricter on sticking to critical-only fixes on old  
> > releases and have long felt that this sentiment wasn't really shared in  
> > practice by other devs/committers (could be my fault getting the wrong  
> > impression, but I've lost track of the number of time were other  
> > devs/committers argue for "just this time because it's really simple"  
> when  
> > those questions cam up), so I've partly gave up on arguing. I'm happy to  
> > get more consistent on this and +1 reverting those.  
> >  
> > I think CASSANDRA-11349 is the one possibly more debatable. Fabien on the  
> > ticket seemed to suggest that on his clusters the bug was make repair  
> > unmanageable ("a few days after filing the bug, we decided to temporarily  
> > stop repairing some tables [...] which were heavily impacted by those  
> > bugs"). He mention in particular having seen "around a hundred"  
> mismatches  
> > with the patch against "a few hundred of thousands" without. I suppose  
> one  
> > could make a case that having repair over-stream by 3 order of magnitude  
> in  
> > some case is critical-ish. Note that I wouldn't oppose reverting this  
> too,  
> > as it doesn't fully meet *my* definition of critical, but I'm willing to  
> > accept my definition is on the stronger side of things and leave it in.  
> >  
> > --  
> > Sylvain  
> >  
> > On Wed, Jul 20, 2016 at 5:29 PM, Aleksey Yeschenko   
> > wrote:  
> >  
> > > +1 from me (and I don’t see any resistance to it either).  
> > >  
> > > --  
> > > AY  
> > >  
> > > On 18 July 2016 at 18:36:42, Jonathan Ellis (jbel...@gmail.com) wrote:  
> > >  
> > > Except there really wasn't.  
> > >  
> > > Patch submitter: "I want this in 2.1."  
> > > Reviewer: "Okay."  
> > >  
> > > That's not exactly 

Re: Blockers for 4.0

[Aleksey Yeschenko]

I don’t think so, b/c https://issues.apache.org/jira/browse/CASSANDRA-12142 
will allow us to develop them incrementally.

-- 
AY

On 20 July 2016 at 22:03:37, Jake Luciani (jak...@gmail.com) wrote:

Also, anything related to native protocol v5 
https://issues.apache.org/jira/issues/?jql=labels%20%3D%20protocolv5

Re: Blockers for 4.0

[Aleksey Yeschenko]

3.10 most likely.

-- 
AY

On 21 July 2016 at 01:28:13, Jake Luciani (jak...@gmail.com) wrote:

Will that be in 3.x or 4?

Re: [VOTE] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

I still think the issue is minor enough, and with 3.8 being extremely delayed, 
and being a non-odd release, at that, we’d be better off just pushing it.

Also, I know we’ve been easy on -1s when voting on releases, but I want to 
remind people in general that release votes can not be vetoed and only require 
a majority of binding votes, 
http://www.apache.org/foundation/voting.html#ReleaseVotes

-- 
AY

On 21 July 2016 at 08:57:22, Sylvain Lebresne (sylv...@datastax.com) wrote:

Sorry but I'm (binding) -1 on this because of  
https://issues.apache.org/jira/browse/CASSANDRA-12236.  

I disagree that knowingly releasing a version that will temporarily break  
in-flight queries during upgrade, even if it's for a very short time-frame  
until re-connection, is ok. I'll note in particular that in the test  
report, there is 74! failures in the upgrade tests (for reference the 3.7  
test report had only 2 upgrade tests failure both with open tickets). Given  
that we have a known problem during upgrade, I don't really buy the "We are  
assuming these are due to a recent downsize in instance size that these  
tests run on" and that suggest to me the problem is not too minor.  


On Thu, Jul 21, 2016 at 6:18 AM, Dave Brosius   
wrote:  

> +1  
>  
>  
> On 07/20/2016 05:48 PM, Michael Shuler wrote:  
>  
>> I propose the following artifacts for release as 3.8.  
>>  
>> sha1: c3ded0551f538f7845602b27d53240cd8129265c  
>> Git:  
>>  
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
>>   
>> Artifacts:  
>>  
>> https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/
>>   
>> Staging repository:  
>>  
>> https://repository.apache.org/content/repositories/orgapachecassandra-1123/  
>>  
>> The debian packages are available here:  
>> http://people.apache.org/~mshuler/  
>>  
>> The vote will be open for 72 hours (longer if needed).  
>>  
>> [1]: http://goo.gl/oGNH0i (CHANGES.txt)  
>> [2]: http://goo.gl/KjMtUn (NEWS.txt)  
>> [3]: https://goo.gl/TxVLKo (3.8 Test Summary)  
>>  
>>  
>  

Re: [VOTE] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

What we’d usually do is revert the offending ticket and push it to the next 
release, if this indeed were significant enough.

So option 4 would be to revert CDC fast (painful) and ship.
Option 5 would be to quickly fix the issue, retag, and revote, with 3.9 still 
following up on schedule.
Option 6 would be to ignore the calendar entirely. Fix or revert the issue 
eventually, and release 3.8 then. Have 3.9 and 3.0.9 out at whatever time we 
decide to, and go back to monthly cycles from there on.

TBH I don’t think anybody is even going to notice, or care. So I’m fine with 1, 
4, 5, 6, but not reverting my +1 so far.

-- 
AY

On 21 July 2016 at 14:46:17, Sylvain Lebresne (sylv...@datastax.com) wrote:

On Thu, Jul 21, 2016 at 3:21 PM, Jonathan Ellis  wrote:  

> I see the alternatives as:  
>  
> 1. Release this as 3.8  
> 2. Skip 3.8 and release 3.9 next month on schedule  
> 3. Skip this month and release 3.8 next month instead  
>  

I've hopefully made it clear I don't really like 1. I'm totally fine with  
either 2 or 3 though (with a very very small preference for 3. because I  
suspect skipping a release might confuse a few users, but also knowing that  
2. has the small advantage of keeping the 3.0.x and 3.x versions released  
more or less in lockstep).  



>  
> On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko   
> wrote:  
>  
> > I still think the issue is minor enough, and with 3.8 being extremely  
> > delayed, and being a non-odd release, at that, we’d be better off just  
> > pushing it.  
> >  
> > Also, I know we’ve been easy on -1s when voting on releases, but I want  
> to  
> > remind people in general that release votes can not be vetoed and only  
> > require a majority of binding votes,  
> > http://www.apache.org/foundation/voting.html#ReleaseVotes  
> >  
> > --  
> > AY  
> >  
> > On 21 July 2016 at 08:57:22, Sylvain Lebresne (sylv...@datastax.com)  
> > wrote:  
> >  
> > Sorry but I'm (binding) -1 on this because of  
> > https://issues.apache.org/jira/browse/CASSANDRA-12236.  
> >  
> > I disagree that knowingly releasing a version that will temporarily break  
> > in-flight queries during upgrade, even if it's for a very short  
> time-frame  
> > until re-connection, is ok. I'll note in particular that in the test  
> > report, there is 74! failures in the upgrade tests (for reference the 3.7  
> > test report had only 2 upgrade tests failure both with open tickets).  
> Given  
> > that we have a known problem during upgrade, I don't really buy the "We  
> are  
> > assuming these are due to a recent downsize in instance size that these  
> > tests run on" and that suggest to me the problem is not too minor.  
> >  
> >  
> > On Thu, Jul 21, 2016 at 6:18 AM, Dave Brosius   
> > wrote:  
> >  
> > > +1  
> > >  
> > >  
> > > On 07/20/2016 05:48 PM, Michael Shuler wrote:  
> > >  
> > >> I propose the following artifacts for release as 3.8.  
> > >>  
> > >> sha1: c3ded0551f538f7845602b27d53240cd8129265c  
> > >> Git:  
> > >>  
> > >>  
> >  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
>   
> > >> Artifacts:  
> > >>  
> > >>  
> >  
> https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/
>   
> > >> Staging repository:  
> > >>  
> > >>  
> >  
> https://repository.apache.org/content/repositories/orgapachecassandra-1123/  
> > >>  
> > >> The debian packages are available here:  
> > >> http://people.apache.org/~mshuler/  
> > >>  
> > >> The vote will be open for 72 hours (longer if needed).  
> > >>  
> > >> [1]: http://goo.gl/oGNH0i (CHANGES.txt)  
> > >> [2]: http://goo.gl/KjMtUn (NEWS.txt)  
> > >> [3]: https://goo.gl/TxVLKo (3.8 Test Summary)  
> > >>  
> > >>  
> > >  
> >  
>  
>  
>  
> --  
> Jonathan Ellis  
> Project Chair, Apache Cassandra  
> co-founder, http://www.datastax.com  
> @spyced  
>  

Re: Blockers for 4.0

[Aleksey Yeschenko]

We don’t need to block 4.0 on #8110.

What we need is to block those sstable-format related tickets on *either* #8110 
*or* 4.0.

#8110 itself can go anywhere in 3.x or 4.x.

-- 
AY

On 21 July 2016 at 15:38:58, Jason Brown (jasedbr...@gmail.com) wrote:

Sylvain,  

In the large, yes, that is the best "have enough mechanism in place that no  
further ticket _have to_ wait for a major", but many of the tickets we are  
talking about makes changes to things we've all agreed can *only* happen at  
majors, as per the http://wiki.apache.org/cassandra/CompatibilityGuarantees  
(changing the internode protocol, for instance).  

if we're willing to trade on those Guarantees, then sure, majors are just  
bike shedding the version numbers, but I suspect we don't want to do that ;)  

That being said, I completely understand the frustration of "one more week,  
X is almost ready and we don't want to wait a year to get it in". I offer  
two points, though:  
1) This is an open source project, with no real business requirements to  
ship any version by any specific date. We want to ship often enough to be  
relevant as a project/product, of course, but there's no financial or  
business requirement to do so.  
2) We could have better planning as to what we actually want to ship in a  
"version", or at least have some agreed upon mid- to long-term roadmap.  
This would help focus the calendar and the project. Currently, it's largely  
willy-nilly as to what ships when, and while tick-tock has introduced  
regularity wrt release dates, there's not much that shapes what goes in  
those releases.  

My two cents,  

-Jason  



On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne   
wrote:  

> My very own preference would be to actually focus on making 4.0 the release  
> where have enough mechanism in place that no further ticket _have to_ wait  
> for a major. That means at least making sure CASSANDRA-12042 makes it in,  
> adding some proper versioning of schemas and CASSANDRA-8110.  
>  
> If we had all that in place, I think no other would _have to_ be ready for  
> 4.0 as it could then just be delayed to 4.2 (or whenever it's ready).  
>  
> If we don't do that, I'm willing to take bets that every new major release  
> every year will be delayed cause "one more week, X is almost ready and we  
> don't want to wait a year to get it in".  
>  
> On Wed, Jul 20, 2016 at 4:40 PM, Jonathan Ellis  wrote:  
>  
> > The plan of record has been to ship 4.0 in November, 12 months after 3.0.  
> > But, there are a number of features that are going to cause backwards  
> > incompatibility and if they miss 4.0 will need to wait for 5.0. Are any  
> of  
> > these worth delaying 4.0 for?  
> >  
> > (Currently the plan is to have all of these ready for November, but let's  
> > get our backup plan figured out now, just in case. That way we don't  
> have  
> > to make the decision at the last minute when everything feels like an  
> > emergency.)  
> >  
> > Some candidates that might be worth delaying the release for:  
> >  
> > - "Birch" trees for the primary key index  
> > . Changes the  
> > format of data on disk so automatically in the "dot zero" category.  
> > - Decouple messaging protocol versioning  
> > . This would  
> > allow us to change the intra-node protocol on a per-message basis,  
> which  
> > gives us more flexibility with compatibility. Currently any change  
> > drops  
> > us into the "no schema changes until everyone is upgraded" world which  
> > effectively rules out making any improvements across tick-tock  
> releases.  
> > - Allow dropping COMPACT STORAGE flag  
> > . This is  
> what  
> > makes it possible to remove the deprecated Thrift support.  
> > - Schema rearchitecture  
> > . Can we live  
> > without safe and programatic CREATE and ALTER for another year?  
> >  
> > --  
> > Jonathan Ellis  
> > Project Chair, Apache Cassandra  
> > co-founder, http://www.datastax.com  
> > @spyced  
> >  
>  

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

Sorry, but I’m counting 3 binding +1s and 1 binding -1 (2, if you interpret 
Jonathan’s emails as such).

Thus, if you were to do close the vote now, the vote is passing with the 
binding majority, and the required minimum # of +1s gained.

I also don’t see the PMC consensus on ‘August 3.8 release target’.

As such, the vote is now reopened for further discussion, and to allow PMC to 
change their votes if they feel like it (I, for one, have just returned, and 
need to reevaluate 12236 in light of new comments).

-- 
AY

On 25 July 2016 at 15:46:40, Michael Shuler (mshu...@apache.org) wrote:

Thanks for the clarity, Jonathan. I agree that an August 3.8 release  
target sounds like the most reasonable option, at this point in time.  

With Sylvain's binding -1, this vote has failed.  

--  
Kind regards,  
Michael Shuler  

On 07/21/2016 05:33 PM, Jonathan Ellis wrote:  
> I feel like the calendar is relevant though because if we delay 3.8 more  
> we're looking at a week, maybe 10 days before 3.9 is scheduled. Which  
> doesn't give us much time for the stabilizing we're supposed to do in 3.9.  
>  
> All in all I think I agree that releasing 3.8 in August is less confusing  
> than skipping it entirely. And I don't like the idea of ignoring a whole  
> bunch of test failures and hoping they don't mean anything, because we just  
> had that thread about getting more rigorous about tests, not less.  
>  
> So I would recommend we go ahead and fix this before releasing, and to  
> avoid a super compressed 3.9 window either retarget 3.8 for August, or 3.9  
> for September.  
>  
> On Thu, Jul 21, 2016 at 9:58 AM, Aleksey Yeschenko   
> wrote:  
>  
>> What we’d usually do is revert the offending ticket and push it to the  
>> next release, if this indeed were significant enough.  
>>  
>> So option 4 would be to revert CDC fast (painful) and ship.  
>> Option 5 would be to quickly fix the issue, retag, and revote, with 3.9  
>> still following up on schedule.  
>> Option 6 would be to ignore the calendar entirely. Fix or revert the issue  
>> eventually, and release 3.8 then. Have 3.9 and 3.0.9 out at whatever time  
>> we decide to, and go back to monthly cycles from there on.  
>>  
>> TBH I don’t think anybody is even going to notice, or care. So I’m fine  
>> with 1, 4, 5, 6, but not reverting my +1 so far.  
>>  
>> --  
>> AY  
>>  
>> On 21 July 2016 at 14:46:17, Sylvain Lebresne (sylv...@datastax.com)  
>> wrote:  
>>  
>> On Thu, Jul 21, 2016 at 3:21 PM, Jonathan Ellis  wrote:  
>>  
>>> I see the alternatives as:  
>>>  
>>> 1. Release this as 3.8  
>>> 2. Skip 3.8 and release 3.9 next month on schedule  
>>> 3. Skip this month and release 3.8 next month instead  
>>>  
>>  
>> I've hopefully made it clear I don't really like 1. I'm totally fine with  
>> either 2 or 3 though (with a very very small preference for 3. because I  
>> suspect skipping a release might confuse a few users, but also knowing that  
>> 2. has the small advantage of keeping the 3.0.x and 3.x versions released  
>> more or less in lockstep).  
>>  
>>  
>>  
>>>  
>>> On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko   
>>> wrote:  
>>>  
>>>> I still think the issue is minor enough, and with 3.8 being extremely  
>>>> delayed, and being a non-odd release, at that, we’d be better off just  
>>>> pushing it.  
>>>>  
>>>> Also, I know we’ve been easy on -1s when voting on releases, but I want  
>>> to  
>>>> remind people in general that release votes can not be vetoed and only  
>>>> require a majority of binding votes,  
>>>> http://www.apache.org/foundation/voting.html#ReleaseVotes  
>>>>  
>>>> --  
>>>> AY  
>>>>  
>>>> On 21 July 2016 at 08:57:22, Sylvain Lebresne (sylv...@datastax.com)  
>>>> wrote:  
>>>>  
>>>> Sorry but I'm (binding) -1 on this because of  
>>>> https://issues.apache.org/jira/browse/CASSANDRA-12236.  
>>>>  
>>>> I disagree that knowingly releasing a version that will temporarily  
>> break  
>>>> in-flight queries during upgrade, even if it's for a very short  
>>> time-frame  
>>>> until re-connection, is ok. I'll note in particular that in the test  
>>>> report, there is 74! failures in the upgrade tests (for reference the  
>> 3.7  
>>>> test report had only 2 upgrade tests failure both with open tickets).  
>>>