Re: [VOTE] Release Apache Cassandra 4.1-alpha1

[Aleksey Yeschenko]

+1

> On 24 May 2022, at 09:38, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 4.1-alpha1 for release.
> 
> sha1: 6f05be447073925a7f3620ddbbd572aa9fcd10ed
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1-alpha1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1273/org/apache/cassandra/cassandra-all/4.1-alpha1/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1-alpha1/
> 
> 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]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.1-alpha1-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.1-alpha1-tentative

Re: [VOTE] Release Apache Cassandra 4.0.3

[Aleksey Yeschenko]

+1

> On 15 Feb 2022, at 07:49, Marcus Eriksson  wrote:
> 
> +1
> 
> On Sun, Feb 13, 2022 at 11:03:01PM +0100, Mick Semb Wever wrote:
>> Proposing the test build of Cassandra 4.0.3 for release.
>> 
>> 
>> sha1: a87055d56a33a9b17606f14535f48eb461965b82
>> 
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.3-tentative
>> 
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1259/org/apache/cassandra/cassandra-all/4.0.3/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.3/
>> 
>> 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]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.3-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.3-tentative

Re: [DISCUSS] Disabling MIME-part filtering on this mailing list

[Aleksey Yeschenko]

Agreed as well.

> On 4 Dec 2021, at 23:28, bened...@apache.org wrote:
> 
> I think you were correct to start a DISCUSS thread, Bowen. You should not 
> start a vote until you have first established if there is consensus.
> 
> Also, I agree with the proposal.
> 
> From: Bowen Song 
> Date: Saturday, 4 December 2021 at 23:12
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] Disabling MIME-part filtering on this mailing list
> Hmm.. It's too late to change that. I opened it as "DISCUSS" because I
> was not sure if the information in it is enough for people to vote on
> it. There's clearly a lot more can be asked or discussed. For example
> the change will also stop the "To unsubscribe, ..." footer being
> appended to some emails (but not this one), and that may cause some
> difficulties for some people to find the unsubscribe link/address.
> 
> Hint #1: you can find the unsubscribe button where you found
>  the subscribe button.
> 
> Hint #2: you can also find the unsubscribe address in the email header
> "List-Unsubscribe"
> 
> Hint #3: failing all the above, you can also ask in the list. I'm sure
> other people will help.
> 
> On 04/12/2021 22:31, Mick Semb Wever wrote:
>>> What's your opinion on this? Do you support or oppose disabling the
>>> MIME-part filtering on the Cassandra-dev mailing list?
>> 
>> +1
>> 
>> (nit: am thinking the thread should have had a [VOTE] prefix, since you are
>> calling out for consensus)
>> 


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

Re: [VOTE] CEP-15: General Purpose Transactions

[Aleksey Yeschenko]

+1 on all points

> On 14 Oct 2021, at 17:31, bened...@apache.org wrote:
> 
> Hi everyone,
> 
> I would like to start a vote on this CEP, split into three sub-decisions, as 
> discussion has been circular for some time.
> 
> 1. Do you support adopting this CEP?
> 2. Do you support the transaction semantics proposed by the CEP for Cassandra?
> 3. Do you support an incremental approach to developing transactions in 
> Cassandra, leaving scope for future development?
> 
> The first vote is a consensus vote of all committers, the second and third 
> however are about project direction and therefore are simple majority votes 
> of the PMC.
> 
> Recall that all -1 votes must be accompanied by an explanation. If you reject 
> the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
> majority reject grounds (2) or (3) then transaction developments will halt 
> for the time being.
> 
> This vote will be open for 72 hours.


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

Re: [DISCUSS] CEP-15: General Purpose Transactions

[Aleksey Yeschenko]

Lacking the most basic support for multi-partition transactions is a serious 
handicap. The CEP offers a concrete solution.

It’s possible to solve multi-partition transactions in a myriad of other ways, 
I’m sure, but CEP-15 is what’s on offer for Cassandra at the moment, and I’m 
not seeing any alternative CEPs with folks lined up to implement them.

The CEP is a clear and meaningful improvement over status quo. The engineers 
behind it are committed to doing the implementation work and can be trusted to 
stick around for maintenance. It’s been a month now, please, let’s get this 
going.

> On 11 Oct 2021, at 13:43, bened...@apache.org wrote:
> 
> For those who missed it, my talk discussing this CEP at ApacheCon is now 
> available to view:  https://www.youtube.com/watch?v=YAE7E-QEAvk
> 
> 
> 
> From: Oleksandr Petrov 
> Date: Monday, 11 October 2021 at 10:11
> To: dev 
> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
>> I support this proposal. From what I can understand, this proposal  moves
> us towards having the building blocks we need to correctly deliver some of
> the most often requested features in Cassandra.
> 
> Same here. I also support this proposal and believe it opens up many new
> opportunities (while not limiting us / not narrowing our future options),
> can help us implement features we've all wanted to have implemented for
> years, and make significant improvements in the subsystems that were a
> source of issues for a long time.
> 
> I think it's also good to start with CAS batches: it's a great way to make
> the feature available and work incrementally. After this lands, people will
> be able to use Accord/MPT in different subsystems and get busy
> implementing all sorts of other features and improvements on top of it.
> 
> 
> 
> 
> On Sat, Oct 9, 2021 at 4:18 PM Joseph Lynch  wrote:
> 
>>> With the proposal hitting the one-month mark, the contributors are
>> interested in gauging the developer community's response to the proposal.
>> 
>> I support this proposal. From what I can understand, this proposal
>> moves us towards having the building blocks we need to correctly
>> deliver some of the most often requested features in Cassandra. For
>> example it seems to unlock: batches that actually work, registers that
>> offer fast compare and swap, global secondary indices that can be
>> correctly maintained, and more. Therefore, given the benefit to the
>> community, I support working towards that foundation that will allow
>> us to build solutions in Cassandra that pay consensus closer to
>> mutation instead of lazily at read/repair time.
>> 
>> I think the feedback in this thread around interface (what statements
>> will this facilitate and how will the library integrate with Cassandra
>> itself), performance (how fast will these transactions be, will we
>> offer bounded stale reads, etc ...), and implementation (how does this
>> compare/contrast with other consensus approaches) has been
>> informative, but at this point I think it makes sense to start trying
>> to make incremental progress towards a functional integration to
>> discover any remaining areas for improvement.
>> 
>> Cheers and thank you!
>> -Joey
>> 
>> 
>> 
>> On Thu, Oct 7, 2021 at 10:51 AM C. Scott Andreas 
>> wrote:
>>> 
>>> Hi Jonathan,
>>> 
>>> Following up on my message yesterday as it looks like our replies may
>> have crossed en route.
>>> 
>>> Thanks for bumping your message from earlier in our discussion. I
>> believe we have addressed most of these questions on the thread, in
>> addition to offering a presentation on this and related work at ApacheCon,
>> a discussion hosted following that presentation at ApacheCon, and in ASF
>> Slack. Contributors have further offered an opportuntity to discuss
>> specific questions via videoconference if it helps to speak live. I'd be
>> happy to do so as well.
>>> 
>>> Since your original message, discussion has covered a lot of ground on
>> the related databases you've mentioned:
>>> – Henrik has shared expertise related to MongoDB and its implementation.
>>> – You've shared an overview of Calvin.
>>> – Alex Miller has helped us review the work relative to other Paxos
>> algorithms and identified a few great enhancements to incorporate.
>>> – The paper discusses related approaches in FoundationDB, CockroachDB,
>> and Yugabyte.
>>> – Subsequent discussion has contrasted the implementation to DynamoDB,
>> Google Cloud BigTable, and Google Cloud Spanner (noting specifically that
>> the protocol achieves Spanner's 1x round-trip without requiring specialized
>> hardware).
>>> 
>>> In my reply yesterday, I've attempted to crystallize what becomes
>> possible via CQL: one-shot multi-partition transactions in the first
>> implementation and a 4x latency reduction on writes / 2x latency reduction
>> on reads relative to today; along with the ability to build upon this work
>> to enable interactive transactions in the future.
>>> 
>>> I believe we've exercised the qu

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

[Aleksey Yeschenko]

+1

> On 23 Jul 2021, at 14:03, Joshua McKenzie  wrote:
> 
> +1
> 
> On Fri, Jul 23, 2021 at 8:07 AM Dinesh Joshi 
> wrote:
> 
>> +1
>> 
>> 
>>> On Jul 23, 2021, at 4:56 AM, Paulo Motta 
>> wrote:
>>> 
>>> +1
>>> 
 Em sex., 23 de jul. de 2021 às 08:37, Andrés de la Peña <
 a.penya.gar...@gmail.com> escreveu:
 
 +1
 
> On Fri, 23 Jul 2021 at 11:56, Sam Tunnicliffe  wrote:
> 
> +1
> 
>> On 22 Jul 2021, at 23:40, Brandon Williams <
>> brandonwilli...@apache.org
> 
> wrote:
>> 
>> I am proposing the test build of Cassandra 4.0.0 for release.
>> 
>> sha1: 902b4d31772eaa84f05ffdc1e4f4b7a66d5b17e6
>> Git:
> 
 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
>> Maven Artifacts:
>> 
> 
 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1244/org/apache/cassandra/cassandra-all/4.0.0/
>> 
>> The Source and Build Artifacts, and Debian and RPM packages and
>> repositories are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
>> 
>> 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]: CHANGES.txt:
>> 
> 
 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
>> [2]: NEWS.txt:
> 
 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


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

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

[Aleksey Yeschenko]

I would say just go with it. JMX isn’t quite deprecated yet, and if we ever 
even end up doing that, it’s not going to be any time soon.

> On 16 Jul 2021, at 13:32, Stefan Miklosovic 
>  wrote:
> 
> Thanks Benjamin for the understanding, but in the end, let's put aside
> the frustration here, I think I can just kind of detach from that.
> 
> However, in this particular case, I really think we should just finish
> this and merge it and move on. By not doing so and waiting for the CEP
> around this, we are just opening ourselves to a possibility that it
> will not be finished / implemented and we will live without that
> command.
> 
> In other words, I just do not like to not do something, when it just
> lies in front of me, just because of some assumption we make that
> something will happen in the future. I do not get this approach. The
> future might just change. Plus this is just an easy patch, no big
> deal, it is not like I would have to revert the heaps of code to
> accommodate future features.
> 
> If I do not merge it, I am afraid this might happen:
> 
> A user (lets call him Tommy), is excited about 4.0, they are using
> some custom auditing and he wants to give a shot to native stuff we
> provide here. So he goes and downloads, tries it, all is good.
> Then he realises that it was a long time ago he set this up, messed
> with that a bit and kept it running. But after a while, he forgot how
> he set it up. So he looks into nodetool and sees, yay, enableauditlog,
> disableauditlog, there are a bunch of get* commands too, but no status
> of audit log? How can I know how that is set up?
> 
> So Tommy reaches the community and says that hey, you are missing that
> command, am I going to see it in 4.1 or in some patch release at least
> to get it sooner?
> 
> And we reply:
> 
> Dear Tommy,
> 
> we know it is missing, but wait! There is this CEP we are working day
> and night on, it will solve the world hunger and it will be the best
> thing since the sliced bread, you just have to wait a little bit
> longer, because there are other things going on right now and it seems
> to take longer than expected, lot of problems on the way, so maybe
> return in 4.3 and there you get it.
> 
> But Tommy does not care. He truly does not. He just wants to query the
> state of the audit log by any means necessary. And once this happens
> multiple times he just goes away.
> 
> By the way, I really think this is a little bit more complicated than
> it seems. It is hard to guess how the implementation will look like
> but in our original discussion with Paulo, we were thinking about
> having a completely separate repository for this where only the client
> would be. There are few benefits - it might be just released
> independently, if we truly separate this and we talk only CQL, I do
> not see any reason why we should depend on the main Cassandra
> repository. It also lowers the barrier for other people who would want
> to implement the command they miss. However, I get that while we want
> to support both approaches, it will be done and probably it has to be
> done together, but I am afraid that we will just introduce a hybrid
> which would take ages to finish fully so we can announce JMX
> deprecated. There are a lot of commands to be migrated as well and
> having a separate repository would at least make the main repo less
> noisy. But since I am not fully aware of what approach we end up with
> and how the implementation would look like in the end, I can not fully
> advocate the separate repository approach because it might be just
> rendered ineffective and wrong.
> 
> That's just my rambling here but I would just close the issue with
> 16725 by merging that and then we can fully focus on CEP and all
> things related.
> 
> Sounds good to everybody?
> 
> Regards
> 
> 
> On Fri, 16 Jul 2021 at 10:44, Benjamin Lerer  wrote:
>> 
>> Thanks a lot for all the feedback, I really appreciate the discussion and
>> Paulo's proposals.
>> 
>> Regarding the ongoing patches:
>> 
>> Based on the discussion, it clearly appears that nodetool will still be
>> there for some time (and will be there in the next major release).
>> As such, it seems to me that the current ongoing patches to add new
>> nodetool commands will be useful.
>> I honestly do not see the point at this stage of preventing them from going
>> in and I can totally understand the frustration of the people that have
>> spent time on making them.
>> I did not trigger that discussion with that goal in mind. My goal was more
>> to clarify our strategy for the future.
>> 
>> It seems only fair to me to let these patches go in and simply thank the
>> contributors for their efforts and work.
>> We can open some followup tickets for providing those functionalities
>> through Virtual Tables (we are only talking about 2 patches).
>> If nobody else takes them, I will.
>> 
>> 
>> Le ven. 16 juil. 2021 à 10:17, Mick Semb Wever  a écrit :
>> 
 
> Until CEP exists and is appr

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

[Aleksey Yeschenko]

We could eventually make a virtual table only mode to resolve this - not serve 
any data until a node is ready to do so - if necessary.

> On 15 Jul 2021, at 17:43, Jeff Jirsa  wrote:
> 
> There's a tactical issue, too, that virtual tables require native transport
> to be up before it's usable, so for things pre-startup (e.g. querying
> streaming state during bootstrap), so I don't think nodetool/jmx dies
> entirely ever (or, a non-client-facing-virtual-tables-only port has to be
> created, but that's much more involved obviously)
> 
> On Thu, Jul 15, 2021 at 9:18 AM Lorina Poland  wrote:
> 
>> I think it is important to keep in mind that users may be utilizing
>> nodetool programmatically, in scripts. Obviously, those scripts could use
>> calls to cqlsh as an alternative, but I'm a fan of keeping nodetool intact,
>> building out virtual table capability, and then deprecating nodetool. In
>> other words, only deprecate/remove nodetool commands once a *whole*
>> replacement is available. And then deprecate slowly, perhaps with migration
>> help in the docs for nodetool -> virtual tables.
>> 
>> Lorina
>> 
>> On Thu, Jul 15, 2021 at 6:59 AM Paulo Motta 
>> wrote:
>> 
>>> Perhaps one approach to expose VirtualTables via nodetool without
>> requiring
>>> the user to provide CQL credentials would be to provide a generic
>>> StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
>>> TabularData result. This would allow to keep a consistent nodetool
>> frontend
>>> to users while progressively switching the backend from JMX to
>>> VirtualTables.
>>> 
>>> We could create a framework to automatically expose a basic nodetool
>>> getter/setter command whenever a new virtual table is added, making the
>> new
>>> feature visible to non-power nodetool users while requiring little
>>> additional effort from the VirtualTable implementor.
>>> 
>>> When migrating commands from JMX to VirtualTables we could just update
>> the
>>> legacy nodetool command implementation to access the virtual table via
>> the
>>> generic StorageServiceMBean.queryVirtualTable(String name) method while
>>> keeping the output consistent with the previous implementation, and
>>> deprecating their JMX counterpart.
>>> 
>>> Ultimately when all commands are migrated from JMX to VirtualTables we
>>> could decide if we want to keep the nodetool CLI, acessing all virtual
>>> tables via the generic JMX virtual table accessor, or to deprecate
>> nodetool
>>> altogether and tell users to query virtual tables directly via cqlsh
>>> instead.
>>> 
>>> Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <
>>> pauloricard...@gmail.com>
>>> escreveu:
>>> 
 Thanks for bringing this discussion Benjamin. I raised a similar point
>> in
 CASSANDRA-16725 >> 
 and it may become a recurrent topic now the code freeze is lifted and
>>> more
 contributors will want to add new administrative commands to nodetool
>> so
 it's important that we discuss and decide a consistent approach to this
 transition moving forward.
 
 I was planning to write a CEP to propose a migration strategy from JMX
>> to
 Virtual tables but since this discussion came before I will detail my
 thoughts so far.
 
 I think that we should add new commands exclusively to Virtual Tables
>> and
 progressively migrate existing nodetool/JMX commands to
>> VirtualTables/CQL
 until we ultimately get rid of JMX/nodetool. Nevertheless, from the
>> user
 point of view it may be inconvenient/confusing to have administrative
 commands split between different interfaces so we need to think about
>>> this
 transition carefully to provide the best possible user experience.
 
 My motivation for CASSANDRA-16513 <
 https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
 already providing some functionalities exclusively via Virtual Tables,
>> so
 these features may not be visible to non-power users which are
>> accustomed
 to the nodetool CLI interface for admin commands. The original plan for
 that ticket was to make nodetool abstract away the underlying interface
 (JMX, CQL) for administrative commands, so we would expose admin
 functionality via the same CLI interface (nodetool) to users while
 progressively migrating the backend from JMX to CQL/VirtualTables.
 
 Some people raised the concern that this could cause confusion among
>>> users
 about which credentials to use if JMX or CQL for nodetool. Based on
>> this
 feedback I adapted the proposal to create an entirely different
 administrative CLI tool (which I called admintool) to access/modify
>>> virtual
 tables. In this proposal new administrative commands would be added
 exclusively to Virtual Tables and would automatically land on this
>> tool,
 and legacy nodetool commands (via JMX) would be progressively migrated
>> to
 admintool (C

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

[Aleksey Yeschenko]

+1

> On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
> 
> +1
> 
> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever  wrote:
> 
>> Proposing the test build of Cassandra 4.0.0 for release.
>> 
>> sha1: 924bf92fab1820942137138c779004acaf834187
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
>> Maven Artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
>> 
>> 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]: CHANGES.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
> 
> -- 
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced


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

Re: [VOTE] Release Apache Cassandra 4.0-rc2

[Aleksey Yeschenko]

+1

> On 28 Jun 2021, at 14:05, Gary Dusbabek  wrote:
> 
> +1; yay!
> 
> On Sun, Jun 27, 2021 at 11:02 AM Mick Semb Wever  wrote:
> 
>> Proposing the test build of Cassandra 4.0-rc2 for release.
>> 
>> sha1: 4c98576533e1d7663baf447e8877788096489165
>> Git:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc2-tentative
>> Maven Artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1237/org/apache/cassandra/cassandra-all/4.0-rc2/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc2/
>> 
>> 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]: CHANGES.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc2-tentative
>> [2]: NEWS.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc2-tentative
>> [3]: The maven artifacts were accidentally prematurely made public. Docs
>> have been updated to prevent this happening again.
>> 


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

Re: Additions to Cassandra ecosystem page?

[Aleksey Yeschenko]

+1

> On 24 Jun 2021, at 10:22, Sam Tunnicliffe  wrote:
> 
> +1
> 
>> On 23 Jun 2021, at 22:31, Jeff Jirsa  wrote:
>> 
>> This would be my preference.
>> 
>> 
>> On Wed, Jun 23, 2021 at 2:22 PM Ben Bromhead  wrote:
>> 
>>> I'm also comfortable with a strict approach where we just list actual
>>> Apache Cassandra offerings, that also provides good solid clarity to users.
>>> 
>>> On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org 
>>> wrote:
>>> 
 +1
 
 From: Brandon Williams 
 Date: Wednesday, 23 June 2021 at 15:44
 To: dev@cassandra.apache.org 
 Subject: Re: Additions to Cassandra ecosystem page?
 On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie 
 wrote:
> 
> The obvious core responsibility of the website should be to ASLv2
> permissively licensed Apache Cassandra and secondarily to CQL as a
 protocol
> IMO. I don't think we as a project should be tracking derivative works,
> forks, or other things built on top of the code-base and certainly not
> things with wildly varied licensing (AGPL, proprietary closed, etc).
 
 I agree.  I don't see how it makes sense for us to promote less
 compatible derivatives with more restrictive licensing.  Imitation may
 be flattery but as you pointed out, we don't need to be the ones
 advertising it.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
>>> 
>>> 
>>> --
>>> 
>>> Ben Bromhead
>>> 
>>> Instaclustr | www.instaclustr.com | @instaclustr
>>>  | +64 27 383 8975
>>> 
> 
> 
> -
> 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: [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

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

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

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: 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: [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: [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: [RESULT][VOTE] Ask Infra to move github notification emails to pr@

[Aleksey Yeschenko]

+1

—
AY

On 28 July 2017 at 11:47:29, Stefan Podkowinski (s...@apache.org) wrote:

Can we forward notifications for the new cassandra-dtest repo there as well?  

On 24.03.2017 18:59, Jeff Jirsa wrote:  
> With 6 binding +1s, 6 non-binding +1s, and no -1s of any kind, the vote 
> passes, I'll ask for a new mailing list and get this transitioned.  
>  
> - Jeff  
>  
> On 2017-03-20 15:32 (-0700), Jeff Jirsa  wrote:  
>> There's no reason for the dev list to get spammed everytime there's a  
>> github PR. We know most of the time we prefer JIRAs for real code PRs, but  
>> with docs being in tree and low barrier to entry, we may want to accept  
>> docs through PRs ( see https://issues.apache.org/jira/browse/CASSANDRA-13256 
>>  
>> , and comment on it if you disagree).  
>>  
>> To make that viable, we should make it not spam dev@ with every comment.  
>> Therefore I propose we move github PR comments/actions to pr@ so as  
>> not to clutter the dev@ list.  
>>  
>> Voting to remain open for 72 hours.  
>>  
>> - Jeff  
>>  

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

Re: Integrating vendor-specific code and developing plugins

[Aleksey Yeschenko]

I’m with Sylvain on this for essentially same reasons.

If we need to improve our extensibility here, we should do that, and then have 
niche platform specific code
be an external plug-in (and add a link to the plug-in to our docs, to promote 
it).

-- 
AY

On 12 May 2017 at 12:36:33, Sylvain Lebresne (sylv...@datastax.com) wrote:

On Fri, May 12, 2017 at 12:29 AM, Jason Brown  wrote:  

> Hey all,  
>  
> I'm on-board with what Rei is saying. I think we should be open to, and  
> encourage, other platforms/architectures for integration. Of course, it  
> will come down to specific maintainers/committers to do the testing and  
> verification on non-typical platforms. Hopefully those maintainers will  
> also contribute to other parts of the code base, as well, so I see this as  
> another way to bring more folks into the project.  
>  

Without going so far as to say we shouldn't merge any  
platform/architecture/vendor specific code ever and for no reason, I  
personally think we should avoid doing so as much as practical and  
encourage the "plugins" route instead. It's just much cleaner imo on  
principle and amounts to good software development hygiene.  

I don't want to not be able to commit some changes because it breaks the  
build because there is code for X number of super specific  
platform/architecture I don't have access to/don't know anything about  
and the maintainers are on vacation or hasn't been reachable in a while.  
And what if such maintainer do go away? Sure we can have some "process"  
to remove the code in such cases, but why add that burden on us? Plus  
we, the Apache Cassandra project, would still be seen as the ones that  
drop support for said platform/architecture even though we really have  
no choice if it's something we don't have access to anyway.  

And sure, I'm painting a bleak picture here, and we would probably have  
none of those problems in most cases. But if we do start encourage  
actual merge of such code, you can be sure we'll have some of those  
problems at some point.  

Encouraging plugins have imo pretty much all the benefits with none of  
the risks. In particular, I'm unconvinced that someone will be  
much more likely to meaningfully contribute to other part of the code  
if his "plugins" is in-tree versus out of it.  

*But* I can certainly agree with the part about us not having done a  
good job to promote plugins and it make sense to me to try to improve on  
that.  


>  
> WRT extensibility, it just requires someone to do the work of making  
> reasonable abstraction points - and documenting them ;). The interesting  
> question comes down to how to host/ship any pluggable dependencies. Much  
> like what we had with jna before they relicensed, we'll probably ship some  
> things in-tree and some things users will have to fetch and deploy  
> themselves; it's a case-by-case basis.  
>  
> Thanks,  
>  
> -Jason  
>  
>  
> On Thu, May 11, 2017 at 2:59 PM, 大平怜  wrote:  
>  
> > Hi all,  
> >  
> > In this JIRA ticket https://issues.apache.org/  
> jira/browse/CASSANDRA-13486,  
> > we proposed integrating our code to support a fast flash+FPGA card  
> (called  
> > CAPI Flash) only available in the ppc architecture. Although we will keep  
> > discussing the topics specific to the patch (e.g. documentation, license,  
> > code quality) in the JIRA, we would like to start in this dev list more  
> > general discussion about how to (and how not to) merge  
> > architecture-specific (or vendor-specific) changes.  
> >  
> > I think in the end the problem boils down to how to test the  
> > architecture-specific code. The original contributors of the  
> > architecture-specific code can keep "supporting" the code in a sense that  
> > when a problem arises they can fix it and send a patch, but the  
> committers  
> > cannot test it anyway. Are there any other factors we must consider?  
> >  
> > Also, in this particular case, it is relatively easy to turn the code  
> > change into a plugin because it extended the already-pluggable  
> RowCache. I  
> > feel Cassandra has promoted the plugins not so much as other pluggable  
> > software have done like Eclipse, Apache HTTP server, fluentd, etc. For  
> > example, they have a list of plugins in their Web pages. I think if the  
> > community wants to encourage developers to maintain vendor-specific code  
> as  
> > plugins outside of the main source tree, a deeper commitment to the  
> plugin  
> > ecosystem would be appreciated.  
> >  
> > What do you think?  
> >  
> >  
> > Thanks,  
> > Rei Odaira  
> >  
>  

Re: [VOTE] Release Apache Cassandra 3.0.13

[Aleksey Yeschenko]

+1

-- 
AY

On 11 April 2017 at 19:59:32, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.0.13.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/xBbbHa  
[2]: (NEWS.txt) https://goo.gl/PlsFmm  

Re: unsubscribe

[Aleksey Yeschenko]

Unsubscribe applications rejected, sorry.

-- 
AY

On 10 April 2017 at 14:10:05, Sara Prokop (sara.pro...@g2-ops.com) wrote:

Unsubscribe  


Sara Prokop  
G2 Ops, Inc.  

Office: 757-330-0372  

205 Business Park Drive, Suite 200  
Virginia Beach, VA, 23462  


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. Please 
note that any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of the company. Finally, the 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email  

  
From: alivesubsta...@gmail.com   
Sent: Sunday, April 9, 2017 9:20:50 AM  
To: dev@cassandra.apache.org  
Subject: Re: unsubscribe  

Unsubscribe  

Sent from my HTC  

- Reply message -  
From: "Michael Kjellman"   
To: "dev@cassandra.apache.org"   
Subject: unsubscribe  
Date: Thu, Apr 6, 2017 19:59  


http://apache.org/foundation/mailinglists.html  

Sent from my iPhone  

On Apr 6, 2017, at 9:57 AM, Nitija Patil 
mailto:nitij...@gmail.com>> wrote:  

unsubscribe  

On Thu, Apr 6, 2017 at 10:25 PM, Vineet Gadodia 
mailto:gadodi...@gmail.com>> wrote:  

unsubscribe  

On Wed, Apr 5, 2017 at 1:51 AM, Ksawery Glab 
mailto:ksaweryg...@gmail.com>>  
wrote:  

unsubscribe  

2017-04-05 9:45 GMT+01:00 Nitija Patil 
mailto:nitij...@gmail.com>>:  

unsubscribe  

On Wed, Apr 5, 2017 at 2:05 PM, 郑蒙家(蒙家) 

Re: [VOTE] self-assignment of jira tickets

[Aleksey Yeschenko]

+1 super binding.

-- 
AY

On 29 March 2017 at 16:22:03, Jason Brown (jasedbr...@gmail.com) wrote:

Hey all,  

Following up my thread from a week or two ago (  
https://lists.apache.org/thread.html/0665f40c7213654e99817141972c003a2131aba7a1c63d6765db75c5@%3Cdev.cassandra.apache.org%3E),
  
I'd like to propose a vote to change to allow any potential contributor to  
assign a jira to themselves without needing to be added to the contributors  
group first.  

https://issues.apache.org/jira/browse/INFRA-11950 is an example of how to  
get this done with INFRA.  

Vote will be open for 72 hours.  

Thanks,  

-Jason Brown  

Re: [VOTE] Release Apache Cassandra 3.0.12

[Aleksey Yeschenko]

+1

-- 
AY

On 7 March 2017 at 16:15:32, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.0.12.  

This release addresses a possible 2.1->3.0 upgrade issue[3], along with  
a few fixes committed since 3.0.11.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/RtBFVA  
[2]: (NEWS.txt) https://goo.gl/GGI0aq  
[3]: https://issues.apache.org/jira/browse/CASSANDRA-13294  

Re: [VOTE] Release Apache Cassandra 3.0.11

[Aleksey Yeschenko]

+1

-- 
AY

On 16 February 2017 at 01:15:46, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.0.11.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/ztSHQJ  
[2]: (NEWS.txt) https://goo.gl/nrengr  

--  
Kind regards,  
Michael Shuler  

Re: [VOTE] Release Apache Cassandra 2.1.17

[Aleksey Yeschenko]

+1

-- 
AY

On 16 February 2017 at 01:16:59, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 2.1.17.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/17RivH  
[2]: (NEWS.txt) https://goo.gl/axKXys  

--  
Kind regards,  
Michael Shuler  

Re: [VOTE] Release Apache Cassandra 2.2.9

[Aleksey Yeschenko]

+1

-- 
AY

On 16 February 2017 at 01:16:14, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 2.2.9.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/AYblr5  
[2]: (NEWS.txt) https://goo.gl/gIXxgR  

--  
Kind regards,  
Michael Shuler  

Re: MV improvements

[Aleksey Yeschenko]

To some extent it’s fluid.

For outright MV bugs (correctness, severe performance issues), 3.11 would still 
be allowed.
Unless the change set touches too much code and is deemed to be potentially 
destabilising.

I would recommend starting all the work on trunk, and on case-by-case basis 
(think committer consensus),
backport all/some of the patches to 3.11. 

-- 
AY

On 15 February 2017 at 19:51:09, Benjamin Roth (benjamin.r...@jaumo.com) wrote:

Hi there,  

I'd like to start working on some MV improvements the next days. I created  
several tickets for that some weeks ago.  

Which is the right branch to start working on? The tick-tock discussion  
about different branches lately was a bit confusing.  

Second question:  
Is there anybody out there who would like to assist me or would like to  
work together on that?  
I have several ideas for improvements and I'd love to work on them but I  
know only a small part of the whole code base and also have little  
experience with the history of the code base. If not, I will start alone  
but I'd appreciate any kind of support.  

Thanks folks!  

--  
Benjamin Roth  
Prokurist  

Jaumo GmbH · www.jaumo.com  
Wehrstraße 46 · 73035 Göppingen · Germany  
Phone +49 7161 304880-6 · Fax +49 7161 304880-1  
AG Ulm · HRB 731058 · Managing Director: Jens Kammerer  

Re: cassandra-3.X branch, 3.x version, cleanup

[Aleksey Yeschenko]

A handy filter to see if you’ve got any JIRAs as assignee/reviewer that need 
correction:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20Cassandra%20and%20fixVersion%20%3D%203.x%20and%20statusCategory%20%3D%20Complete%20and%20((reviewer%20%3D%20currentUser())%20or%20(assignee%20%3D%20currentUser()))

-- 
AY

On 5 February 2017 at 17:47:33, Aleksey Yeschenko (alek...@apache.org) wrote:

HI all.

Now that 3.10 has finally been released, I’ve cleaned up several things, as 
promised:

1. Cherry-picked bug fixes from cassandra-3.X branch into cassandra-3.11 branch
2. Fixed up CHANGES.txt in both cassandra-3.11 branch and trunk
3. Dropped cassandra-3.X branch altogether
4. Added 3.11.x version placeholder, got rid of 3.12 version

What remains to be done:

1. Get rid of 3.x version in JIRA, by relabelling all affected issues

For uncommitted future 3.11 bug fixes, please use the new 3.11.x fixver on JIRA.

Current merge order: 2.1 -> 2.2 -> 3.0 -> 3.11 -> trunk.

P.S. While cleaning things up, I’ve noticed a lot of resolved JIRA issues with 
.x version placeholders.
To committers: please, set the fixver to a concrete version when resolving the 
JIRA. Don’t make others
dig through git log to determine where the patch went into eventually.

Also, when resolving as Duplicate or Won’t Fix or Not a Problem, please remove 
the version in fixversion field altogether.

Thank you.

-- 
AY

cassandra-3.X branch, 3.x version, cleanup

[Aleksey Yeschenko]

HI all.

Now that 3.10 has finally been released, I’ve cleaned up several things, as 
promised:

1. Cherry-picked bug fixes from cassandra-3.X branch into cassandra-3.11 branch
2. Fixed up CHANGES.txt in both cassandra-3.11 branch and trunk
3. Dropped cassandra-3.X branch altogether
4. Added 3.11.x version placeholder, got rid of 3.12 version

What remains to be done:

1. Get rid of 3.x version in JIRA, by relabelling all affected issues

For uncommitted future 3.11 bug fixes, please use the new 3.11.x fixver on JIRA.

Current merge order: 2.1 -> 2.2 -> 3.0 -> 3.11 -> trunk.

P.S. While cleaning things up, I’ve noticed a lot of resolved JIRA issues with 
.x version placeholders.
To committers: please, set the fixver to a concrete version when resolving the 
JIRA. Don’t make others
dig through git log to determine where the patch went into eventually.

Also, when resolving as Duplicate or Won’t Fix or Not a Problem, please remove 
the version in fixversion field altogether.

Thank you.

-- 
AY

Re: [VOTE] Release Apache Cassandra 3.10 (Take 5)

[Aleksey Yeschenko]

+1

-- 
AY

On 31 January 2017 at 21:29:32, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.10.  

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

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

- All unit test variations passed on this sha.  
- 2 dtests failed on this sha with known failures:  
- TestAuthUpgrade - CASSANDRA-11469  
- TestReadFailures - CASSANDRA-13167 (passed on re-run)  

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

[1]: (CHANGES.txt) https://goo.gl/XDn15n  
[2]: (NEWS.txt) https://goo.gl/tvmL8j  

Re: [VOTE] 3.X branch feature freeze

[Aleksey Yeschenko]

I’m counting 6 binding PMC +1s, 4 non-binding +1s, and no -1s of any kind.

From now on, please skip merging into the 3.X branch on the way to trunk.

The new merge order: 2.1 -> 2.2 -> 3.0 -> 3.11 -> trunk.

I will take care of what’s currently in 3.X branch, NEWS, CHANGES, and JIRA 
fixversions
when 3.10 gets released.

Thank you.

-- 
AY

On 14 January 2017 at 21:35:35, Nate McCall (zznat...@gmail.com) wrote:

+1  
Thanks for bringing this up.  

On Sat, Jan 14, 2017 at 6:21 AM, Aleksey Yeschenko  wrote:  
> Hi all!  
>  
> It seems like we have a general consensus on ending tick-tock at 3.11, and 
> moving  
> on to stabilisation-only for 3.11.x series.  
>  
> In light of this, I suggest immediate feature freeze in the 3.X branch.  
>  
> Meaning that only bug fixes go to the 3.11/3.X branch from now on.  
>  
> All new features that haven’t be committed yet should go to trunk only (4.0), 
> if the vote passes.  
>  
> What do you think?  
>  
> Thanks.  
>  
> --  
> AY  

Re: [VOTE] Release Apache Cassandra 3.10 (Take 4)

[Aleksey Yeschenko]

+1

-- 
AY

On 14 January 2017 at 00:47:08, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.10.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/WaAEVn  
[2]: (NEWS.txt) https://goo.gl/7deAsG  

All of the unit tests passed and the main dtest job passed.  

https://cassci.datastax.com/job/cassandra-3.11_testall/47/  
https://cassci.datastax.com/job/cassandra-3.11_utest/55/  
https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/  
https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/  
https://cassci.datastax.com/job/cassandra-3.11_dtest/31/  

--  
Kind regards,  
Michael Shuler  

Re: [VOTE] 3.X branch feature freeze

[Aleksey Yeschenko]

In my opinion, stabilising MVs would count towards bug fixing, to totally 
acceptable
for the 3.11.X line. No conflict here.

-- 
AY

On 13 January 2017 at 17:56:06, Jonathan Haddad (j...@jonhaddad.com) wrote:

+1 (non binding) to feature freeze.  

I also like the idea of stabilizing MVs. Ben, you've probably been the  
most vocal about the issues, have you made any progress towards making them  
work any better during bootstrap / etc? Any idea of fixing them is a major  
undertaking?  

Jon  

On Fri, Jan 13, 2017 at 9:39 AM Benjamin Roth   
wrote:  

+1 also I appreciate any effort on MV stability. It is an official 3.x  
feature but not production ready for the masses.  

Am 13.01.2017 18:34 schrieb "Jonathan Ellis" :  

> +1  
>  
> On Fri, Jan 13, 2017 at 11:21 AM, Aleksey Yeschenko   
> wrote:  
>  
> > Hi all!  
> >  
> > It seems like we have a general consensus on ending tick-tock at 3.11,  
> and  
> > moving  
> > on to stabilisation-only for 3.11.x series.  
> >  
> > In light of this, I suggest immediate feature freeze in the 3.X branch.  
> >  
> > Meaning that only bug fixes go to the 3.11/3.X branch from now on.  
> >  
> > All new features that haven’t be committed yet should go to trunk only  
> > (4.0), if the vote passes.  
> >  
> > What do you think?  
> >  
> > Thanks.  
> >  
> > --  
> > AY  
>  
>  
>  
>  
> --  
> Jonathan Ellis  
> co-founder, http://www.datastax.com  
> @spyced  
>  

Re: [VOTE] 3.X branch feature freeze

[Aleksey Yeschenko]

To elaborate further, under the current consensus there would be no 3.12 
release.

Meaning that there are a few features that already made it to 3.X (3.12) that 
would
either:

a) have to be reverted
b) have to be discarded together with the remained of the 3.X branch

If the vote goes through, I suggest we kill off the 3.X branch, and cherry-pick 
the bug fixes
that made it to 3.X back to the 3.11 branch.

3.11 branch will be the only one remaining.

https://github.com/apache/cassandra/blob/cassandra-3.X/CHANGES.txt 

-- 
AY

On 13 January 2017 at 17:21:22, Aleksey Yeschenko (alek...@apache.org) wrote:

Hi all!

It seems like we have a general consensus on ending tick-tock at 3.11, and 
moving
on to stabilisation-only for 3.11.x series.

In light of this, I suggest immediate feature freeze in the 3.X branch.

Meaning that only bug fixes go to the 3.11/3.X branch from now on.

All new features that haven’t be committed yet should go to trunk only (4.0), 
if the vote passes.

What do you think?

Thanks.

-- 
AY

[VOTE] 3.X branch feature freeze

[Aleksey Yeschenko]

Hi all!

It seems like we have a general consensus on ending tick-tock at 3.11, and 
moving
on to stabilisation-only for 3.11.x series.

In light of this, I suggest immediate feature freeze in the 3.X branch.

Meaning that only bug fixes go to the 3.11/3.X branch from now on.

All new features that haven’t be committed yet should go to trunk only (4.0), 
if the vote passes.

What do you think?

Thanks.

-- 
AY

Re: Per blockng release on dtest

[Aleksey Yeschenko]

That’s a good point.

So 3.11 after 3.10, then move on to 3.11.x further bug fix releases?

+1 to that.

-- 
AY

On 10 January 2017 at 17:22:09, Michael Shuler (mich...@pbandjelly.org) wrote:

I had the same thought. 3.10 is the tick, so a 3.11 bugfix tock follows  
the intended final fix release for closing out tick-tock. Throwing a  
3.10.1 out there would add more user confusion and would be the exact  
same contents as a 3.11 release versioned package set anyway.  

--  
Michael  

On 01/10/2017 11:18 AM, Josh McKenzie wrote:  
> | If someone tries to upgrade 3.10 to whatever 4.0 ends up being I  
> think they will hit the wrong answer bug. So I would advocate for  
> having the fix brought  
> into 3.10, but it was broken in 3.9 as well.  
>  
> Seems like we'd just release that as 3.10.1 (instead of 3.11) and just  
> tell people "you can upgrade to 4.0 w/latest version of 3.10". This  
> does violate the "even releases features, odd releases bugfix", so  
> maybe a 3.11 as final 3.X line would help keep that consistent?  
>  
> I'd rather not open the can of worms of back-porting this to 3.9 as  
> well to hold to our claim of "any 3.X can go to 4.0".  
>  
> On Tue, Jan 10, 2017 at 12:13 PM, Ariel Weisberg  wrote:  
>> Hi,  
>>  
>>  
>>  
>> The upgrade tests are tricky because they upgrade from an existing  
>> release to a current release. The bug is in 3.9 and won't be fixed until  
>> 3.11 because the test checks out and builds 3.9 right now. 3.10 doesn't  
>> include the commit that fixes the issue so it will fail after 3.10 is  
>> released and the test is updated to check out 3.10.  
>>  
>>  
>> We claim to support upgrade from any 3.x version to 4.0. If someone  
>> tries to upgrade 3.10 to whatever 4.0 ends up being I think they will  
>> hit the wrong answer bug. So I would advocate for having the fix brought  
>> into 3.10, but it was broken in 3.9 as well.  
>>  
>>  
>> Some of the tests fail because trunk complains of unreadable stables and  
>> I suspect that isn't a bug it's just something that is no longer  
>> supported due to thrift removal, but I haven't fixed those yet. Those  
>> are probably issues with trunk or the tests.  
>>  
>>  
>> Others fail for reasons I haven't triaged yet. I'm struggling with my  
>> own issues getting the tests to run locally.  
>>  
>>  
>> Ariel  
>>  
>>  
>>  
>> On Tue, Jan 10, 2017, at 11:49 AM, Nate McCall wrote:  
>>  
  
>>  
 I concede it would be fine to do it gradually. Once the pace of  
 issues  
 introduced by new development is beaten by the pace at which  
 they are  
 addressed I think things will go well.  
>>  
>>>  
>>  
>>> So from Michael's JIRA query:  
>>  
>>> https://issues.apache.org/jira/browse/CASSANDRA-12617?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.10%20AND%20resolution%20%3D%20Unresolved
>>>   
>>>  
>>  
>>> Are we good for 3.10 after we get those cleaned up?  
>>  
>>>  
>>  
>>> Ariel, you made reference to:  
>>  
>>> https://github.com/apache/cassandra/commit/c612cd8d7dbd24888c216ad53f974686b88dd601
>>>   
>>>  
>>  
>>> Do we need to re-open an issue to have this applied to 3.10 and add it  
>>> to the above list?  
>>  
>>>  
>>  
  
>>  
 On Tue, Jan 10, 2017, at 11:17 AM, Josh McKenzie wrote:  
>>  
>  
>>  
> Sankalp's proposal of us progressively tightening up our standards  
> allows  
> us to get code out the door and regain some lost momentum on  
> the 3.10  
> release failures and blocking, and gives us time as a community to  
> adjust  
> our behavior without the burden of an ever-later slipped release  
> hanging  
> over our heads. There's plenty of bugfixes in the 3.X line; the  
> more time  
> people can have to kick the tires on that code, the more things  
> we can  
> find  
>>  
> and the better future releases will be.  
>>  
>>>  
>>  
>>>  
>>  
>>> +1 On gradually moving to this. Dropping releases with huge change  
>>  
>>> lists has never gone well for us in the past.  
>>  
>>  

Re: Per blockng release on dtest

[Aleksey Yeschenko]

I would personally favour pushing 3.10 out without waiting for the pretty 
innocent
#13113 resolution.

With the amount of bug fixes accumulated in the 3.X branch it’s borderline
irresponsible to not release them out to the users.

-- 
AY

On 10 January 2017 at 17:05:57, Michael Shuler (mich...@pbandjelly.org) wrote:

Generally, fixver has only been set during commits - I only marked 3.10  
and blocker status to highlight the few that failed votes, in order to  
sort of cheerlead "fix me so we can release!" JIRA tickets. The full  
test-failure list is probably the more "realistic" view, since any of  
those may occur. As I also just replied, an auth_test method is the  
current failure on c-3.11 branch. Mark it as a blocker? Re-run the job  
and hope for green? Unmark the current 3.10 fixver blockers, since they  
didn't fail? (Likely to get some other failure or maybe a full pass)  

--  
Michael  

On 01/10/2017 10:56 AM, Josh McKenzie wrote:  
> I assume you meant the query w/out 12617 embedded?  
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.10%20AND%20resolution%20%3D%20Unresolved
>   
>  
> Do we have confidence that all test failures have fixVersion attached  
> correctly? The list of test failures w/out fixVersion is pretty daunting:  
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20labels%20in%20(test%2C%20test-failure%2C%20dtest%2C%20unittest)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixversion%20%3D%20null%20and%20labels%20!%3D%20windows%20ORDER%20BY%20created%20asc
>   
>  
> On Tue, Jan 10, 2017 at 11:49 AM, Nate McCall  wrote:  
>  
>>>  
>>> I concede it would be fine to do it gradually. Once the pace of issues  
>>> introduced by new development is beaten by the pace at which they are  
>>> addressed I think things will go well.  
>>  
>> So from Michael's JIRA query:  
>> https://issues.apache.org/jira/browse/CASSANDRA-12617?  
>> jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.  
>> 10%20AND%20resolution%20%3D%20Unresolved  
>>  
>> Are we good for 3.10 after we get those cleaned up?  
>>  
>> Ariel, you made reference to:  
>> https://github.com/apache/cassandra/commit/c612cd8d7dbd24888c216ad53f9746  
>> 86b88dd601  
>>  
>> Do we need to re-open an issue to have this applied to 3.10 and add it  
>> to the above list?  
>>  
>>>  
>>> On Tue, Jan 10, 2017, at 11:17 AM, Josh McKenzie wrote:  
  
 Sankalp's proposal of us progressively tightening up our standards  
>> allows  
 us to get code out the door and regain some lost momentum on the 3.10  
 release failures and blocking, and gives us time as a community to  
>> adjust  
 our behavior without the burden of an ever-later slipped release hanging  
 over our heads. There's plenty of bugfixes in the 3.X line; the more  
>> time  
 people can have to kick the tires on that code, the more things we can  
 find  
 and the better future releases will be.  
>>  
>>  
>> +1 On gradually moving to this. Dropping releases with huge change  
>> lists has never gone well for us in the past.  
>>  
>  

Re: Wrapping up tick-tock

[Aleksey Yeschenko]

I’m thinking put it on the same rails as 2.2.x and 3.0.x. As needed.

-- 
AY

On 10 January 2017 at 16:46:25, Josh McKenzie (jmcken...@apache.org) wrote:

>  
> I would also propose we move on to 3.10.x bugfix only releases from now  
> on, with all new feature development moving to trunk from now on.  

You thinking monthly release on that or "as needed"? In theory, monthly  
should be easier than previous tick-tock if we're only putting in bugfix or  
testfix on the branch.  

On Tue, Jan 10, 2017 at 11:41 AM, Aleksey Yeschenko   
wrote:  

> 6 months seems reasonable to me as well.  
>  
> There seems to be an agreement to halting 3.X on 3.10. I would also propose  
> we move on to 3.10.x bugfix only releases from now on, with all new feature  
> development moving to trunk from now on.  
>  
> This should allow us to finally stabilise 3.X so that we can get all test  
> jobs to green.  
>  
> --  
> AY  
>  
> On 10 January 2017 at 16:36:43, Josh McKenzie (jmcken...@apache.org)  
> wrote:  
>  
> +1 to 6 months.  
>  
> On Tue, Jan 10, 2017 at 11:32 AM, Jonathan Ellis   
> wrote:  
>  
> > I agree that 6 month seems like a reasonable compromise.  
> >  
> > On Tue, Jan 10, 2017 at 10:31 AM, Blake Eggleston   
> > wrote:  
> >  
> > > I agree that 3.10 should be the last tick-tock release, but I also  
> agree  
> > > with Jon that we shouldn't go back to yearly-ish releases.  
> > >  
> > > 6 months has come up several times now as a good cadence for feature  
> > > releases, and I think it's a good compromise between the competing  
> > > interests of long term support, regular release of features (to prevent  
> > > piling on), and effort to release. So +1 to 6 month releases.  
> > >  
> > > On January 10, 2017 at 10:14:12 AM, Ariel Weisberg (ar...@weisberg.ws)  
> > > wrote:  
> > >  
> > > Hi,  
> > >  
> > > With yearly releases trunk is going to be a mess when it comes time to  
> > > cut a release. Cutting releases is when people start caring whether all  
> > > the things in the release are in a finished state. It's when the state  
> > > of CI finally becomes relevant.  
> > >  
> > > If we wait a year we are going to accumulate a years worth of  
> unfinished  
> > > stuff in a single release. It's more expensive to context switch back  
> > > and then address those issues. If we put out large unstable releases it  
> > > means time until the features in the release are usable is pushed back  
> > > even further since it takes another 6-12 months for the release to  
> > > stabilize. Features introduced at the beginning of the cycle will have  
> > > to wait 18-24 months before anyone can benefit from them.  
> > >  
> > > Is the biggest pain point with tick-tock just the elimination of long  
> > > term support releases? What is the pain point around release frequency?  
> > > Right now people should be using 3.0 unless they need a bleeding edge  
> > > feature from 3.X and those people will have to give up something to get  
> > > something.  
> > >  
> > > Ariel  
> > >  
> > > On Tue, Jan 10, 2017, at 10:29 AM, Jonathan Haddad wrote:  
> > > > I don't see why it has to be one extreme (yearly) or another  
> (monthly).  
> > > > When you had originally proposed Tick Tock, you wrote:  
> > > >  
> > > > "The primary goal is to improve release quality. Our current major  
> “dot  
> > > > zero” releases require another five or six months to make them stable  
> > > > enough for production. This is directly related to how we pile  
> features  
> > > > in  
> > > > for 9 to 12 months and release all at once. The interactions between  
> > the  
> > > > new features are complex and not always obvious. 2.1 was no  
> exception,  
> > > > despite DataStax hiring a full tme test engineering team specifically  
> > for  
> > > > Apache Cassandra."  
> > > >  
> > > > I agreed with you at the time that the yearly cycle was too long to  
> be  
> > > > adding features before cutting a release, and still do now. Instead  
> of  
> > > > elastic banding all the way back to a process which wasn't working  
> > > > before,  
> > > > why not try somewhere in the middle? A release every 6 months (with  
> > > > monthly bug fixes for a year) gives:  
> > > >  
> > > > 1. lo

Re: Wrapping up tick-tock

[Aleksey Yeschenko]

6 months seems reasonable to me as well.

There seems to be an agreement to halting 3.X on 3.10. I would also propose
we move on to 3.10.x bugfix only releases from now on, with all new feature
development moving to trunk from now on.

This should allow us to finally stabilise 3.X so that we can get all test jobs 
to green.

-- 
AY

On 10 January 2017 at 16:36:43, Josh McKenzie (jmcken...@apache.org) wrote:

+1 to 6 months.  

On Tue, Jan 10, 2017 at 11:32 AM, Jonathan Ellis  wrote:  

> I agree that 6 month seems like a reasonable compromise.  
>  
> On Tue, Jan 10, 2017 at 10:31 AM, Blake Eggleston   
> wrote:  
>  
> > I agree that 3.10 should be the last tick-tock release, but I also agree  
> > with Jon that we shouldn't go back to yearly-ish releases.  
> >  
> > 6 months has come up several times now as a good cadence for feature  
> > releases, and I think it's a good compromise between the competing  
> > interests of long term support, regular release of features (to prevent  
> > piling on), and effort to release. So +1 to 6 month releases.  
> >  
> > On January 10, 2017 at 10:14:12 AM, Ariel Weisberg (ar...@weisberg.ws)  
> > wrote:  
> >  
> > Hi,  
> >  
> > With yearly releases trunk is going to be a mess when it comes time to  
> > cut a release. Cutting releases is when people start caring whether all  
> > the things in the release are in a finished state. It's when the state  
> > of CI finally becomes relevant.  
> >  
> > If we wait a year we are going to accumulate a years worth of unfinished  
> > stuff in a single release. It's more expensive to context switch back  
> > and then address those issues. If we put out large unstable releases it  
> > means time until the features in the release are usable is pushed back  
> > even further since it takes another 6-12 months for the release to  
> > stabilize. Features introduced at the beginning of the cycle will have  
> > to wait 18-24 months before anyone can benefit from them.  
> >  
> > Is the biggest pain point with tick-tock just the elimination of long  
> > term support releases? What is the pain point around release frequency?  
> > Right now people should be using 3.0 unless they need a bleeding edge  
> > feature from 3.X and those people will have to give up something to get  
> > something.  
> >  
> > Ariel  
> >  
> > On Tue, Jan 10, 2017, at 10:29 AM, Jonathan Haddad wrote:  
> > > I don't see why it has to be one extreme (yearly) or another (monthly).  
> > > When you had originally proposed Tick Tock, you wrote:  
> > >  
> > > "The primary goal is to improve release quality. Our current major “dot  
> > > zero” releases require another five or six months to make them stable  
> > > enough for production. This is directly related to how we pile features  
> > > in  
> > > for 9 to 12 months and release all at once. The interactions between  
> the  
> > > new features are complex and not always obvious. 2.1 was no exception,  
> > > despite DataStax hiring a full tme test engineering team specifically  
> for  
> > > Apache Cassandra."  
> > >  
> > > I agreed with you at the time that the yearly cycle was too long to be  
> > > adding features before cutting a release, and still do now. Instead of  
> > > elastic banding all the way back to a process which wasn't working  
> > > before,  
> > > why not try somewhere in the middle? A release every 6 months (with  
> > > monthly bug fixes for a year) gives:  
> > >  
> > > 1. long enough time to stabilize (1 year vs 1 month)  
> > > 2. not so long things sit around untested forever  
> > > 3. only 2 releases (current and previous) to do bug fix support at any  
> > > given time.  
> > >  
> > > Jon  
> > >  
> > > On Tue, Jan 10, 2017 at 6:56 AM Jonathan Ellis   
> > wrote:  
> > >  
> > > > Hi all,  
> > > >  
> > > > We’ve had a few threads now about the successes and failures of the  
> > > > tick-tock release process and what to do to replace it, but they all  
> > died  
> > > > out without reaching a robust consensus.  
> > > >  
> > > > In those threads we saw several reasonable options proposed, but from  
> > my  
> > > > perspective they all operated in a kind of theoretical fantasy land  
> of  
> > > > testing and development resources. In particular, it takes around a  
> > > > person-week of effort to verify that a release is ready. That is,  
> going  
> > > > through all the test suites, inspecting and re-running failing tests  
> > to see  
> > > > if there is a product problem or a flaky test.  
> > > >  
> > > > (I agree that in a perfect world this wouldn’t be necessary because  
> > your  
> > > > test ci is always green, but see my previous framing of the perfect  
> > world  
> > > > as a fantasy land. It’s also worth noting that this is a common  
> problem  
> > > > for large OSS projects, not necessarily something to beat ourselves  
> up  
> > > > over, but in any case, that's our reality right now.)  
> > > >  
> > > > I submit that any pr

Re: Per blockng release on dtest

[Aleksey Yeschenko]

If they aren’t regressions from 3.9, we should still push 3.10 out.

The branch has accumulated a lot of fixes, for problems that *are* real.
Just have a look at CHANGES.txt.

By holding 3.10 you are denying those (arguably few, but still) users fixes for 
bugs that we
know are in.

It’s been more than 3 months now, delaying it further is unreasonable. The 
branch needs to be uncorked.

I would also prefer that people who -1, in particular bindingly, were prepared 
to go and fix the offending tests,
if they are blocking the vote on the ground of tests. Can’t expect test 
failures to magically go away all
by themselves.

-- 
AY

On 10 January 2017 at 15:33:45, Ariel Weisberg (ar...@weisberg.ws) wrote:

Hi,  

At least some of those failures are real. I don't think we should  
release 3.10 until the real failures are addressed. As I said earlier  
one of them is a wrong answer bug that is not going to be fixed in 3.10.  

Can we just ignore failures because we think they don't mean anything?  
Who is going to check which of the 60 failures is real?  

These tests were passing just fine at the beginning of December and then  
commits happened and now the tests are failing. That is exactly what  
their for. They are good tests. I don't think it matters if the failures  
are "real" today because those are valid tests and they don't test  
anything if they fail for spurious reasons. They are a critical part of  
the Cassandra infrastructure as much as the storage engine or network  
code.  

In my opinion the tests need to be fixed and people need to fix them as  
they break them and we need to figure out how to get from people  
breaking them and it going unnoticed to they break it and then fix it in  
a time frame that fits the release schedule.  

My personal opinion is that releases are a reward for finishing the job.  
Releasing without finishing the job creates the wrong incentive  
structure for the community. If you break something you are no longer  
the person that blocked the release you are just one of several people  
breaking things without consequence.  

I think that rapid feedback and triaging combined with releases blocked  
by the stuff individual contributors have broken is the way to more  
consistent releases both schedule wise and quality wise.  

Regarding delaying 3.10? Who exactly is the consumer that is chomping at  
the bit to get another release? One that doesn't reliably upgrade from a  
previous version?  

Ariel  

On Tue, Jan 10, 2017, at 08:13 AM, Josh McKenzie wrote:  
> First, I think we need to clarify if we're blocking on just testall +  
> dtest  
> or blocking on *all test jobs*.  
>  
> If the latter, upgrade tests are the elephant in the room:  
> http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest_upgrade/lastCompletedBuild/testReport/
>   
>  
> Do we have confidence that the reported failures are all test problems  
> and  
> not w/Cassandra itself? If so, is that documented somewhere?  
>  
> On Mon, Jan 9, 2017 at 7:33 PM, Nate McCall  wrote:  
>  
> > I'm not sure I understand the culmination of the past couple of threads on  
> > this.  
> >  
> > With a situation like:  
> > http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest/  
> > lastCompletedBuild/testReport/  
> >  
> > We have some sense of stability on what might be flaky tests(?).  
> > Again, I'm not sure what our criteria is specifically.  
> >  
> > Basically, it feels like we are in a stalemate right now. How do we  
> > move forward?  
> >  
> > -Nate  
> >  

Re: Configurable password policy in Cassandra...

[Aleksey Yeschenko]

You can write a patch for one, or create a custom authenticator implementation 
that would enforce this.

They are pluggable after all, just like authorizer is.

-- 
AY

On 23 December 2016 at 20:06:19, Prakash Chauhan (prakash.chau...@ericsson.com) 
wrote:

Hello All,  

In Apache Cassandra , there are no strict password policies for creating a new 
user.  

A new user can be created with a password as simple as "abc" which is not at 
all recommended for production use.  
Moreover the same password can be used again and again.  

There should be a configurable password policy in Cassandra for creating new 
users.  

Any thoughts on this   



Regards,  
Prakash Chauhan.  

Re: Where do I find EverywhereStrategy?

[Aleksey Yeschenko]

It isn’t, but you are supposed to change it.

The reason it cannot be set higher by default is that out of the box 
single-node clusters should still work,
and setting the default RF to higher than 1 would break this, as it performs 
some queries at quorum CL.

-- 
AY

On 3 December 2016 at 06:47:12, sankalp kohli (kohlisank...@gmail.com) wrote:

The point Ben is saying is that for auth keyspace, default o​f RF=1 is not  
good for any type of cluster whether it is small or large.  

Re: Rough roadmap for 4.0

[Aleksey Yeschenko]

I’ll comment on the broader issue, but right now I want to elaborate on 
3.11/January/arbitrary cutoff date.

Doesn’t matter what the original plan was. We should continue with 3.X until 
all the 4.0 blockers have been
committed - and there are quite a few of them remaining yet.

So given all the holidays, and the tickets remaining, I’ll personally be 
surprised if 4.0 comes out before
February/March and 3.13/3.14. Nor do I think it’s an issue. 

—
AY

On 16 November 2016 at 00:39:03, Mick Semb Wever (m...@thelastpickle.com) wrote:

On 4 November 2016 at 13:47, Nate McCall  wrote:  

> Specifically, this should be "new stuff that could/will break things"  
> given we are upping  
> the major version.  
>  


How does this co-ordinate with the tick-tock versioning¹ leading up to the  
4.0 release?  

To just stop tick-tock and then say yeehaa let's jam in all the breaking  
changes we really want seems to be throwing away some of the learnt wisdom,  
and not doing a very sane transition from tick-tock to  
features/testing/stable². I really hope all this is done in a way that  
continues us down the path towards a stable-master.  

For example, are we fixing the release of 4.0 to November? or continuing  
tick-tocks until we complete the 4.0 roadmap? or starting the  
features/testing/stable branching approach with 3.11?  


Background:  
¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"  

> And as 4.0 was initially supposed to come after 3.11, which is coming,  
it's probably time to have a home for those tickets.  

²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1"  
thread  

> three branch plan with “features”, “testing”, and “stable” starting with  
4.0?  


Mick  

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

[Aleksey Yeschenko]

-1 for the reasons listed.

—
AY

On 11 November 2016 at 16:59:04, Michael Shuler (mich...@pbandjelly.org) wrote:

For the record, I'm changing my vote to a -1, as well.  

--  
Michael  

On 11/11/2016 09:40 AM, Michael Shuler wrote:  
> I think cassandra-3.0 HEAD is good with me, too. We can adjust the  
> fixver for those that may say 3.0.11 currently.  
>  

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

Agreed.

-- 
AY

On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com) wrote:

‘Accepted’ JIRA status seems useful, but would encourage something more 
explicit like ‘Concept Accepted’ or similar to denote that the concept is 
agreed upon, but the actual patch itself may not be accepted yet.  

/bikeshed.  

On 11/7/16, 2:56 AM, "Ben Slater"  wrote:  

>Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a  
>better name).  
>  
>One other thing I noted from the Mesos process - they have an “Accepted”  
>jira status that comes after open and means “at least one Mesos developer  
>thought that the ideas proposed in the issue are worth pursuing further”.  
>Might also be something to consider as part of a process like this?  
>  
>Cheers  
>Ben  
>  
>On Mon, 7 Nov 2016 at 09:37 Dave Lester  wrote:  
>  
>> Hi Ben,  
>>  
>> A few ideas to add to your suggestions [inline]:  
>>  
>> On 2016-11-06 13:51 (-0800), Ben Slater 
>> >  >  
>> wrote:  
>> > Hi All,  
>> >  
>> > I thought I would add a couple of observations and suggestions as someone  
>> > who has both personally made my first contributions to the project in the  
>> > last few months and someone in a leadership role in an organisation  
>> > (Instaclustr) that is feeling it’s way through increasing our  
>> contributions  
>> > as an organisation.  
>> >  
>> > Firstly - an observation on contribution experience and what I think is  
>> > likely to make people want to contribute again:  
>> > 1) The worst thing that can happen is for your contribution to be  
>> > completely ignored.  
>> > 2) The second worst thing is for it to be rejected without a good  
>> > explanation (that you can learn from) or with hostility.  
>> > 3) Having it rejected with a good reason is not a bad thing (you learn)  
>> > 4) Having it accepted is, of course, the best!  
>> >  
>> > With this as a background I would suggest a couple of thing that help  
>> make  
>> > sure (3) and (4) are always more common that (1) and (2) (good outcomes  
>> are  
>> > probably more common than bad at the moment but we’ve experienced all  
>> four  
>> > scenarios in the last few months):  
>> > 1) I think some process of assigning a committer of a “sponsor” of a  
>> change  
>> > (which would probably mean committers volunteering) before it commences  
>> > would be useful. You can kind of do this at the moment by creating a JIRA  
>> > and asking for comment but I think the process is a bit unclear and a bit  
>> > intimidating for people starting off and it would be nice to know who was  
>> > your primary reviewer for a piece of work. (Or maybe this process does  
>> > exist and I don’t know about.)  
>>  
>> I've seen this approach before and it that can reduce ambiguity on the  
>> state of contributions; the Apache Mesos project has a shepherding system  
>> similar to this. I would shy away from the term "sponsor" since it could  
>> infer a non-voluntary relationship between contributors and volunteer  
>> committers.  
>>  
>> From the Mesos docs: "Find a shepherd to collaborate on your patch. A  
>> shepherd is a Mesos committer that will work with you to give you feedback  
>> on your proposed design, and to eventually commit your change into the  
>> Mesos source tree." More info on how they approach this is in both their  
>> newbie guide: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_newbie-2Dguide_&d=DgIFaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=MB2cGSGm5RHMnWWRGLZ4h8P7Mo0Rvm6k5mW2yhQVZ7U&e=
>>  , and  
>> submitting a patch guide:  
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_latest_submitting-2Da-2Dpatch_&d=DgIFaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=PSj3seUwzL_USxWvdvqlMKrU_yfBXpOSQ4XfjdhnmO0&e=
>>  .  
>>  
>> In practice, there are some limitations and risks to this model. For one,  
>> a shepherding process is not a substitute for the Apache Way, and it's  
>> critical that design decisions and reviews are still done in the open.  
>> Additionally, in projects where a single organization has disproportionate  
>> representation at the committer level it can create bottlenecks if features  
>> are a lower priority for those orgs (while not malicious, it may mean that  
>> certain patches are shepherded while others are ignored). It's possible to  
>> work within these limitations, especially in cases where the community is  
>> having healthy conversations about the di

Re: DataStax role in Cassandra and the ASF

[Aleksey Yeschenko]

I’d say they are interwoven with inappropriate passages that should have never 
been typed,
and *all of them* came from ASF board members.

I feel like it would be in the interest of Apache Cassandra, and the greater 
Apache community,
to expose the way the board treats its volunteer PMC and committers - with no 
class, gratitude,
or any resemblance of professionalism one would normally expect from persons in 
such a role.

I’m one of the participants of those threads, and I have no objections to them 
being published as is.
Maybe doing so would make certain people think about what they type before they 
hit ‘Send’,
and show some respect to Apache volunteers in the future?

-- 
AY

On 5 November 2016 at 18:47:44, Marvin Humphrey (mar...@rectangular.com) wrote:

The recent conversations which took place on private lists regarding the 
Cassandra community are interwoven with passages which ought to stay private. 

Re: DataStax role in Cassandra and the ASF

[Aleksey Yeschenko]

I have a feeling that you didn’t even bother to check out the mailing list 
threads that Łukasz linked to.

I encourage you, and others, to first do so, instead of blindly assuming that 
their content is inappropriate.

-- 
AY

On 5 November 2016 at 00:14:42, Chris Mattmann (mattm...@apache.org) wrote:

Thank you for sending this. I am not going to reply in depth now, but will do 
so to Kelly and  
others over the weekend, but this is *precisely* the reason that I have been so 
emphatic  
about trying to get the PMC to see the road they have already gone done and the 
ship that  
has already set sail.  

Those not familiar with Lucene and its vote to merge Lucene/Solr may want to 
Google the  
Apache archives around 2010 and see some of the effects of Individual 
organizations and  
vendors driving supposedly vendor neutral Apache projects. It’s not even 
conjecture at this  
point in Cassandra. The Board has acted as Greg referred to else-thread, and we 
asked Jonathan & the  
PMC to find a new chair (rotation is healthy yes, but we also need the chair to 
be the eyes  
and ears of the Board and we asked for a change there). Mark Thomas from the 
Apache Board  
also has a set of actions that he is working with the PMC having to do with 
trademarks and  
other items to move towards more independent governance.  

Your experience that you cite below Lukasz is precisely one I found in 
Lucene/Solr, Hadoop,  
Maven, and other projects. Sometimes the ship has been righted – for example in 
all of these  
projects they have moved towards much more independent governance, welcoming to 
contributors,  
and shared community for the project. However, in other cases (see IBATIS), it 
didn’t work out, for  
various reasons including community issues, but also misunderstandings as to 
the way that the  
ASF works. I know my own experience of being an unpaid, occasional contributor 
to some open  
source projects has put me to a disadvantage even in some ASF projects driven 
by a single vendor.  
I’ve also been paid to work on open source (at the ASF and elsewhere) and in 
doing so, been on the  
other side of the code. That’s why ASF projects and my own work in particular I 
strive to try and  
remain neutral and to address these types of issues by being welcoming, lower 
the bar to committership  
and PMC, and moving “contributors” to having a vote/shared governance of the 
project at the ASF.  

Thanks for sending this email and your insights are welcome below. The Apache 
Board should hear this  
too so I am CC’ing them.  

Cheers,  
Chris  





On 11/4/16, 5:03 PM, "Łukasz Dywicki"  wrote:  

Good evening,  
I feel myself a bit called to table by both Kelly and Chris. Thing is I don’t 
know personally nor have any relationship with both of you. I’m not even ASF 
member. My tweet was simply reaction for Kelly complaints about ASF punishing 
out DataStax. Kelly timeline also contained statement such "forming a long term 
strategy to grow diversity around” which reminded me my attempts to collaborate 
on Cassandra and Tinkerpop projects to grow such diversity. I collected message 
links and quotes and put it into gist who could be read by anyone:  
https://gist.github.com/splatch/aebe4ad4d127922642bee0dc9a8b1ec1  

I don’t want to bring now these topics back and disscuss technical stuff over 
again. It happened to me in the past to refuse (or vote against) some change 
proposals in other Apache projects I am involved. I was on the other ("bad 
guy") side multiple times. I simply collected public records of interactions 
with DataStax staff I was aware, simply because of my personal involvement. It 
shown how some ideas, yet cassandra mailing list don’t have many of these 
coming from externals, are getting put a side with very little or even lack of 
will to pull in others people work in. This is blocking point for anyone coming 
from external sides to get involved into project and help it growing. If 
someone changes requires moves in project core or it’s public APIs that person 
will require support from project members to get this done. If such help will 
not be given it any outside change will be ever completed and noone will invest 
time in doing something more than fixing typos or common programmer errors 
which we all do from time to time. Despite of impersonal nature of 
communications in Internet we still do have human interactions and we all have 
just one chance to make first impression. If we made it wrong at beginning its 
hard to fix it later on.  
Some decisions made in past by project PMCs lead to situation that project was 
forked and maintained outside ASF (ie. stratio cassandra which eventually ended 
up as lucene indexes plugin over a year ago), some other did hurt users running 
cassandra for long time (ie. discontinuation of thrift). Especially second 
decission was seen by outsiders, who do not desire billion writes per second, 
as marketing driven. This led to people looking and finding alter

Re: DataStax role in Cassandra and the ASF

[Aleksey Yeschenko]

You got this one completely wrong, my friend.

It’s the PMC who reached out to stratio and helped them get the changes they 
required into Cassandra,
so that they could abandon the fork.

I know because I was that PMC member.

cc Andres from Stratio

-- 
AY

On 5 November 2016 at 00:14:42, Chris Mattmann (mattm...@apache.org) wrote:

Some decisions made in past by project PMCs lead to situation that project was 
forked and maintained outside ASF (ie. stratio cassandra which eventually ended 
up as lucene indexes plugin over a year ago)

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

Dunno. A sneaky correctness or data corruption bug. A performance regression. 
Or something that can take a node/cluster down.

Of course no process is bullet-proof. The purpose of review is to minimise the 
odds of such a thing happening.

I’m sure users running Cassandra in production would prefer actual proper 
reviews to non-review +1s.

-- 
AY

On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com) wrote:

I feel that is really standing up on a soap box. What would be the worst 
thing that happens here

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

I’m sure that impactful, important, and/or potentially destabilising patches 
will continue getting reviewed
by those engineers.

As for patches that no organisation with a strong enough commercial interest 
cares about, they probably won’t.
Engineering time is quite expensive, most employers are understaffed as it is, 
overloaded with deadlines and
fires, so it’s hard to justify donating man hours to work that brings no value 
to your employer - be it Instagram,
Apple, or DataStax.

I don’t want to sound negative here, but I’d rather not fake optimism here, 
either. Expect that kind of patches
to stay in unreviewed limbo for the most part.

But significant work will still get reviewed and committed, keeping the project 
overall healthy. I wouldn’t worry much.

-- 
AY

On 4 November 2016 at 22:13:42, Aleksey Yeschenko (alek...@apache.org) wrote:

This has always been a concern. We’ve always had a backlog on unreviewed 
patches.

Reviews (real reviews, not rubber-stamping a +1 formally) are real work, often 
taking as much work
as creating the patch in question. And taking as much expertise (or more).

It’s also not ‘fun’ and doesn’t lend itself to scratch-your-own-itch drive-by 
style contributions.

In other words, not something people tend to volunteer for. Something done 
mostly by people
paid to do the work, reviews assigned to them by their managers.

There is also the issue of specialisation. Very few people can be trusted with 
review of arbitrary
Cassandra patches. I can count them all on fingers of one hand. There are 
islands of expertise
and people who can review certain subsystems, and most of them are employed by 
a certain one
company. A few people at Apple, but with no real post-8099, 3.0 code experience 
at the moment.

What I’m saying is that it’s insufficient to just have desire to volunteer - 
you also need the actual
knowledge and skill to properly review non-trivial work, and for that we 
largely only have DataStax
employed contributors, with a sprinkle of people at Apple, and that’s sadly 
about it.

We tried to improve it by holding multiple bootcamps, at Summits, and privately 
within major companies,
at non-trivial expense to the company, but those initiatives mostly failed so 
far :(

This has always been a problem (lack of review bandwidth), and always will be. 
That said, I don’t expect it to get
much worse than it is now.

-- 
AY

On 4 November 2016 at 21:50:20, Nate McCall (zznat...@gmail.com) wrote:

To be clear, getting the community more involved is a super hard,
critically important problem to which I don't have a concrete answer
other than I'm going to keep reaching out for opinions, ideas and
involvement.

Just like this.

Please speak up here if you have ideas on how this could work.

On Sat, Nov 5, 2016 at 10:38 AM, Nate McCall  wrote:
> [Moved to a new thread because this topic is important by itself]
>
> There are some excellent points here - thanks for bringing this up.
>
>> What can inspiring developers contribute to 4.0
>> that would move the project forward to it’s goals and would be very likely
>> included in the final release?
>
> That is a hard question with regards to the tickets I listed. My goal
> was to list the large, potentially breaking changes which would
> necessitate a move from '3' to '4' major release. Unfortunately in
> this context, those types of issues have a huge surface area that
> requires experience with the code to review in a meaningful way.
>
> We are kind of in this trap now with the Gossip 2.0 tickets. There are
> very few people who feel comfortable enough to give Jason feedback on
> the patches because he has effectively replaced (necessarily, IMO)
> seven years of edge case fixes baked into the current implementation.
> And that stuff is just hard in the first place.
>
> I'm not completely sure what the answer is here. I will tell you that
> from my own experience, an excellent way to get familiar with the code
> and concepts would be to look at some of these large tickets in
> detail, go through what changed and ask some questions about the
> choices made.
>
> Community is based on participation, conversation and exchange of
> knowledge. The more involvement we have in day to day exchanges, the
> more we all learn and the healthier things will become.
>
>> What should people work on that would not be
>> left ignored, because there’s no need for it or no time to really take care
>> of it?
>
> We have a huge pile of backlogged tickets in "unresolved" and "patch
> available." Going through these and testing, reviewing, submitting
> patches, even pinging on status, rebasing if needed would be awesome.
> Frankly, we need the help.
>
> Another thought - "I would like to add X, how should I go about doing
> this?" is an excellent con

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

This has always been a concern. We’ve always had a backlog on unreviewed 
patches.

Reviews (real reviews, not rubber-stamping a +1 formally) are real work, often 
taking as much work
as creating the patch in question. And taking as much expertise (or more).

It’s also not ‘fun’ and doesn’t lend itself to scratch-your-own-itch drive-by 
style contributions.

In other words, not something people tend to volunteer for. Something done 
mostly by people
paid to do the work, reviews assigned to them by their managers.

There is also the issue of specialisation. Very few people can be trusted with 
review of arbitrary
Cassandra patches. I can count them all on fingers of one hand. There are 
islands of expertise
and people who can review certain subsystems, and most of them are employed by 
a certain one
company. A few people at Apple, but with no real post-8099, 3.0 code experience 
at the moment.

What I’m saying is that it’s insufficient to just have desire to volunteer - 
you also need the actual
knowledge and skill to properly review non-trivial work, and for that we 
largely only have DataStax
employed contributors, with a sprinkle of people at Apple, and that’s sadly 
about it.

We tried to improve it by holding multiple bootcamps, at Summits, and privately 
within major companies,
at non-trivial expense to the company, but those initiatives mostly failed so 
far :(

This has always been a problem (lack of review bandwidth), and always will be. 
That said, I don’t expect it to get
much worse than it is now.

-- 
AY

On 4 November 2016 at 21:50:20, Nate McCall (zznat...@gmail.com) wrote:

To be clear, getting the community more involved is a super hard,  
critically important problem to which I don't have a concrete answer  
other than I'm going to keep reaching out for opinions, ideas and  
involvement.  

Just like this.  

Please speak up here if you have ideas on how this could work.  

On Sat, Nov 5, 2016 at 10:38 AM, Nate McCall  wrote:  
> [Moved to a new thread because this topic is important by itself]  
>  
> There are some excellent points here - thanks for bringing this up.  
>  
>> What can inspiring developers contribute to 4.0  
>> that would move the project forward to it’s goals and would be very likely  
>> included in the final release?  
>  
> That is a hard question with regards to the tickets I listed. My goal  
> was to list the large, potentially breaking changes which would  
> necessitate a move from '3' to '4' major release. Unfortunately in  
> this context, those types of issues have a huge surface area that  
> requires experience with the code to review in a meaningful way.  
>  
> We are kind of in this trap now with the Gossip 2.0 tickets. There are  
> very few people who feel comfortable enough to give Jason feedback on  
> the patches because he has effectively replaced (necessarily, IMO)  
> seven years of edge case fixes baked into the current implementation.  
> And that stuff is just hard in the first place.  
>  
> I'm not completely sure what the answer is here. I will tell you that  
> from my own experience, an excellent way to get familiar with the code  
> and concepts would be to look at some of these large tickets in  
> detail, go through what changed and ask some questions about the  
> choices made.  
>  
> Community is based on participation, conversation and exchange of  
> knowledge. The more involvement we have in day to day exchanges, the  
> more we all learn and the healthier things will become.  
>  
>> What should people work on that would not be  
>> left ignored, because there’s no need for it or no time to really take care  
>> of it?  
>  
> We have a huge pile of backlogged tickets in "unresolved" and "patch  
> available." Going through these and testing, reviewing, submitting  
> patches, even pinging on status, rebasing if needed would be awesome.  
> Frankly, we need the help.  
>  
> Another thought - "I would like to add X, how should I go about doing  
> this?" is an excellent conversation to start on the mail list:  
> https://lists.apache.org/thread.html/0ecddfb2ecc72e8c5f4027d96b72345d3476edfe0094f89b42a93539@%3Cdev.cassandra.apache.org%3E
>   
>  
>>  
>> Each contribution  
>> deserves some kind of response and even if it’s just a “not relevant for  
>> next release, will look into it another time” type of reply.  
>  
> I completely agree. Per the above, anyone should feel like they can  
> chime in on tickets. It's a community effort.  
>  
> Particularly if you are an operator - your thoughts, experiences and  
> opinions matter (to me at least) like 10x what a developer thinks for  
> anything with operational or end user impact.  
>  
>> Having clear  
>> goals or a certain theme for the release should make it easier to decide  
>> what to review and where to decline. Does that make sense?  
>  
> I think anything *new* with a large surface area not already well  
> underway (and maybe some things that are?) should be tabled 

Re: [VOTE] Release Apache Cassandra 3.10

[Aleksey Yeschenko]

+1

-- 
AY

On 31 October 2016 at 15:19:00, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.10.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/8uMiBt  
[2]: (NEWS.txt) https://goo.gl/prKdlZ  

Re: [VOTE] Release Apache Cassandra 3.0.10

[Aleksey Yeschenko]

+1

-- 
AY

On 31 October 2016 at 16:12:08, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.0.10.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/4e1P3e  
[2]: (NEWS.txt) https://goo.gl/AwLFr1  

Re: Proposal - 3.5.1

[Aleksey Yeschenko]

I’m not sure it makes sense to have separate features/stability releases in 
that world. 4.0.x will be stable, every 4.x will be a dev release on the road 
to 5.0.

-- 
AY

On 20 October 2016 at 22:43:19, Jeff Jirsa (jji...@apache.org) wrote:



On 2016-10-20 14:21 (-0700), Jeremiah Jordan  wrote:  
> In the original tick tock plan we would not have kept 4.0.x around. So I am 
> proposing a change for that and then we label the 3.x and 4.x releases as 
> "development releases" or some other thing and have "yearly" LTS releases 
> with .0.x.  
> Those are similar to the previous 1.2/2.0/2.1/2.2 and we are adding semi 
> stable development releases as well which give people an easier way to try 
> out new stuff than "build it yourself", which was the only way to do that in 
> between the previous Big Bang releases.  
>  

This sounds reasonable to me. Would 4.(even) still be features and 4.(odd) 
still be stability fixes? Or everything in 4.x is features and/or stability?  

Re: [VOTE] Release Apache Cassandra 2.1.16

[Aleksey Yeschenko]

+1

-- 
AY

On 6 October 2016 at 15:32:46, Gary Dusbabek (gdusba...@gmail.com) wrote:

+1  

On Wed, Oct 5, 2016 at 6:09 PM, Michael Shuler   
wrote:  

> I propose the following artifacts for release as 2.1.16.  
>  
> sha1: 87034cd05964e64c6c925597279865a40a8c152f  
> Git:  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=  
> shortlog;h=refs/tags/2.1.16-tentative  
> Artifacts:  
> https://repository.apache.org/content/repositories/  
> orgapachecassandra-1129/org/apache/cassandra/apache-cassandra/2.1.16/  
> Staging repository:  
> https://repository.apache.org/content/repositories/  
> orgapachecassandra-1129/  
>  
> The Debian packages are available here: http://people.apache.org/~mshuler  
>  
> The vote will be open for 72 hours (longer if needed).  
>  
> [1]: (CHANGES.txt) https://goo.gl/xc7jn6  
> [2]: (NEWS.txt) https://goo.gl/O0C3Gb  
>  

Re: [VOTE] Accept dtests Donation Into Project

[Aleksey Yeschenko]

+1

-- 
AY

On 30 September 2016 at 19:51:32, Nate McCall (zzn...@apache.org) wrote:

I propose we begin the process of accepting the contribution of the  
dtest codebase (https://github.com/riptano/cassandra-dtest) into the  
project.  

Background discussion thread here:  
https://lists.apache.org/thread.html/840fd900fb7f6568bfa008d122d4375b708c1f7f1b5929018118d5d5@%3Cdev.cassandra.apache.org%3E
  

Note: It won't be immediate as there are some steps to follow [0] for  
accepting outside code contributions.  

The vote will be open for 72 hours.  

-Nate  

[0] http://incubator.apache.org/ip-clearance/ip-clearance-template.html  

Re: Failing tests 2016-09-28

[Aleksey Yeschenko]

We had one accidental merge from 3.0 into 3.9 (looking at you, you know who you 
are), so could be.

-- 
AY

On 28 September 2016 at 17:48:27, Philip Thompson 
(philip.thomp...@datastax.com) wrote:

That ticket was only supposed to be committed to 3.10 and 3.0.x. Was it  
accidentally also merged into 3.9?  

On Wed, Sep 28, 2016 at 12:40 PM, Oleksandr Petrov <  
oleksandr.pet...@gmail.com> wrote:  

> LWTTester issues are leftovers from the bad merge in  
> https://github.com/riptano/cassandra-dtest/pull/1214  
>  
> I've rebased and currently re-running tests.  
>  
> On Wed, Sep 28, 2016 at 6:23 PM Philip Thompson <  
> philip.thomp...@datastax.com> wrote:  
>  
> > Hi All,  
> >  
> > cassandra-3.9:  
> > ===  
> > testall: All passed!  
> >  
> > ===  
> > dtest: 4 failures  
> >  
> > cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest  
> > .test_round_trip_with_authentication  
> > Flaky test, needs a Jira ticket  
> >  
> >  
> > cql_tests.LWTTester  
> > .conditional_deletes_on_static_columns_with_null_values_test  
> >  
> > cql_tests.LWTTeste  
> > r.conditional_deletes_on_static_columns_with_null_values_batch_test  
> >  
> > cql_tests.LWTTester  
> > .conditional_updates_on_static_columns_with_null_values_test  
> > These three failures are all the same, and need a ticket  
> > ===  
> > upgrade: 661 failures  
> >  
> > I won't enumerate these here. 12697 should resolve them, and also  
> explains  
> > where they're all coming from  
> >  
> > ===  
> > novnode: All passed!  
> >  
> > ===  
> >  
> > trunk:  
> >  
> > ===  
> > testall: 13 failures  
> >  
> > org.apache.cassandra.config.DatabaseDescriptorRefTest  
> > .testDatabaseDescriptorRef  
> >  
> > org.apache.cassandra.config.DatabaseDescriptorRefTest  
> > .testDatabaseDescriptorRef-compression  
> > CASSANDRA-12677 for the two failures above.  
> >  
> > org.apache.cassandra.service.RemoveTest  
> > .testLocalHostId  
> > CASSANDRA-12714  
> >  
> > 10 unlisted timeouts  
> >  
> > ===  
> > dtest: 4 failures  
> >  
> > materialized_views_test.TestMaterializedViews  
> > .clustering_column_test  
> >  
> > materialized_views_test.TestMaterializedViews  
> > .insert_test  
> >  
> > materialized_views_test.TestMaterializedViews  
> > .query_all_new_column_test  
> >  
> > materialized_views_test.TestMaterializedViews  
> > .query_new_column_test  
> >  
> > No need to file a jira for these, I've fixed them already.  
> >  
> > ===  
> > upgrade: 662 failures  
> >  
> > I won't enumerate these here. 12697 should resolve them, and also  
> explains  
> > where they're all coming from  
> >  
> > ===  
> > novnode: 9 failures  
> >  
> > Same 8 paging failures. CASSANDRA-12666  
> >  
> > compaction_test.TestCompaction_with_DateTieredCompactionStrategy  
> > .bloomfilter_size_test  
> > CASSANDRA-12711  
> >  
> > Thanks,  
> > Philip  
> >  
> --  
> Alex Petrov  
>  

Re: Create table with ID - Question

[Aleksey Yeschenko]

No way to do that via Thrift I’m afraid, nor will there be one. Sorry.

-- 
AY

On 28 September 2016 at 16:43:58, Roman Bielik 
(roman.bie...@openmindnetworks.com) wrote:

Hi,  

in CQL it is possible to create a table with explicit ID: CREATE TABLE ...  
WITH ID='xyz'.  

Is something like this possible via Thrift interface?  
There is an int32 "id" field in CfDef, but it has no effect on the table ID.  

My problem is, that concurrent create table (add_column_family) requests  
for the same table name result in clash with somewhat unpredictable  
behavior.  

This problem was reported in:  
https://issues.apache.org/jira/browse/CASSANDRA-9933  

and seems to be related to changes from ticket:  
https://issues.apache.org/jira/browse/CASSANDRA-5202  

A workaround for me could be using the same ID in create table, however I'm  
using Thrift interface only.  

Thank you.  
Regards,  
Roman  

--  

  
  
   

Re: A home for 4.0

[Aleksey Yeschenko]

WFM

-- 
AY

On 27 September 2016 at 11:18:33, Sylvain Lebresne (sylv...@datastax.com) wrote:

We have a number of tickets that we now have to wait on 4.0 due to needing a  
messaging protocol change or major sstable format (https://goo.gl/OvqNQp),  
and  
we currently have no branch for those. And as 4.0 was initially supposed to  
come  
after 3.11, which is coming, it's probably time to have a home for those  
tickets.  

And as 4.0 should probably be the 'trunk' (at least it's how we've always  
done),  
I'm proposing to create a new '3.X' branch from trunk as home for the  
remaining  
3.x tick-tock release. In that configuration, the merge path will become:  

2.1 -> 2.2 -> 3.0 -> 3.X -> trunk (future 4.0)  

Any strong objection to me creating that branch?  

Sylvain Lebresne  

Re: [VOTE] Release Apache Cassandra 3.9

[Aleksey Yeschenko]

+1

-- 
AY

On 26 September 2016 at 16:12:50, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.9.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/TEMHqi  
[2]: (NEWS.txt) https://goo.gl/1w6Ec1  

--  
Kind regards,  
Michael Shuler  

Re: [VOTE] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

+1

-- 
AY

On 26 September 2016 at 15:52:26, Michael Shuler (mich...@pbandjelly.org) wrote:

I propose the following artifacts for release as 3.8.  

sha1: ce609d19fd130e16184d9e6d37ffee4a1ebad607  
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-1126/org/apache/cassandra/apache-cassandra/3.8/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1126/  

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

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

[1]: (CHANGES.txt) https://goo.gl/b80Qe2  
[2]: (NEWS.txt) https://goo.gl/Aen2iN  

--  
Kind regards,  
Michael  

Re: cassandra-3.9 (and 3.8) release

[Aleksey Yeschenko]

Please don’t make me argue over 3.8/3.9 again. We are way, way over our 
original schedule at this point.

Releasing 3.9 now breaks no promises. You still get more than a month of purely 
bug fixes in the release.

And if we only do 3.8 off the current cassandra-3.9 branch, then trunk becomes 
the next 3.9,
except it already has a ton of new features, improvements, and a non-trivial 
amount of bugfixes as well.

We could branch off, and cherry-pick all the fixes back from trunk, but just 
releasing both now is a lot less work.

More importantly, it would mean delaying 3.9 by another month. We’ve 
communicated that odd ones are to be run in production,
so users stuck on 3.7 would have to wait even longer until the can upgrade 
further. And the delta between 3.7 and current cassandra-3.9
is pretty significant. Let’s not make people wait even longer, please?

Plus, we had a consensus when this came up last time. Let’s stick to the plan, 
because if we keep ignoring our
previous conclusions we’ll never release anything.

(binding) -1 to (only) releasing the current cassandra-3.9 head as 3.8.

Michael: please start both votes. For 3.8 there is consensus, for 3.9 there is 
consensus among PMCs. If something changed,
it’ll be reflected in the vote.

-- 
AY

On 23 September 2016 at 21:39:09, Michael Shuler (mich...@pbandjelly.org) wrote:

Jonathan's is a pretty compelling perspective.  

--  
Michael  

On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote:  
> Both are effectively 3.9 on steroids. One month of features and  
> improvements with 2 months of bug fixes on top.  
>  
> If anything, this overdelivers.  
>  
> -- AY  
>  
> On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com)  
> wrote:  
>  
> (non-binding) -1 on releasing 2 versions with the same version  
> number. Everything that's been communicated to the world has been  
> that there would be a feature release, then a bug fix release a month  
> later. This breaks that promise.  
>  
> On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler  
>  wrote:  
>  
>> Thanks! I'll do these release builds and start votes, first thing  
>> Monday morning, unless I find some time on Sunday.  
>>  
>> -- Michael  
>>  
>> On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote:  
>>> Branch 3.8 off 3.9 with a commit that only changes the version in  
>>> all  
>> appropriate places.  
>>>  
>>> Two separate votes works.  
>>>  
>>> -- AY  
>>>  
>>> On 23 September 2016 at 12:36:54, Michael Shuler  
>>> (mich...@pbandjelly.org)  
>> wrote:  
>>>  
>>> The cassandra-3.9 branch HEAD, commit bb371ea, looks good to  
>>> release (which will also be released as 3.8, changing just the  
>>> version number). I'm re-running a couple jobs right now, but  
>>> overall, I think we hit the goal of a clean board:  
>>> http://cassci.datastax.com/view/cassandra-3.9/  
>>>  
>>> If there are no objections, I'd like to roll up 3.9/3.8 and get  
>>> them out the door. Should this be on one vote, since they are  
>>> really the same, or do 2 votes? I'm actually not entirely sure  
>>> how the build for 3.8 will work, since the branch was deleted.  
>>> Should I create new branch again for 3.8 with the version edit?  
>>> This sounds the most reasonable and workable with the release  
>>> build process. This actually does sound like it should be 2  
>>> votes, since the commit sha will be different.. Thanks!  
>>>  
>>> -- Kind regards, Michael  
>>>  
>>  
>>  
>  

Re: cassandra-3.9 (and 3.8) release

[Aleksey Yeschenko]

Both are effectively 3.9 on steroids. One month of features and improvements 
with 2 months of bug fixes on top.

If anything, this overdelivers.

-- 
AY

On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com) wrote:

(non-binding) -1 on releasing 2 versions with the same version number.  
Everything that's been communicated to the world has been that there would  
be a feature release, then a bug fix release a month later. This breaks  
that promise.  

On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler   
wrote:  

> Thanks! I'll do these release builds and start votes, first thing Monday  
> morning, unless I find some time on Sunday.  
>  
> --  
> Michael  
>  
> On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote:  
> > Branch 3.8 off 3.9 with a commit that only changes the version in all  
> appropriate places.  
> >  
> > Two separate votes works.  
> >  
> > --  
> > AY  
> >  
> > On 23 September 2016 at 12:36:54, Michael Shuler (mich...@pbandjelly.org)  
> wrote:  
> >  
> > The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release  
> > (which will also be released as 3.8, changing just the version number).  
> > I'm re-running a couple jobs right now, but overall, I think we hit the  
> > goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/  
> >  
> > If there are no objections, I'd like to roll up 3.9/3.8 and get them out  
> > the door. Should this be on one vote, since they are really the same, or  
> > do 2 votes? I'm actually not entirely sure how the build for 3.8 will  
> > work, since the branch was deleted. Should I create new branch again for  
> > 3.8 with the version edit? This sounds the most reasonable and workable  
> > with the release build process. This actually does sound like it should  
> > be 2 votes, since the commit sha will be different.. Thanks!  
> >  
> > --  
> > Kind regards,  
> > Michael  
> >  
>  
>  

Re: [VOTE] Release Apache Cassandra 2.2.8

[Aleksey Yeschenko]

+1

-- 
AY

On 23 September 2016 at 16:04:58, Michael Shuler (mshu...@apache.org) wrote:

I propose the following artifacts for release as 2.2.8.  

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

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

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

[1]: (CHANGES.txt) https://goo.gl/3Chc0Z  
[2]: (NEWS.txt) https://goo.gl/0UgwXZ  

Re: cassandra-3.9 (and 3.8) release

[Aleksey Yeschenko]

Branch 3.8 off 3.9 with a commit that only changes the version in all 
appropriate places.

Two separate votes works.

-- 
AY

On 23 September 2016 at 12:36:54, Michael Shuler (mich...@pbandjelly.org) wrote:

The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release  
(which will also be released as 3.8, changing just the version number).  
I'm re-running a couple jobs right now, but overall, I think we hit the  
goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/  

If there are no objections, I'd like to roll up 3.9/3.8 and get them out  
the door. Should this be on one vote, since they are really the same, or  
do 2 votes? I'm actually not entirely sure how the build for 3.8 will  
work, since the branch was deleted. Should I create new branch again for  
3.8 with the version edit? This sounds the most reasonable and workable  
with the release build process. This actually does sound like it should  
be 2 votes, since the commit sha will be different.. Thanks!  

--  
Kind regards,  
Michael  

Re: [VOTE] Release Apache Cassandra 3.0.9

[Aleksey Yeschenko]

+1

-- 
AY

On 15 September 2016 at 11:58:24, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 3.0.9.  

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

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]: https://goo.gl/JKkE05 (CHANGES.txt)  
[2]: https://goo.gl/Hi8X71 (NEWS.txt)  

Re: in-tree 'Cassandra Development' docs

[Aleksey Yeschenko]

Can’t really forcefully assign work, including review work, to volunteers.

So I’m not sure what we can do here, other than perhaps create some sort of 
dashboard
to show tickets with unassigned reviewers, and tickets with overdue reviews.

Both can be easily done as JIRA filters, however.

As an individual volunteer committer, you just pick JIRAs you want to work 
on/review, if they aren’t taken.
If they are taken, you talk to the current assignee and ask them to take over. 
Usually if they aren’t far in,
they’ll happily yield, in my experience.

-- 
AY

On 28 August 2016 at 23:49:23, mck (m...@apache.org) wrote:


http://cassandra.apache.org/doc/latest/development/index.html  


This is fantastic. Thanks heaps and heaps for doing this.  
Stefan i believe you get some of the credit for this!  


The top level 'Community' link now seems a bit superfluous. I guess  
there are plans for this?  

There's also no docs on how which tickets get reviewed.  
As far as i know DS has an internal system for this, which is fair  
enough. But it would be nice to know more (and see  
formalised/documented) about how the tickets to review are pulled, how  
they'll split into different areas of code to make it easier for  
committers to review, and how tickets don't get forgotten along the way.  
I've had a number of tickets where the reviewer just 'disappeared' and  
many months went by. This is a potential source of frustration for  
contributors.  

Mick.  

Re: Github pull requests

[Aleksey Yeschenko]

Also, Github’s ability to modify files ‘in-place’ and create pull requests from 
those changes is
extremely important for our Docs progress. Now that we have proper in-tree 
documentation,
this would lower the barrier for Docs writers tremendously.

-- 
AY

On 26 August 2016 at 17:15:54, Jake Luciani (jak...@gmail.com) wrote:

Jake could you show an example issue and how the pipeline works?  

On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell  wrote:  

> We just switched Apache Thrift over to using Github for all our inbound  
> contributions, have not made Github canonical yet. We wanted to have one  
> unified way to accept patches and also make it easier for automated CI to  
> validate the patch prior to review. Much easier now that we have a set  
> pipeline  
>  
> -Jake  
>  
> On Fri, Aug 26, 2016 at 11:44 AM, Ben Coverston <  
> ben.covers...@datastax.com>  
> wrote:  
>  
> > I think it would certainly make contributing to Cassandra more  
> > straightforward.  
> >  
> > I'm not a committer, so I don't regularly create patches, and every time  
> I  
> > do I have to search/verify that I'm doing it right.  
> >  
> > But pull requests? I make pull requests every day, and GitHub makes that  
> > process work the same everywhere.  
> >  
> > On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis   
> wrote:  
> >  
> > > Hi all,  
> > >  
> > > Historically we've insisted that people go through the process of  
> > creating  
> > > a Jira issue and attaching a patch or linking a branch to demonstrate  
> > > intent-to-contribute and to make sure we have a unified record of  
> changes  
> > > in Jira.  
> > >  
> > > But I understand that other Apache projects are now recognizing a  
> github  
> > > pull request as intent-to-contribute [1] and some are even making  
> github  
> > > the official repo, with an Apache mirror, rather than the other way  
> > > around. (Maybe this is required to accept pull requests, I am not  
> sure.)  
> > >  
> > > Should we revisit our policy here?  
> > >  
> > > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed  
> > >  
> > > --  
> > > Jonathan Ellis  
> > > Project Chair, Apache Cassandra  
> > > co-founder, http://www.datastax.com  
> > > @spyced  
> > >  
> >  
> >  
> >  
> > --  
> > Ben Coverston  
> > DataStax -- The Apache Cassandra Company  
> >  
>  



--  
http://twitter.com/tjake  

Re: Github pull requests

[Aleksey Yeschenko]

Mark, I, for one, will be happy with the level of GitHub integration that Spark 
has, formal or otherwise.

As it stands right now, none of the committers/PMC members have any control 
over Cassandra Github mirror.

Which, among other things, means that we cannot even close the erroneously 
opened PRs ourselves,
they just accumulate unless the PR authors is kind enough to close them. That’s 
really frustrating.

-- 
AY

On 26 August 2016 at 17:07:29, Mark Thomas (ma...@apache.org) wrote:

On 26/08/2016 16:33, Jonathan Ellis wrote:  
> Hi all,  
>  
> Historically we've insisted that people go through the process of creating  
> a Jira issue and attaching a patch or linking a branch to demonstrate  
> intent-to-contribute and to make sure we have a unified record of changes  
> in Jira.  
>  
> But I understand that other Apache projects are now recognizing a github  
> pull request as intent-to-contribute [1] and some are even making github  
> the official repo, with an Apache mirror, rather than the other way  
> around. (Maybe this is required to accept pull requests, I am not sure.)  
>  
> Should we revisit our policy here?  

At the moment, the ASF Git repo is always the master, with GitHub as a  
mirror. That allows push requests to be made via GitHub.  

Infra is exploring options for giving PMCs greater control over GitHub  
config (including allowing GitHub to be the master with a golden copy  
held at the ASF) but that is a work in progress.  

As far as intent to contribute goes, there does appear to be a trend  
that the newer a project is to the ASF, the more formal the project  
makes process around recording intent to contribute. (The same can be  
said for other processes as well like Jira config.)  

It is worth noting that all the ASF requires is that there is an intent  
to contribute. Anything that can be reasonably read that way is fine.  
Many PMCs happily accept patches sent to the dev list (although they may  
ask them to be attached to issues more so they don't get forgotten than  
anything else). Pull requests are certainly acceptable.  

My personal recommendation is don't put more formal process in place  
than you actually need. Social controls are a lot more flexible than  
technical ones and generally have a much lower overhead.  

Mark  

>  
> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed  

Re: 3.8/3.9 releases/branch freeze, current merge order

[Aleksey Yeschenko]

No worries. It was a somewhat.. messy thread.

And it’s taken us a while to get the tests to this level, so it’s somewhat far 
away in time in the past.

-- 
AY

On 24 August 2016 at 20:43:39, Mark Thomas (ma...@apache.org) wrote:

On 24/08/2016 20:26, Aleksey Yeschenko wrote:  
> No. Removing a dead branch is just mindless admin work.  
>  
> As for 3.8/3.9 plans, look up the previous quite lengthy vote discussion on 
> 3.8, on dev.  

Thanks. Found it. Just need to go back a little further in the archive.  

Mark  

>  
> --  
> AY  
>  
> On 24 August 2016 at 20:23:04, Mark Thomas (ma...@apache.org) wrote:  
>  
> On 24/08/2016 16:44, Aleksey Yeschenko wrote:  
>  
>   
>  
>> Also, cassandra-3.8 branch was removed from the repo, to further minimise 
>> confusion.  
>  
> That is the sort of thing I'd expect to see discussed on the dev list  
> first. Where is that discussion?  
>  
> Mark  
>  
>  
>  

Re: 3.8/3.9 releases/branch freeze, current merge order

[Aleksey Yeschenko]

No. Removing a dead branch is just mindless admin work.

As for 3.8/3.9 plans, look up the previous quite lengthy vote discussion on 
3.8, on dev.

-- 
AY

On 24 August 2016 at 20:23:04, Mark Thomas (ma...@apache.org) wrote:

On 24/08/2016 16:44, Aleksey Yeschenko wrote:  

  

> Also, cassandra-3.8 branch was removed from the repo, to further minimise 
> confusion.  

That is the sort of thing I'd expect to see discussed on the dev list  
first. Where is that discussion?  

Mark  

Re: 3.8/3.9 releases/branch freeze, current merge order

[Aleksey Yeschenko]

Correction: s/12528/11195/g. I’m an idiot who cannot copy-paste.

Also, cassandra-3.8 branch was removed from the repo, to further minimise 
confusion.

-- 
AY

On 24 August 2016 at 16:25:21, Aleksey Yeschenko (alek...@apache.org) wrote:

TL;DR: cassandra-3.8 branch is dead; cassandra-3.9 is frozen, unless you are 
committing the fix for #12140 or #12528.
For everything else go cassandra-3.0 -> trunk.

There has been some confusion regarding the current branch merge order that I’d 
like to clarify.

As you’ve seen from Joel’s last email, we are close to full Code Green status 
on casandra-3.9 branch, with one dtest and one upgrade test failing.

As soon as those two issues are resolved, we’ll be starting off the long 
delayed 3.8+3.9 votes.

What does it mean for the merge order? It means that unless you are committing 
the fix for CASSANDRA-12140 (the one failing dtest),
or the fix for CASSANDRA-12528 (the one failing upgrade test), you should skip 
cassandra-3.9 branch altogether and merge directly
into trunk (to become 3.10 eventually).

For all other tickets consider the branch to be frozen. On a related note, 
cassandra-3.8 branch is dead, and should be skipped altogether.

-- 
AY

3.8/3.9 releases/branch freeze, current merge order

[Aleksey Yeschenko]

TL;DR: cassandra-3.8 branch is dead; cassandra-3.9 is frozen, unless you are 
committing the fix for #12140 or #12528.
For everything else go cassandra-3.0 -> trunk.

There has been some confusion regarding the current branch merge order that I’d 
like to clarify.

As you’ve seen from Joel’s last email, we are close to full Code Green status 
on casandra-3.9 branch, with one dtest and one upgrade test failing.

As soon as those two issues are resolved, we’ll be starting off the long 
delayed 3.8+3.9 votes.

What does it mean for the merge order? It means that unless you are committing 
the fix for CASSANDRA-12140 (the one failing dtest),
or the fix for CASSANDRA-12528 (the one failing upgrade test), you should skip 
cassandra-3.9 branch altogether and merge directly
into trunk (to become 3.10 eventually).

For all other tickets consider the branch to be frozen. On a related note, 
cassandra-3.8 branch is dead, and should be skipped altogether.

-- 
AY

Re: 3.8, 3.9 release plan

[Aleksey Yeschenko]

No objections, the plan sounds good to me.

In addition to that, prep for pushing 3.0.9 out with 3.9.

-- 
AY

On 16 August 2016 at 16:51:24, Michael Shuler (mich...@pbandjelly.org) wrote:

Yesterday, it was suggested on #cassandra-dev that when 3.9 is ready for  
release, we release 3.8 with the same code base. My plan is to force  
push the contents of cassandra-3.9 branch to the cassandra-3.8 branch,  
updating the version appropriately, so we can build/test from the 3.8  
branch, as usual.  

Any objections to doing this push to 3.8 today, then again when we have  
a green light on 3.9 release?  

Thanks! Michael  

Re: A proposal to move away from Jira-centric development

[Aleksey Yeschenko]

Well, if you read carefully what Jeremiah and I have just proposed, it wouldn’t 
be an issue.

The notable major changes would start off on dev@ (think, a summary, a link to 
the JIRA, and maybe an attached spec doc).

No need to follow the JIRA feed. Watch dev@ for those announcements and start 
watching the invidual JIRA tickets if interested.

This creates the least amount of noise: you miss nothing important, and at the 
same time you won’t be receiving mail from
dev@ for each individual comment - including those on proposals you don’t care 
about.

We aren’t doing it currently, but we could, and probably should.

-- 
AY

On 15 August 2016 at 18:22:36, Chris Mattmann (mattm...@apache.org) wrote:

Discussion belongs on the dev list. Putting discussion in JIRA, is fine, but 
realize,  
there is a lot of noise in that signal and people may or may not be watching  
the JIRA list. In fact, I don’t see JIRA sent to the dev list at all so you are 
basically  
forking the conversation to a high noise list by putting it all in JIRA.  





On 8/15/16, 10:11 AM, "Aleksey Yeschenko"  wrote:  

I too feel like it would be sufficient to announce those major JIRAs on the 
dev@ list, but keep all discussion itself to JIRA, where it belongs.  

You don’t need to follow every ticket this way, just subscribe to dev@ and then 
start watching the select major JIRAs you care about.  

--  
AY  

On 15 August 2016 at 18:08:20, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:  

I like keeping things in JIRA because then everything is in one place, and it 
is easy to refer someone to it in the future.  
But I agree that JIRA tickets with a bunch of design discussion and POC’s and 
such in them can get pretty long and convoluted.  

I don’t really like the idea of moving all of that discussion to email which 
makes it has harder to point someone to it. Maybe a better idea would be to 
have a “design/POC” JIRA and an “implementation” JIRA. That way we could still 
keep things in JIRA, but the final decision would be kept “clean”.  

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.  

My 2c.  

-Jeremiah  


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  wrote:  
>  
> A long time ago, I was a proponent of keeping most development discussions  
> on Jira, where tickets can be self contained and the threadless nature  
> helps keep discussions from getting sidetracked.  
>  
> But Cassandra was a lot smaller then, and as we've grown it has become  
> necessary to separate out the signal (discussions of new features and major  
> changes) from the noise of routine bug reports.  
>  
> I propose that we take advantage of the dev list to perform that  
> separation. Major new features and architectural improvements should be  
> discussed first here, then when consensus on design is achieved, moved to  
> Jira for implementation and review.  
>  
> I think this will also help with the problem when the initial idea proves  
> to be unworkable and gets revised substantially later after much  
> discussion. It can be difficult to figure out what the conclusion was, as  
> review comments start to pile up afterwards. Having that discussion on the  
> list, and summarizing on Jira, would mitigate this.  
>  
> --  
> Jonathan Ellis  
> Project Chair, Apache Cassandra  
> co-founder, http://www.datastax.com  
> @spyced  

Re: A proposal to move away from Jira-centric development

[Aleksey Yeschenko]

I too feel like it would be sufficient to announce those major JIRAs on the 
dev@ list, but keep all discussion itself to JIRA, where it belongs.

You don’t need to follow every ticket this way, just subscribe to dev@ and then 
start watching the select major JIRAs you care about.

-- 
AY

On 15 August 2016 at 18:08:20, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

I like keeping things in JIRA because then everything is in one place, and it 
is easy to refer someone to it in the future.  
But I agree that JIRA tickets with a bunch of design discussion and POC’s and 
such in them can get pretty long and convoluted.  

I don’t really like the idea of moving all of that discussion to email which 
makes it has harder to point someone to it. Maybe a better idea would be to 
have a “design/POC” JIRA and an “implementation” JIRA. That way we could still 
keep things in JIRA, but the final decision would be kept “clean”.  

Though it would be nice if people would send an email to the dev list when 
proposing “design” JIRA’s, as not everyone has time to follow every JIRA ever 
made to see that a new design JIRA was created that they might be interested in 
participating on.  

My 2c.  

-Jeremiah  


> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis  wrote:  
>  
> A long time ago, I was a proponent of keeping most development discussions  
> on Jira, where tickets can be self contained and the threadless nature  
> helps keep discussions from getting sidetracked.  
>  
> But Cassandra was a lot smaller then, and as we've grown it has become  
> necessary to separate out the signal (discussions of new features and major  
> changes) from the noise of routine bug reports.  
>  
> I propose that we take advantage of the dev list to perform that  
> separation. Major new features and architectural improvements should be  
> discussed first here, then when consensus on design is achieved, moved to  
> Jira for implementation and review.  
>  
> I think this will also help with the problem when the initial idea proves  
> to be unworkable and gets revised substantially later after much  
> discussion. It can be difficult to figure out what the conclusion was, as  
> review comments start to pile up afterwards. Having that discussion on the  
> list, and summarizing on Jira, would mitigate this.  
>  
> --  
> Jonathan Ellis  
> Project Chair, Apache Cassandra  
> co-founder, http://www.datastax.com  
> @spyced  

Re: [VOTE] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

Jake was just swapping his vote +1 to -1.

Swapping mine to -1 too, so that we have a binding -1 majority now.

Let’s get #12236 in and then decide what to do.

-- 
AY

On 28 July 2016 at 19:46:56, Benedict Elliott Smith (bened...@apache.org) wrote:

I think -1 lacks a little clarity when responding to a block of prose with  
multiple clauses, suggestions and no single proposition requiring a yes/no  
answer.  

As fun as it is to type -1.  


On Thursday, 28 July 2016, Jake Luciani > wrote:  

> -1  
>  
> On Thu, Jul 28, 2016 at 2:19 PM, Aleksey Yeschenko   
> wrote:  
>  
> > Let me sum up my thoughts so far.  
> >  
> > Some of the most important goals of tick-tock were 1) predictable,  
> regular  
> > releases with manageable changesets and  
> > 2)individual releases that are more stable than in our previous process.  
> >  
> > Now, we’ve already slipped a few times. Most recently with 3.6, and now  
> > with 3.8. If we push 3.9 as well, then the delay  
> > will cascade: 3.10, 3.11, and 3.12 will all be late according to the  
> > original plan.  
> >  
> > In other words, if we delay 3.9, then 6 out of 12 tick-tock releases will  
> > be off-schedule.  
> >  
> > Worse, so will be 3.0.9, 3.0.10, 3.0.11, and 3.0.12.  
> >  
> > Now, #12236 is indeed an issue, but it really is a minor annoyance, and  
> > goes away quickly after upgrading. And let’s not  
> > kid ourselves that just by fixing #12236 alone 3.8 will somehow become a  
> > stable release. No amount of passive aggressive  
> > remarks is going to change that, either. So the choices as I see them  
> > were: a) release 3.8 with a known minor annoyance now,  
> > so that we can at least save 3.9 to 3.12 schedule or b) delay 3.9-3.12  
> and  
> > 3.0.9-3.0.12 by a month, each, without that minor annoyance,  
> > but ultimately have just as stable/unstable 3.8. The pragmatic choice in  
> > my opinion is clearly (a): we at least maintain some regularity that way.  
> >  
> > That said, after having though about it more, I realised that it’s the  
> odd  
> > 3.9, not the even 3.8 that’s already late, that I really care about.  
> > So here are the two options I suggest - and I’m fine with either:  
> >  
> > 1. Release 3.8 as is now. It’s an even preview release that can live fine  
> > with one minor annoyance on upgrade. Have 3.9 released on schedule.  
> > Since the vote technically passed, we can just do it, now.  
> >  
> > 2. Wait until #12236 is in, and release 3.8 then, doesn’t matter when.  
> > Have 3.9+ released on schedule. Even though the delta between 3.8 and 3.9  
> > would  
> > be tiny, it’s still IMO less confusing than skipping a whole version, and  
> > a lot more preferable than failing the schedule for 4 upcoming 3.x and  
> > 3.0.x releases.  
> >  
> > 3.9, after all, *does* have a month of bugfix only stabilisation changes  
> > in it. So does 3.0.9. The sooner we can get those into people’s hands,  
> the  
> > better.  
> > 3.8 is ultimately unimportant. Even if we release 3.8 and 3.9 on the same  
> > date, it’s not a huge deal.  
> >  
> >  
> > P.S. I feel like 1 week freeze is insufficient given a monthly cadence.  
> If  
> > we are to keep the monthly cycle, we should probably extend the freeze to  
> > two weeks,  
> > so that we have time to fix problems uncovered by regular and, more  
> > importantly, upgrade tests.  
> >  
> > --  
> > AY  
> >  
> > On 27 July 2016 at 22:04:31, Michael Shuler (mshu...@apache.org) wrote:  
> >  
> > I apologize for messing this vote up.  
> >  
> > So, what should happen now? Drop RESULT from the subject and continue  
> > discussion of alternatives and voting?  
> >  
> > --  
> > Kind regards,  
> > Michael  
> >  
> > On 07/27/2016 06:33 AM, Aleksey Yeschenko wrote:  
> > > The difference is that those -1s were based on new information  
> > > discovered after the vote was started, while this one wasn’t.  
> > >  
> > > In addition to that, the discussion was still ongoing, and a decision  
> > > on the alternative has not been made. As such closing the vote was  
> > > definitely premature.  
> > >  
> > > FWIW I intended to swap my +1 with a -1, but was not given a chance  
> > > to do so. As for what alternative I prefer, I’m not sure yet.  
> > >  
> > > -- AY  
> > >  
> > > On 27 July 2016 at 09:59:50, Sylvain Lebresne (sylv...@datastax.com)  
> > > wrote:  
> > >  
> > > 

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

Let me sum up my thoughts so far.

Some of the most important goals of tick-tock were 1) predictable, regular 
releases with manageable changesets and 
2)individual releases that are more stable than in our previous process.

Now, we’ve already slipped a few times. Most recently with 3.6, and now with 
3.8. If we push 3.9 as well, then the delay
will cascade: 3.10, 3.11, and 3.12 will all be late according to the original 
plan.

In other words, if we delay 3.9, then 6 out of 12 tick-tock releases will be 
off-schedule.

Worse, so will be 3.0.9, 3.0.10, 3.0.11, and 3.0.12.

Now, #12236 is indeed an issue, but it really is a minor annoyance, and goes 
away quickly after upgrading. And let’s not
kid ourselves that just by fixing #12236 alone 3.8 will somehow become a stable 
release. No amount of passive aggressive
remarks is going to change that, either. So the choices as I see them were: a) 
release 3.8 with a known minor annoyance now,
so that we can at least save 3.9 to 3.12 schedule or b) delay 3.9-3.12 and 
3.0.9-3.0.12 by a month, each, without that minor annoyance,
but ultimately have just as stable/unstable 3.8. The pragmatic choice in my 
opinion is clearly (a): we at least maintain some regularity that way.

That said, after having though about it more, I realised that it’s the odd 3.9, 
not the even 3.8 that’s already late, that I really care about.
So here are the two options I suggest - and I’m fine with either:

1. Release 3.8 as is now. It’s an even preview release that can live fine with 
one minor annoyance on upgrade. Have 3.9 released on schedule.
Since the vote technically passed, we can just do it, now.

2. Wait until #12236 is in, and release 3.8 then, doesn’t matter when. Have 
3.9+ released on schedule. Even though the delta between 3.8 and 3.9 would
be tiny, it’s still IMO less confusing than skipping a whole version, and a lot 
more preferable than failing the schedule for 4 upcoming 3.x and 3.0.x releases.

3.9, after all, *does* have a month of bugfix only stabilisation changes in it. 
So does 3.0.9. The sooner we can get those into people’s hands, the better.
3.8 is ultimately unimportant. Even if we release 3.8 and 3.9 on the same date, 
it’s not a huge deal.


P.S. I feel like 1 week freeze is insufficient given a monthly cadence. If we 
are to keep the monthly cycle, we should probably extend the freeze to two 
weeks,
so that we have time to fix problems uncovered by regular and, more 
importantly, upgrade tests.

-- 
AY

On 27 July 2016 at 22:04:31, Michael Shuler (mshu...@apache.org) wrote:

I apologize for messing this vote up.  

So, what should happen now? Drop RESULT from the subject and continue  
discussion of alternatives and voting?  

--  
Kind regards,  
Michael  

On 07/27/2016 06:33 AM, Aleksey Yeschenko wrote:  
> The difference is that those -1s were based on new information  
> discovered after the vote was started, while this one wasn’t.  
>  
> In addition to that, the discussion was still ongoing, and a decision  
> on the alternative has not been made. As such closing the vote was  
> definitely premature.  
>  
> FWIW I intended to swap my +1 with a -1, but was not given a chance  
> to do so. As for what alternative I prefer, I’m not sure yet.  
>  
> -- AY  
>  
> On 27 July 2016 at 09:59:50, Sylvain Lebresne (sylv...@datastax.com)  
> wrote:  
>  
> On Wed, Jul 27, 2016 at 12:42 AM, Aleksey Yeschenko  
>  wrote:  
>  
>> 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).  
>>  
>  
> It has been my understanding that we took a more human approach to  
> release decisions than strictly and blindly adhering to the Apache  
> written voting rules. There has been many votes that has been  
> re-rolled even though they had had more than 3 binding vote already  
> when a problem was detected, and it never took an official PMC vote  
> to do so, nor did we ever officially waited on the cast votes to be  
> officially reverted.  
>  
> I'm also sad that knowing that there is a bug that breaks in-flight  
> queries during upgrade *and* the fact the vast majority of our  
> upgrade tests are failing is not _obviously_ enough to hold a  
> release, without the need for further considerations. This speaks imo  
> poorly of the PMC attachment to release qualit

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

The difference is that those -1s were based on new information discovered after 
the vote was started, while this one wasn’t.

In addition to that, the discussion was still ongoing, and a decision on the 
alternative has not been made. As such closing the vote was definitely 
premature. 

FWIW I intended to swap my +1 with a -1, but was not given a chance to do so. 
As for what alternative I prefer, I’m not sure yet.

-- 
AY

On 27 July 2016 at 09:59:50, Sylvain Lebresne (sylv...@datastax.com) wrote:

On Wed, Jul 27, 2016 at 12:42 AM, Aleksey Yeschenko   
wrote:  

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

It has been my understanding that we took a more human approach to release  
decisions than strictly and blindly adhering to the Apache written voting  
rules. There has been many votes that has been re-rolled even though they  
had had more than 3 binding vote already when a problem was detected, and  
it never took an official PMC vote to do so, nor did we ever officially  
waited on the cast votes to be officially reverted.  

I'm also sad that knowing that there is a bug that breaks in-flight queries  
during upgrade *and* the fact the vast majority of our upgrade tests are  
failing is not _obviously_ enough to hold a release, without the need for  
further considerations. This speaks imo poorly of the PMC attachment to  
release quality.  

But you are correct on the technicality of vote counting and their official  
consequences according to the written rules ...  


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

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Aleksey Yeschenko]

Sorry (: Only see yours, Dave’s, and mine in my client. Apparently I’ve trashed 
the email chain at some point.

-- 
AY

On 26 July 2016 at 23:48:49, Brandon Williams (dri...@gmail.com) wrote:

Small nit: there are currently 5 binding +1 and 1 binding -1, (or 2, with  
Jonathan.)  

On Tue, Jul 26, 2016 at 5:42 PM, Aleksey Yeschenko   
wrote:  

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

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

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] 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: [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: 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: 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: 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: [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]

+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: 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: [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: [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 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: 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: 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: [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)  
>