Re: [VOTE] CEP-25: Trie-indexed SSTable format

[Jake Luciani]

+1

On Mon, Dec 19, 2022 at 7:27 PM C. Scott Andreas 
wrote:

> +1nb
>
> On Dec 19, 2022, at 1:27 PM, Josh McKenzie  wrote:
>
>
> +1
>
> On Mon, Dec 19, 2022, at 11:54 AM, SAURABH VERMA wrote:
>
> +1
>
> On Mon, Dec 19, 2022 at 9:36 PM Benjamin Lerer  wrote:
>
> +1
>
> Le lun. 19 déc. 2022 à 16:31, Andrés de la Peña  a
> écrit :
>
> +1
>
> On Mon, 19 Dec 2022 at 15:11, Aleksey Yeshchenko 
> wrote:
>
> +1
>
> On 19 Dec 2022, at 13:42, Ekaterina Dimitrova 
> wrote:
>
> +1
>
> On Mon, 19 Dec 2022 at 8:30, J. D. Jordan 
> wrote:
>
> +1 nb
>
> > On Dec 19, 2022, at 7:07 AM, Brandon Williams  wrote:
> >
> > +1
> >
> > Kind Regards,
> > Brandon
> >
> >> On Mon, Dec 19, 2022 at 6:59 AM Branimir Lambov 
> wrote:
> >>
> >> Hi everyone,
> >>
> >> I'd like to propose CEP-25 for approval.
> >>
> >> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format
> >> Discussion:
> https://lists.apache.org/thread/3dpdg6dgm3rqxj96cyhn58b50g415dyh
> >>
> >> The vote will be open for 72 hours.
> >> Votes by committers are considered binding.
> >> A vote passes if there are at least three binding +1s and no binding
> vetoes.
> >>
> >> Thank you,
> >> Branimir
>
>
>
>
> --
> Thanks & Regards,
> Saurabh Verma,
> India
>
>

-- 
http://twitter.com/tjake

Re: Downgradability

[Jake Luciani]

There has been progress on
https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-8928

Which is similar to what datastax does for DSE. Would this be an acceptable
solution?

Jake

On Mon, Feb 20, 2023 at 11:17 AM guo Maxwell  wrote:

> It seems “An alternative solution is to implement/complete CASSANDRA-8110
> ” can give us more
> options if it is finished😉
>
> Branimir Lambov 于2023年2月20日 周一下午11:03写道：
>
>> Hi everyone,
>>
>> There has been a discussion lately about changes to the sstable format in
>> the context of being able to abort a cluster upgrade, and the fact that
>> changes to sstables can prevent downgraded nodes from reading any data
>> written during their temporary operation with the new version.
>>
>> Most of the discussion is in CASSANDRA-18134
>> , and is
>> spreading into CASSANDRA-14277
>>  and
>> CASSANDRA-17698 ,
>> none of which is a good place to discuss the topic seriously.
>>
>> Downgradability is a worthy goal and is listed in the current roadmap. I
>> would like to open a discussion here on how it would be achieved.
>>
>> My understanding of what has been suggested so far translates to:
>> - avoid changes to sstable formats;
>> - if there are changes, implement them in a way that is
>> backwards-compatible, e.g. by duplicating data, so that a new version is
>> presented in a component or portion of a component that legacy nodes will
>> not try to read;
>> - if the latter is not feasible, make sure the changes are only applied
>> if a feature flag has been enabled.
>>
>> To me this approach introduces several risks:
>> - it bloats file and parsing complexity;
>> - it discourages improvement (e.g. CASSANDRA-17698 is no longer a LHF
>> ticket once this requirement is in place);
>> - it needs care to avoid risky solutions to address technical issues with
>> the format versioning (e.g. staying on n-versions for 5.0 and needing a
>> bump for a 4.1 bugfix might require porting over support for new features);
>> - it requires separate and uncoordinated solutions to the problem and
>> switching mechanisms for each individual change.
>>
>> An alternative solution is to implement/complete CASSANDRA-8110
>> , which provides a
>> method of writing sstables for a target version. During upgrades, a node
>> could be set to produce sstables corresponding to the older version, and
>> there is a very straightforward way to implement modifications to formats
>> like the tickets above to conform to its requirements.
>>
>> What do people think should be the way forward?
>>
>> Regards,
>> Branimir
>>
>>
>> --
> you are the apple of my eye !
>
-- 
http://twitter.com/tjake

Re: [VOTE] CEP-30 ANN Vector Search

[Jake Luciani]

+1

On Thu, May 25, 2023 at 11:45 AM Jonathan Ellis  wrote:

> Let's make this official.
>
> CEP:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes
>
> POC that demonstrates all the big rocks, including distributed queries:
> https://github.com/datastax/cassandra/tree/cep-vsearch
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>
-- 
http://twitter.com/tjake

Re: [VOTE] CEP-8 Datastax Drivers Donation

[Jake Luciani]

+1

On Tue, Jun 13, 2023 at 7:14 PM Nate McCall  wrote:

> +1
>
> On Wed, Jun 14, 2023 at 2:15 AM Jeremy Hanna 
> wrote:
>
>> Calling for a vote on CEP-8 [1].
>>
>> To clarify the intent, as Benjamin said in the discussion thread [2], the
>> goal of this vote is simply to ensure that the community is in favor of
>> the donation. Nothing more.
>> The plan is to introduce the drivers, one by one. Each driver donation
>> will need to be accepted first by the PMC members, as it is the case for
>> any donation. Therefore the PMC should have full control on the pace at
>> which new drivers are accepted.
>>
>> If this vote passes, we can start this process for the Java driver under
>> the direction of the PMC.
>>
>> Jeremy
>>
>> 1.
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
>> 2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp
>>
>

-- 
http://twitter.com/tjake

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

[Jake Luciani]

We (DataStax) have a FileSystemProvider for Astra we can provide.
Works with S3/GCS/Azure.

I'll ask someone on our end to make it accessible.

This would work by having a bucket prefix per node. But there are lots
of details needed to support things like out of bound compaction
(mentioned in CEP).

Jake

On Tue, Sep 26, 2023 at 12:56 PM Benedict  wrote:
>
> I agree with Ariel, the more suitable insertion point is probably the JDK 
> level FileSystemProvider and FileSystem abstraction.
>
> It might also be that we can reuse existing work here in some cases?
>
> On 26 Sep 2023, at 17:49, Ariel Weisberg  wrote:
>
> 
> Hi,
>
> Support for multiple storage backends including remote storage backends is a 
> pretty high value piece of functionality. I am happy to see there is interest 
> in that.
>
> I think that `ChannelProxyFactory` as an integration point is going to 
> quickly turn into a dead end as we get into really using multiple storage 
> backends. We need to be able to list files and really the full range of 
> filesystem interactions that Java supports should work with any backend to 
> make development, testing, and using existing code straightforward.
>
> It's a little more work to get C* to creates paths for alternate backends 
> where appropriate, but that works is probably necessary even with 
> `ChanelProxyFactory` and munging UNIX paths (vs supporting multiple 
> Fileystems). There will probably also be backend specific behaviors that show 
> up above the `ChannelProxy` layer that will depend on the backend.
>
> Ideally there would be some config to specify several backend filesystems and 
> their individual configuration that can be used, as well as configuration and 
> support for a "backend file router" for file creation (and opening) that can 
> be used to route files to the backend most appropriate.
>
> Regards,
> Ariel
>
> On Mon, Sep 25, 2023, at 2:48 AM, Claude Warren, Jr via dev wrote:
>
> I have just filed CEP-36 [1] to allow for keyspace/table storage outside of 
> the standard storage space.
>
> There are two desires  driving this change:
>
> The ability to temporarily move some keyspaces/tables to storage outside the 
> normal directory tree to other disk so that compaction can occur in 
> situations where there is not enough disk space for compaction and the 
> processing to the moved data can not be suspended.
> The ability to store infrequently used data on slower cheaper storage layers.
>
> I have a working POC implementation [2] though there are some issues still to 
> be solved and much logging to be reduced.
>
> I look forward to productive discussions,
> Claude
>
> [1] 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-36%3A+A+Configurable+ChannelProxy+to+alias+external+storage+locations
> [2] https://github.com/Claudenw/cassandra/tree/channel_proxy_factory
>
>
>


-- 
http://twitter.com/tjake

Re: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API

[Jake Luciani]

Hi,

I originally worked on the management API sidecar mentioned above.
I'm excited to see there's renewed interest in the cql for ops concept.

Though it currently uses an agent to inject the local socket for cql
(so it can be used by older versions of Apache Cassandra),
Similar logic like the management api project could be added directly
to C* versions if the sidecar project has picked versions it would
support.

I think for security reasons and operability the local unix socket is
the cleanest way to support cql as management.
It also works very well for any sidecar to access ops (while not
messing with JMX).

Let me know if there's anything I can do to help.

Jake

On Mon, Nov 20, 2023 at 11:40 AM German Eichberger via dev
 wrote:
>
> Hi,
>
> From a cloud provider perspective we expose the storage port to customers for 
> Hybrid scenarios (e.g. fusing on-prem Cassandra with in-cloud Cassandra) so 
> would prefer an extra port or a socket.
> Thanks,
> German
>
> 
> From: Dinesh Joshi 
> Sent: Friday, November 17, 2023 4:06 PM
> To: dev 
> Subject: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API
>
> Hi Maxim,
>
> Thanks for putting this CEP together! This is a great start. I have gone over 
> the CEP and there is one thing that stuck out to me.
>
> Among the 'basic requirements', I see you have this -
>
> > A dedicated admin port with the native protocol behind it,
> > allowing only admin commands, to address the concerns when
> > the native protocol is disabled in certain circumstances
> > e.g. the disablebinary command is executed;
>
> I understand what you're achieve here. However, there are a few reasons we 
> should probably offer some choice to our users w.r.t. using a dedicated port 
> for management functions.
>
> Today Cassandra exposes several ports - 9042, 9142, 7000 and 7001. The 
> sidecar runs on port 9043. Thats a lot of ports. I would prefer to allow 
> users to access management functionality over one of the existing ports.
>
> I realize that this would mean a subtle change in behavior for disablebinary 
> when we offer it over port 9042 and not when the operator decides to use a 
> dedicated port.
>
> More importantly, I think having this functionality exposed over the storage 
> ports may be even better. The storage ports are typically firewalled off from 
> the end users. Operators and tooling, however, usually have access to these 
> ports. This especially makes sense from a security standpoint where we'd like 
> to limit users from accessing management functionality.
>
> What do others think about this approach?
>
> thanks,
>
> Dinesh
>
> > On Nov 13, 2023, at 10:08 AM, Maxim Muzafarov  wrote:
> >
> > Hello everyone,
> >
> > While we are still waiting for the review to make the settings virtual
> > table updatable (CASSANDRA-15254), which will improve the
> > configuration management experience for users, I'd like to take
> > another step forward and improve the C* management approach we have as
> > a whole. This approach aims to make all Cassandra management commands
> > accessible via CQL, but not only that.
> >
> > The problem of making commands accessible via CQL presents a complex
> > challenge, especially if we aim to minimize code duplication across
> > the implementation of management operations for different APIs and
> > reduce the overall maintenance burden. The proposal's scope goes
> > beyond simply introducing a new CQL syntax. It encompasses several key
> > objectives for C* management operations, beyond their availability
> > through CQL:
> > - Ensure consistency across all public APIs we support, including JMX
> > MBeans and the newly introduced CQL. Users should see consistent
> > command specifications and arguments, irrespective of whether they're
> > using an API or a CLI;
> > - Reduce source code maintenance costs. With this new approach, when a
> > new command is implemented, it should automatically become available
> > across JMX MBeans, nodetool, CQL, and Cassandra Sidecar, eliminating
> > the need for additional coding;
> > - Maintain backward compatibility, ensuring that existing setups and
> > workflows continue to work the same way as they do today;
> >
> > I would suggest discussing the overall design concept first, and then
> > diving into the CQL command syntax and other details once we've found
> > common ground on the community's vision. However, regardless of these
> > details, I would appreciate any feedback on the design.
> >
> > I look forward to your comments!
> >
> > Please, see the design document: CEP-38: CQL Management API
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FCASSANDRA%2FCEP-38%253A%2BCQL%2BManagement%2BAPI&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7C510fbe97b579406b389f08dbe7ca5430%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638358628430485779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL

C* Sidecar Collaboration

[Jake Luciani]

Hello!
As discussed on the contributors call a couple weeks back[1], I'd like to
announce the open sourcing of a Management API Sidecar project for Apache
Cassandra that some of us have been using at Datastax[2]. It is separate
from the existing C* sidecar subproject right now as we needed specific
functionality to support an operator that we're actively open-sourcing as
well. The intent is to work on incorporating this with the official C*
sidecar project[3].

I'll cover the core similarities/differences I see below:

Similarities:
  * Simple REST API for operations
  * Healthchecks
  * Lifecycle management
  * Basic configuration management
Differences:
* Local access only.
  - Each sidecar process is responsible for the local C* instance
* CQL communication only.
  - Communication between Management API and C* is via CQL only
  - A simple CQL -> method mechanism is added to C* resulting in the
ability to execute statements like: "CALL NodeOps.compact('keyspace');"
* Secure by default.
  - The Management API talks to C* via a local unix socket.
  - The Management API has its own local unix socket so local tools can
communicate securely.
  - Optional Mutual TLS support for secure services
  - Disables default cassandra/cassandra superuser
* No configuration file
  - Keeps deployments simple
* Hooks into Existing C* releases by utilizing a new java agent.

I've opened an EPIC[4] to discuss details of this work.  Sending a note
here so people are aware; I know everyone is heads down on the C* 4.0 scope
right now.

[1]:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-1+Online+meeting+2020-03-10
[2]: http://github.com/datastax/management-api-for-apache-cassandra
[3]: https://github.com/apache/cassandra-sidecar
[4]: https://issues.apache.org/jira/browse/CASSANDRASC-13

Re: C* Sidecar Collaboration

[Jake Luciani]

Hi Stefan!

Yes, this is exactly why we want to move things into the official sidecar.
I think the same should happen for an official k8s operator too...

If you look at the readme for the management api you'll see we are dealing
with the same issues.
The management api is PID 1 for the container and it spawns c*.

I think going CQL Only and not relying on JMX which is why we added the
CALL cql syntax.
Also, by using a local unix socket which you can secure with file/group
permissions, you can bypass sidecar driver setup/auth, and let the callers
create roles as needed.  Like mysql.

I think sidecars are most useful for k8s but it's still quite important to
work as a standalone controller since there's no need to re-build c*
specific operations across different ecosystems,
so putting as much logic into C*/Sidecar makes a lot of sense.

-Jake

On Mon, Mar 30, 2020 at 12:23 PM Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Hey,
>
> good stuff!
>
> We in Instaclustr are already doing the effort in that area. We needed
> Sidecar (1) for our Kubernetes Cassandra operator (2) and it runs as a
> process in a container in the same pod where Cassandra runs.
>
> Right now it provides a very simple API how operations are invoked against
> that.
>
> There are two options, either via JMX or it is possible to leverage
> CQL connection. These operations are called from REST interface and we
> provide simple operations API on top of that (operation submission,
> getting its status and so on).
>
> In practice it is possible to use this Sidecar as as a standalone
> application which just connects to whatever Cassandra it is pointed to
> but it can also live in Kubernetes as already mentioned where it takes
> its credentials from pluggable Cassandra driver configuration
> mechanism from Kubernetes secrets / config maps (2) if custom auth is
> required.
>
> I can clearly see that we have a lot of sidecar implementations going
> on which is always good! It would be nice to exchange experiences and
> approaches taken and distil it ideally into one sidecar which would be
> the flagship of sidecars once and for all!
>
> Regards
>
> (1)
> https://github.com/instaclustr/cassandra-operator/tree/master/java/sidecar
> (2) https://github.com/instaclustr/cassandra-operator
> (3)
> https://github.com/instaclustr/cassandra-operator/blob/master/doc/auth.md#ssl-with-sidecar
>
> On Mon, 30 Mar 2020 at 17:20, Jake Luciani  wrote:
> >
> > Hello!
> > As discussed on the contributors call a couple weeks back[1], I'd like to
> > announce the open sourcing of a Management API Sidecar project for Apache
> > Cassandra that some of us have been using at Datastax[2]. It is separate
> > from the existing C* sidecar subproject right now as we needed specific
> > functionality to support an operator that we're actively open-sourcing as
> > well. The intent is to work on incorporating this with the official C*
> > sidecar project[3].
> >
> > I'll cover the core similarities/differences I see below:
> >
> > Similarities:
> >   * Simple REST API for operations
> >   * Healthchecks
> >   * Lifecycle management
> >   * Basic configuration management
> > Differences:
> > * Local access only.
> >   - Each sidecar process is responsible for the local C* instance
> > * CQL communication only.
> >   - Communication between Management API and C* is via CQL only
> >   - A simple CQL -> method mechanism is added to C* resulting in the
> > ability to execute statements like: "CALL NodeOps.compact('keyspace');"
> > * Secure by default.
> >   - The Management API talks to C* via a local unix socket.
> >   - The Management API has its own local unix socket so local tools can
> > communicate securely.
> >   - Optional Mutual TLS support for secure services
> >   - Disables default cassandra/cassandra superuser
> > * No configuration file
> >   - Keeps deployments simple
> > * Hooks into Existing C* releases by utilizing a new java agent.
> >
> > I've opened an EPIC[4] to discuss details of this work.  Sending a note
> > here so people are aware; I know everyone is heads down on the C* 4.0
> scope
> > right now.
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-1+Online+meeting+2020-03-10
> > [2]: http://github.com/datastax/management-api-for-apache-cassandra
> > [3]: https://github.com/apache/cassandra-sidecar
> > [4]: https://issues.apache.org/jira/browse/CASSANDRASC-13
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Kubernetes operator unification

[Jake Luciani]

Hi Ben!

Totally agree.  We should collaborate on a unified operator and I think as
deployment on k8s becomes more and more prevalent we need to have
distributed testing in k8s.

To that end we are working on OSS releasing our distributed testing service
we've developed over the years to make this easier and reproducible. Need a
few more days before that's ready
but it may give us a leg up.  I know Alex Petrov has been working a lot on
the new jvm dtest harness and may have some ideas.

Jake

On Tue, Mar 31, 2020 at 12:11 AM Ben Bromhead  wrote:

> Hi All
>
> With the announcement of a C* Sidecar and K8s operator from Datastax
> (congrats btw), Jake and Stefan discussed moving to a more
> standardised/unified implementation of an Apache Cassandra operator for
> Kubernetes. Based on discussions with other folks either using our
> operator, building/running their own or just getting started, there appears
> to be some broader enthusiasm to a more unified approach outside of just
> that thread.
>
> The current state of play for folks looking to run Apache Cassandra,
> particularly on Kubernetes, is fairly fragmented. There are multiple
> projects all doing similar things from large companies operating C* at
> scale on kubernetes, individual contributors and commercialising entities.
> Each one of these projects also have similar but diverse implementations
> and capabilities. From an end user perspective, it makes it very hard to
> figure out what path to take and from someone who supports these end users,
> I'd much rather support one implementation than 3 even if it's not the one
> we wrote :)
>
> To that end, I'd like to indicate that we (Instaclustr) are open to working
> towards a project owned standardized K8s operators/sidecar/etc. How that
> looks and how it gets implemented will surely be the subject of debate,
> especially amongst those with existing implementations.
>
> Before engaging in CEP process (
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201)
> it might be useful to informally discuss an approach to unifying
> implementations.
>
> To that end I'd like to circulate the following ideas to kick off the
> discussion of an approach that might be useful:
>
> We should look to start off with a new implementation in a separate repo
> (as the sidecar project has done), leveraging the experience and
> contributions from existing operator implementations and a framework like
> the operator-framework, with the initial scope of just supporting our
> distributed testing in our CI pipeline.
>
> Targeting our own distributed test cases (e.g. dtests) brings a number of
> benefits:
>
>- Defines a common environment and goals that minimizes each
>organisations unique kubernetes challenges.
>- Follows the spirit of the 4.0 release to be more dba/operator aligned,
>more production ready and easier to get right in a production setting
> OOB
>- Our test environment over time will look more and more like how users
>run Cassandra in production. This will be the biggest win IMHO.
>- The distributed tests will also serve as functional tests for the
>operator itself.
>
> The main drawback I can see with this approach is it will potentially be a
> longer path to getting a useable project based operator out the door. It
> will also involve a ton of reworking dtests, which for some is going to a
> hard blocker. From there we can start to expand and support more and more
> real life use cases. Hopefully this is not a huge leap as our testing
> should be covering most of those cases!
>
> This is largely my personal gut feel on the approach and I'm looking
> forward to folks other suggestions!
>
> Cheers
>
> --
>
> Ben Bromhead
>
> Instaclustr | www.instaclustr.com | @instaclustr
>  | (650) 284 9692
>

Re: Idea: Marking required scope for 4.0 GA vs. optional

[Jake Luciani]

I've been starting to look at the work left for 4.0 and was surprised to
see almost 1/2 the open tickets are Improvements.
Shouldn't the only criteria for 4.0 at this point should be bugs.

Can we agree to move the improvements out to 4.0.x?

-Jake

On Tue, Mar 31, 2020 at 4:02 PM Ekaterina Dimitrova <
ekaterina.dimitr...@datastax.com> wrote:

> Hello everyone,
> I think the project might benefit of one "filter applied" now on the
> current scope of JIRA tickets.
> And then, regular triage so focus is not lost.
>
> Up to now, I always try to look at the Release Lifecycle [1] criteria when
> I open a new ticket in order to mark what is the target version of the
> patch. Also, I look from the perspective of the general code freeze.
> Hope I am doing it right. If those are strictly marked, do we need
> additional label for blocking tickets? Or we want to differentiate between
> strong blockers and such patches which would be good if they land at a
> specific release but not mandatory?
>
> Why I am in for initial filter now? As I found many tickets opened in
> 2016...17...etc Things have changed a lot since then and there can be
> easily different PoV nowadays.
>
> I would be more than happy to help in any of these activities, too.
>
> Ekaterina
>
> [1]
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
>
> > Begin forwarded message:
> >
> > *From:* David Capwell 
> > *Date:* 31 March 2020, 15:15:11 GMT-4
> > *To:* dev@cassandra.apache.org
> > *Subject:* *Re:  Idea: Marking required scope for 4.0 GA vs. optional*
> > *Reply-To:* dev@cassandra.apache.org
> >
> > What I'm used to is having two buckets for a release: tickets in the
> > release (if not complete they are blockers), and triage. How this is done
> > isn't important but I do feel it's important to have both.
> >
> > Right now I don't see a active triage, but to Josh's point we would need
> to
> > know who should first. Without answering, let me ask a question; should I
> > (non committer) be adding blockers? If I add a blocker who should verify
> it
> > should block? What if project members elect non-commiters to do this?
> >
> >
> >
> > On Mon, Mar 30, 2020, 8:45 AM Joshua McKenzie 
> > wrote:
> >
> > Regardless of how we indicate optional vs. required for rel, are there
> >
> > strong opinions on who should set that metadata on tickets? Reporter?
> >
> > Assignee? One person? A group of people?
> >
> >
> >
> > On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie 
> >
> > wrote:
> >
> >
> > FWIW, I don't care what we go with as long as we can differentiate
> >
> > tickets
> >
> > that are optional for the rel vs. tickets that are blockers and filter
> >
> > the
> >
> > JIRA board on them so people know where they should focus their effort.
> >
> >
> > The rest of it's just paint colors to me.
> >
> >
> > On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever  wrote:
> >
> >
> >
> > Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> >
> > indicate something is targeting a release vs. blocking on inclusion
> >
> > for
> >
> > it.
> >
> > That seems to be a more "project JIRA hackish idiom", and one that's
> >
> > historically been confusing for people. At least with a label it would
> >
> > be
> >
> > clear with a name like "4.0-blocker", and we could then easily filter
> >
> > the
> >
> > JIRA board on it.
> >
> >
> >
> >
> > Now that I better understand Benedict's previous response (see the
> >
> > 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view
> >
> > for
> >
> > now.
> >
> >
> > I certainly missed the difference on how tickets ended up resolved as
> >
> > `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
> >
> > still go into `4.0-alpha` if they satisfied the feature freeze and met
> >
> > someone's itch, while the unresolved `4.0-alpha` tickets were those the
> >
> > community declared as blockers.
> >
> >
> > Putting aside the discussion on what is a blocker, when it is discovered
> >
> > to
> >
> > be a blocker (and vice versa). My confusion stemmed from the fact there
> >
> > was
> >
> > no specific alpha|beta versions for tickets to get resolved into, eg
> >
> > 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal  `.x`
> >
> > nomenclature got changed, but having accurate fix versions was also
> >
> > removed. If we added the specific alpha|beta versions then I wouldn't
> >
> > consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
> >
> > 4.0-beta and 4.0, versions become purely target versions like the `.x`,
> >
> > and
> >
> > no resolved ticket is ever assigned them.
> >
> >
> > The simpler we can make and document this the better. please.
> >
> >
> > regards,
> >
> > Mick
> >
> >
> > ¹)
> >
> >
> >
> >
> >
> https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
> >
> >
> >
> >
> >
>


-- 
http://twitter.com/tjake

Re: Idea: Marking required scope for 4.0 GA vs. optional

[Jake Luciani]

If the performance issue is a regression compared to 3.11 that makes total
sense.
And in the case of ZStd since that's new if its unusable without the
"improvement" then it also makes sense.

I think in both cases though it makes sense to classify these as
performance regression bugs.
I'll take a deeper look at the Improvement tickets, perhaps they all fall
into this category.

Jake





On Tue, Mar 31, 2020 at 6:27 PM Joseph Lynch  wrote:

> On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani  wrote:
> >
> > Can we agree to move the improvements out to 4.0.x?
>
> Generally I've been asked to put performance issues as improvements,
> e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
> on real clusters without that patch, and therefore I wouldn't feel
> great releasing ZstdCompressor in 4.0 without that patch.
>
> I'm fine to start calling all performance issues "bugs" since at least
> in our deployments and I think in many others performance regressions
> are P0 bugs that cost a lot of $$, or we can just keep calling them
> improvements and just tag them with the ~right target fix version.
> Namely 4.0-alpha if the change impacts any public interface in a non
> backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
> or later if it does not require changes to public interfaces.
>
> -Joey
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake

Re: Idea: Marking required scope for 4.0 GA vs. optional

[Jake Luciani]

I see what you mean, I guess my personal line is: does this work worse than
the previous released version?
Seems like that's a yes in this case :)

On Tue, Mar 31, 2020 at 7:35 PM David Capwell  wrote:

> One ticket I wanted to bring up is CASSANDRA-15566, this ticket is not a
> regression but it is a critical bug.  Personally I feel that only
> regression should go into a freeze so I have a hard time justifying that
> ticket right now (all known failure modes have been failing since at least
> 2.1).  I guess the thing that is hard is where do we draw the line?  One
> person's bug is another person's improvement, so it's easy for different
> perspectives to clash on this.
>
>
> On Tue, Mar 31, 2020, 3:27 PM Joseph Lynch  wrote:
>
> > On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani  wrote:
> > >
> > > Can we agree to move the improvements out to 4.0.x?
> >
> > Generally I've been asked to put performance issues as improvements,
> > e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
> > on real clusters without that patch, and therefore I wouldn't feel
> > great releasing ZstdCompressor in 4.0 without that patch.
> >
> > I'm fine to start calling all performance issues "bugs" since at least
> > in our deployments and I think in many others performance regressions
> > are P0 bugs that cost a lot of $$, or we can just keep calling them
> > improvements and just tag them with the ~right target fix version.
> > Namely 4.0-alpha if the change impacts any public interface in a non
> > backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
> > or later if it does not require changes to public interfaces.
> >
> > -Joey
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


-- 
http://twitter.com/tjake

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

[Jake Luciani]

+1 to jitpack

On Fri, Apr 17, 2020 at 8:50 AM Oleksandr Petrov 
wrote:

> Thank you for suggestions, Jeremiah!
>
> I first really liked the idea of jitpack since I thought it clones
> repository and builds stuff locally. However, it seems like they build on
> their machines in docker container. While this is something that could be
> useful in many cases, I think just using snapshots with hash would yield a
> similar result.
>
> Another suggestion from Jeremiah was to use submodules, which could be
> helpful for IDE. We can explore this in future, I just do not have capacity
> at the moment to figure out how to make sure it all builds with ant to make
> it work nicely for developers.
>
> @Nate McCall   I've added some information about
> deployment to readme file [1], and have also posted how to build a snapshot
> [2]. I'll add information about the length of vote with a reference to this
> mailing list discussion for history.
>
> -- Alex
>
>
> [1]
> https://github.com/apache/cassandra-in-jvm-dtest-api/blob/master/README.md
> [2]
>
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/29d055b7cffc66a852505660930c980c185138a1
>
>
> On Fri, Apr 17, 2020 at 1:34 AM J. D. Jordan 
> wrote:
>
> > I was taking with Alex on slack earlier today brainstorming ideas and two
> > that might work are using a git submodule to reference the code by git
> > hash, so no release needed, or using jitpack.io to be able to pull the
> > jar down by git hash without doing a release.
> >
> > Does anyone find either of those options more appealing than 1/2/3?
> >
> > -Jeremiah
> >
> > > On Apr 16, 2020, at 6:14 PM, David Capwell  wrote:
> > >
> > > Not a fan of 2 or 3.  For #2 there is also talk about getting rid of
> the
> > > jars in /lib so that would complicate things.
> > >
> > > I think frequent releases with snapshots per commit is good.  Agree
> with
> > > Nate we should document this so we have something we can always point
> to.
> > >
> > >> On Thu, Apr 16, 2020 at 2:54 PM Nate McCall 
> wrote:
> > >>
> > >> (1) sounds reasonable to me. I'd like us to document the vote cycle
> and
> > >> release train specifics on cassandra.a.o somewhere (developer and
> > releases
> > >> pages maybe?). Nothing exhaustive, just 'we do X with Y'.
> > >>
> > >>
> > >> On Thu, Apr 16, 2020 at 11:03 PM Oleksandr Petrov <
> > >> oleksandr.pet...@gmail.com> wrote:
> > >>
> > >>> I've posted the question on the legal-discussion mailing list, and
> got
> > >> some
> > >>> helpful responses.
> > >>>
> > >>> We can't work around the vote, best we can do is make it shorter (3
> +1
> > >>> votes / 24 hours). We have several options now:
> > >>>
> > >>> 1. Release SNAPSHOT builds prefixed with in-jvm dtest commit SHAs and
> > cut
> > >>> release every week or so (release-train if you wish)
> > >>> 2. Avoid using Apache repository for releases altogether, and just
> push
> > >>> jars to Cassandra repository
> > >>> 3. Make this code "unofficial" (publish and manage outside Apache)
> > >>>
> > >>> I'm not a big fan of (2), since we already tried that with Python and
> > >> Java
> > >>> drivers, also I'm not sure about binaries in git. As regards (3), I'm
> > not
> > >>> sure if this makes it harder for the folks who rely on Apache legal
> > >>> framework for contributions.
> > >>>
> > >>> Unless there are strong opinions against (1), which seems to be a
> > >>> reasonable middle ground, we can do it. Please let me know if you
> also
> > >> have
> > >>> other ideas.
> > >>>
> > >>> Thank you,
> > >>> -- Alex
> > >>>
> > >>> On Wed, Apr 15, 2020 at 10:33 PM Jeremiah D Jordan <
> > >> jerem...@datastax.com>
> > >>> wrote:
> > >>>
> >  I think as long as we don’t publish the artifacts to maven central
> or
> > >>> some
> >  other location that is for “anyone” we do not need a formal release.
> > >> Even
> >  then since the artifact is only meant for use by people developing
> C*
> > >>> that
> >  might be fine.
> > 
> >  If artifacts are only for use by individuals actively participating
> in
> > >>> the
> >  development process, then no formal release is needed.  See the
> > >>> definition
> >  of “release” and “publication” found here:
> > 
> >  http://www.apache.org/legal/release-policy.html#release-definition
> > > DEFINITION OF "RELEASE" <
> >  http://www.apache.org/legal/release-policy.html#release-definition>
> > > Generically, a release is anything that is published beyond the
> group
> >  that owns it. For an Apache project, that means any publication
> > outside
> > >>> the
> >  development community, defined as individuals actively participating
> > in
> >  development or following the dev list.
> > >
> > > More narrowly, an official Apache release is one which has been
> > >>> endorsed
> >  as an "act of the Foundation" by a PMC.
> > >
> > >
> > 
> > > PUBLICATION <
> > >>> http://www.apache.org/legal/release-policy.html#publication
> > >
> 

Re: Calling for release managers (Committers and PMC)

[Jake Luciani]

Happy to lend a hand

On Mon, May 11, 2020 at 3:12 PM Eric Evans 
wrote:

> I can take a turn.
>
> On Fri, May 8, 2020 at 11:10 AM Vinay Chella 
> wrote:
> >
> > I would like to help as well.
> >
> >
> > On Fri, May 8, 2020 at 8:54 AM Chris Lohfink 
> wrote:
> >
> > > I'd like to get involved in this as well.
> > >
> > > On Thu, May 7, 2020 at 2:06 PM Jon Meredith 
> wrote:
> > >
> > > > Sign me up.
> > > >
> > > > On Thu, May 7, 2020 at 12:36 PM Robert Stupp  wrote:
> > > > >
> > > > > I can help
> > > > >
> > > > > --
> > > > > Robert Stupp
> > > > > @snazy
> > > > >
> > > > > > Am 07.05.2020 um 20:29 schrieb Mick Semb Wever :
> > > > > >
> > > > > > The Cassandra release process has had some improvements to
> better in
> > > > > > line with the ASF guidelines: sha256 & sha512 checksums, staged
> > > > > > artefacts in svnpubsub, dep and rpm repositories complete and
> signed
> > > > > > in staging, and separate scripts and manual steps merged
> together.
> > > > > >
> > > > > > The updated documentation for cutting, voting, and publishing a
> > > > > > release is found here:
> > > > > >
> > > >
> https://cassandra.apache.org/doc/latest/development/release_process.html
> > > > > >
> > > > > > I am hoping to get as many Committers* and PMC members
> interested as
> > > > > > possible for cutting a future release.
> > > > > >
> > > > > > Who is interested? How many names can I get :-)
> > > > > >
> > > > > > The more that are interested then the easier it is to take turns
> and
> > > > > > be flexible depending on our own availability each time. I will
> help
> > > > > > out everyone on their first run. Indeed most of my motivation in
> > > > > > getting involved with the release process was to make it all as
> > > simple
> > > > > > and as forgettable as possible, so the role of the role manager
> can
> > > > > > change easily from release to release.
> > > > > >
> > > > > > *When a Committer cuts a release, a PMC member has to perform the
> > > very
> > > > > > last post-vote publish step.
> > > > > >
> > > > > > regards,
> > > > > > Mick
> > > > > >
> > > > > >
> -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> > --
> >
> > Thanks,
> > Vinay Chella
>
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Project governance wiki doc

[Jake Luciani]

+1

On Tue, Jun 16, 2020 at 5:37 PM Benedict Elliott Smith 
wrote:

> +1
>
> On 16/06/2020, 22:23, "Nate McCall"  wrote:
>
> +1 (binding)
>
> On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie 
> wrote:
>
> > Added unratified draft to the wiki here:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > I propose the following:
> >
> >1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >unless there's a lot of feedback on the wiki we didn't get on gdoc
> >2. pmc votes are considered binding
> >3. committer and community votes are considered advisory /
> non-binding
> >
> > Any objections / revisions to the above?
> >
> > Thanks!
> >
> > ~Josh
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake

Re: [VOTE] Project governance wiki doc (take 2)

[Jake Luciani]

+1 (b)

On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie 
wrote:

> A reminder: this vote will close at midnight PST today in roughly 17 hours.
>
>
> On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan 
> wrote:
>
> > +1 non-binding
> >
> > > On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski 
> wrote:
> > >
> > > +1
> > >
> > >> On 22.06.20 20:12, Blake Eggleston wrote:
> > >> +1
> > >>
> >  On Jun 20, 2020, at 8:12 AM, Joshua McKenzie 
> > wrote:
> > >>>
> > >>> Link to doc:
> > >>>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >>>
> > >>> Change since previous cancelled vote:
> > >>> "A simple majority of this electorate becomes the low-watermark for
> > votes
> > >>> in favour necessary to pass a motion, with new PMC members added to
> the
> > >>> calculation."
> > >>>
> > >>> This previously read "super majority". We have lowered the low water
> > mark
> > >>> to "simple majority" to balance strong consensus against risk of
> stall
> > due
> > >>> to low participation.
> > >>>
> > >>>
> > >>>   - Vote will run through 6/24/20
> > >>>   - pmc votes considered binding
> > >>>   - simple majority of binding participants passes the vote
> > >>>   - committer and community votes considered advisory
> > >>>
> > >>> Lastly, I propose we take the count of pmc votes in this thread as
> our
> > >>> initial roll call count for electorate numbers and low watermark
> > >>> calculation on subsequent votes.
> > >>>
> > >>> Thanks again everyone (and specifically Benedict and Jon) for the
> time
> > and
> > >>> collaboration on this.
> > >>>
> > >>> ~Josh
> > >>
> > >> -
> > >> 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
> >
> >
>


-- 
http://twitter.com/tjake

Re: [VOTE] Release Apache Cassandra 4.0-beta1

[Jake Luciani]

+1 (binding)

On Wed, Jul 15, 2020 at 11:50 AM Joshua McKenzie 
wrote:

> +1 (binding)
>
> On Wed, Jul 15, 2020 at 3:33 AM Yuji Ito  wrote:
>
> > +1 (non-binding)
> >
> > Short Jepsen tests with crash injection for map, set, counter, batch, and
> > LWT passed.
> > https://github.com/scalar-labs/scalar-jepsen
> >
> > 2020年7月15日(水) 8:06 Mick Semb Wever :
> >
> > > Proposing the test build of Cassandra 4.0-beta1 for release.
> > >
> > > sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004
> > > Git:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> > > Maven Artifacts:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/
> > >
> > > 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-beta1/
> > >
> > > 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
> > -1s.
> > >
> > > Eventual publishing and announcement of the 4.0-beta1 release will be
> > > coordinated, as described in
> > >
> > >
> >
> https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
> > >
> > > [1]: CHANGES.txt:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative
> > > [2]: NEWS.txt:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
> > >
> >
>


-- 
http://twitter.com/tjake

Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)

[Jake Luciani]

+1

On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña 
wrote:

> +1 (nb)
>
> On Mon, 20 Jul 2020 at 12:58, João Reis  wrote:
>
> > +1 (nb)
> >
> > The drivers smoke test suite looks good:
> >
> >
> >
> https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004
> >
> > Mick Semb Wever  escreveu no dia sábado, 18/07/2020 à(s)
> > 00:27:
> >
> > > Proposing the test build of Cassandra 4.0-beta1 for release.
> > >
> > > sha1: 972da6fcffa87b3a1684362a2bab97db853372d8
> > > Git:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> > > Maven Artifacts:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1211/org/apache/cassandra/cassandra-all/4.0-beta1/
> > >
> > > 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-beta1/
> > >
> > > The vote will be open for 60 hours (longer if needed). I've taken 12
> > hours
> > > off the normal 72 hours and this follows closely after the initial
> > > 4.0-beta1 vote. 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 -1s.
> > >
> > > Eventual publishing and announcement of the 4.0-beta1 release will be
> > > coordinated, as described in
> > >
> > >
> >
> https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
> > >
> > > [1]: CHANGES.txt:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative
> > > [2]: NEWS.txt:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
> > >
> >
>


-- 
http://twitter.com/tjake

Re: Creating a branch for 5.0 …?

[Jake Luciani]

>  Today the community still has in force an explicit vote prohibiting thee
merge of this work.  You must conduct a vote to rescind this decision.

Actually, the vote was defined to hold until beta release:

https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7b9%40%3Cdev.cassandra.apache.org%3E

-Jake


On Thu, Sep 24, 2020 at 11:05 AM Brandon Williams  wrote:

> On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
>  wrote:
> >
> > You do not have the authority to unilaterally overrule the community
> process.  This is a serious breach of your responsibilities as a member of
> the PMC.
>
> Feel free to complain that I'm creating branches we intend to someday,
> perhaps even in 2020, release.
>
> > I have deleted this branch, and will do so again if you repeat this.
>
> This would create some interesting tickets for INFRA, but I won't
> waste their time with you either. Whether either of us has the
> authority to do such on ASF infrastructure is irrelevant, since that
> is the only thing that can be argued here.  The ASL absolutely allows
> people to innovate on their own with the code, so let's just move the
> bits.
>
> Those who wish to innovate,
> https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
> business, PRs accepted. This will be maintained to track trunk on the
> ASF servers.
>
> I guess this is the apache way.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake

Re: Creating a branch for 5.0 …?

[Jake Luciani]

I'm sorry I see no issue with branching 4.0 as it was the thing we voted on
back in 2018.  If you wish to extend the freeze you should call a new vote.

On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith 
wrote:

> Nobody has any problem with an external repository being maintained.  Just
> bear in mind the normal process will need to take place to merge to the ASF
> repository, and that there may be feedback and review requests to address,
> so merge order and diffs will probably change.
>
>
> On 24/09/2020, 16:05, "Brandon Williams"  wrote:
>
> On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
>  wrote:
> >
> > You do not have the authority to unilaterally overrule the community
> process.  This is a serious breach of your responsibilities as a member of
> the PMC.
>
> Feel free to complain that I'm creating branches we intend to someday,
> perhaps even in 2020, release.
>
> > I have deleted this branch, and will do so again if you repeat this.
>
> This would create some interesting tickets for INFRA, but I won't
> waste their time with you either. Whether either of us has the
> authority to do such on ASF infrastructure is irrelevant, since that
> is the only thing that can be argued here.  The ASL absolutely allows
> people to innovate on their own with the code, so let's just move the
> bits.
>
> Those who wish to innovate,
> https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
> business, PRs accepted. This will be maintained to track trunk on the
> ASF servers.
>
> I guess this is the apache way.
>
> -
> 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
>
>

-- 
http://twitter.com/tjake

Re: Creating a branch for 5.0 …?

[Jake Luciani]

> Today the community still has in force an explicit vote prohibiting thee
merge of this work.

You referred to an explicit vote here.  I assume that was the one you were
referring to?  Yes, the community should decide.
Call a vote if you think the community thinks we should continue the freeze
vs continuing to rely on beliefs about the community.

I'm simply pointing out the branching of 4.0 post beta was the plan of last
record.

Jake

On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith 
wrote:

> The community does everything through discussion and consensus.  Does that
> include branching, or not?
>
> If there is no consensus, a vote is held.  Whether or not you consider the
> vote from 2018 still valid, you still need to seek the consent of the
> community for your action today.  Or is that not sacrosanct anymore?
>
>
> On 24/09/2020, 16:22, "Jake Luciani"  wrote:
>
> I'm sorry I see no issue with branching 4.0 as it was the thing we
> voted on
> back in 2018.  If you wish to extend the freeze you should call a new
> vote.
>
> On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Nobody has any problem with an external repository being
> maintained.  Just
> > bear in mind the normal process will need to take place to merge to
> the ASF
> > repository, and that there may be feedback and review requests to
> address,
> > so merge order and diffs will probably change.
> >
> >
> > On 24/09/2020, 16:05, "Brandon Williams"  wrote:
> >
> > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> >  wrote:
> > >
> > > You do not have the authority to unilaterally overrule the
> community
> > process.  This is a serious breach of your responsibilities as a
> member of
> > the PMC.
> >
> > Feel free to complain that I'm creating branches we intend to
> someday,
> > perhaps even in 2020, release.
> >
> > > I have deleted this branch, and will do so again if you repeat
> this.
> >
> > This would create some interesting tickets for INFRA, but I won't
> > waste their time with you either. Whether either of us has the
> > authority to do such on ASF infrastructure is irrelevant, since
> that
> > is the only thing that can be argued here.  The ASL absolutely
> allows
> > people to innovate on their own with the code, so let's just
> move the
> > bits.
> >
> > Those who wish to innovate,
> > https://github.com/driftx/cassandra/tree/cassandra-5.0 is now
> open for
> > business, PRs accepted. This will be maintained to track trunk
> on the
> > ASF servers.
> >
> > I guess this is the apache way.
> >
> >
>  -
> > 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
> >
> >
>
> --
> http://twitter.com/tjake
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake

Re: Creating a branch for 5.0 …?

[Jake Luciani]

The vote was to unfreeze new changes at beta, so logically that means
non-bugfix work goes into trunk.

Jordan, thanks.   That is a more recent vote so thanks.  That being said,
under that line Benedict comments this needs to be discussed.
So how about we just have a Vote on branching cassandra-4.0 and the issue
will be decided?

Jake




On Thu, Sep 24, 2020 at 11:53 AM Benedict Elliott Smith 
wrote:

> I'm not sure what you are referring to here, that vote said nothing about
> branching at beta.
>
> The most recent vote on the topic anyway was for the Release Lifecycle
> process, which stipulates branching at GA.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> We can vote to modify this document, or to make an exception, but I am
> aware of no other vote stipulating anything about the point at which we
> branch.
>
>
> On 24/09/2020, 16:49, "Jake Luciani"  wrote:
>
> > Today the community still has in force an explicit vote prohibiting
> thee
> merge of this work.
>
> You referred to an explicit vote here.  I assume that was the one you
> were
> referring to?  Yes, the community should decide.
> Call a vote if you think the community thinks we should continue the
> freeze
> vs continuing to rely on beliefs about the community.
>
> I'm simply pointing out the branching of 4.0 post beta was the plan of
> last
> record.
>
> Jake
>
> On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > The community does everything through discussion and consensus.
> Does that
> > include branching, or not?
> >
> > If there is no consensus, a vote is held.  Whether or not you
> consider the
> > vote from 2018 still valid, you still need to seek the consent of the
> > community for your action today.  Or is that not sacrosanct anymore?
> >
> >
> > On 24/09/2020, 16:22, "Jake Luciani"  wrote:
> >
> > I'm sorry I see no issue with branching 4.0 as it was the thing
> we
> > voted on
> > back in 2018.  If you wish to extend the freeze you should call
> a new
> > vote.
> >
> > On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith <
> > bened...@apache.org>
> > wrote:
> >
> > > Nobody has any problem with an external repository being
> > maintained.  Just
> > > bear in mind the normal process will need to take place to
> merge to
> > the ASF
> > > repository, and that there may be feedback and review requests
> to
> > address,
> > > so merge order and diffs will probably change.
> > >
> > >
> > > On 24/09/2020, 16:05, "Brandon Williams" 
> wrote:
> > >
> > > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> > >  wrote:
> > > >
> > > > You do not have the authority to unilaterally overrule
> the
> > community
> > > process.  This is a serious breach of your responsibilities as
> a
> > member of
> > > the PMC.
> > >
> > > Feel free to complain that I'm creating branches we intend
> to
> > someday,
> > > perhaps even in 2020, release.
> > >
> > > > I have deleted this branch, and will do so again if you
> repeat
> > this.
> > >
> > > This would create some interesting tickets for INFRA, but
> I won't
> > > waste their time with you either. Whether either of us has
> the
> > > authority to do such on ASF infrastructure is irrelevant,
> since
> > that
> > > is the only thing that can be argued here.  The ASL
> absolutely
> > allows
> > > people to innovate on their own with the code, so let's
> just
> > move the
> > > bits.
> > >
> > > Those who wish to innovate,
> > > https://github.com/driftx/cassandra/tree/cassandra-5.0 is
> now
> > open for
> > > business, PRs accepted. This will be maintained to track
> trunk
> > on the
> > > ASF servers.
> > >
> > > I guess this is the apache way.
> > >
> > 

Re: March 2015 QA retrospective

[Jake Luciani]

Here is my response.

<https://issues.apache.org/jira/browse/CASSANDRA-8332> T Jake Luciani Null
pointer after droping keyspace Add/drop keyspace not tested under load,
with server logs checked for errors

To detect this we would need a test to write to a table,  wait for
compaction to start then drop the table before the compaction finished
and check the log for an exception
(there was no impact to the system other than the error)




On Thu, Apr 9, 2015 at 4:05 PM, Tyler Hobbs  wrote:
> Here are my responses for my tickets:
>
> CASSANDRA-7910 - wildcard prepared statements are incorrect after a column
> is added to the table
>
> As part of the ticket, I added general dtests for prepared statement
> invalidation after ALTER TABLE statements:
> https://github.com/riptano/cassandra-dtest/blob/18cd4adaba65a9f424b5b9f52f4bf510b6c7e47f/cql_tests.py#L5170-L5204.
> In general, though, the dtests don't have great coverage on prepared
> statements.  We could add an abstraction layer over query execution to use
> prepared vs unprepared statements with an environment variable.
>
> CASSANDRA-8264 - Problems with multicolumn relations and COMPACT STORAGE
>
> I'm not sure of the best way to catch missing coverage for table settings
> like COMPACT STORAGE is.  Theoretically a careful inspection of code/branch
> coverage would probably reveal this.  Of course, we could also ensure all
> (applicable) tests cover both COMPACT and non-COMPACT, but other table
> settings like the compaction strategy and caching could also affect some
> tests.  I suppose COMPACT STORAGE is the most likely to make a difference,
> so perhaps we should focus on covering that first and postpone coverage for
> the other attributes until we have a more general solution?
>
> CASSANDRA-8286 - Regression in ORDER BY
>
> The dtests did catch this.  We did not ship the bug in 2.0, but
> unfortunately, it did make it into the 2.1.2 release despite the failing
> test. (The test failed shortly before the release, which had its vote over
> the weekend and thus missed test-engineering input.) After the 2.1.2
> release, we decided to make changes to the release process to prevent that:
> ensure a full test run completes before voting, and require sign-off from a
> test engineer before releasing.
>
> CASSANDRA-8288 - cqlsh describe needs to show 'sstable_compression'
>
> We do have round-trip tests for DESCRIBE in the python driver (
> https://github.com/datastax/python-driver/blob/c381fa0f04dbeb9ac389fa017bac8d9cc2ded0be/tests/integration/standard/test_metadata.py#L41),
> but they don't cover every config option permutation.  Although we now have
> coverage for this particular case, adding a suite of tests for this should
> be pretty straightforward, so I'll open a ticket for that.
>
> CASSANDRA-8302 - Filtering for CONTAINS (KEY) on frozen collection
> clustering columns within a partition does not work
>
> This bug didn't ship, but wasn't caught by a failing test.  I'm not sure
> how we could spot the lack of coverage on this -- even branch coverage
> analysis wouldn't show this.  Perhaps taking the time to manually create a
> test-coverage matrix (and post it in jira) when developing the feature is
> the best approach?  The matrix is too large to simply cover mentally, it
> seems.
>
> CASSANDRA-8408 - limit appears to replace page size under certain conditions
>
> This was discovered while more thorough tests for paging were being written
> (by the reporter).  Obviously, these should have existed when the feature
> was written, but part of the problem was that it required driver changes to
> test and we weren't using the native protocol python driver for dtests
> yet.  We still have a bit of a problem with testing new protocol features,
> but we typically add python driver support for the features while
> developing them so that we can at least run relevant dtests locally.  Once
> https://github.com/riptano/cassandra-dtest/issues/188 is complete, it
> should be easier to write dtests against native protocol changes/features.
>
> CASSANDRA-8410 - Select with many IN values on clustering columns can
> result in a StackOverflowError
>
> Agreed, we need boundary tests for large values of IN clauses, large
> inserts/update/deletes/batches (number of query params, number of partition
> keys, and number of clustering keys)
>
> CASSANDRA-8451 - NPE when writetime() or ttl() are nested inside function
> call
>
> I did add a regression dtest for this.  We do have tests for composition of
> functions, but writetime() and ttl() are special functions and didn't have
> the specific test coverage they deserved.  (I did add dtest coverage as
> part of the ticket.)
>
> 

[VOTE] Release Apache Cassandra 2.1.5

[Jake Luciani]

I propose the following artifacts for release as 2.1.5.

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 2.1.5

[Jake Luciani]

6 binding +1
1 non-binding +1
0 -1

The vote passes. I will publish the artifacts and announce shortly

-- Forwarded message --
From: Sylvain Lebresne 
Date: Tue, Apr 28, 2015 at 4:53 AM
Subject: Re: [VOTE] Release Apache Cassandra 2.1.5
To: "dev@cassandra.apache.org" 


+1

On Mon, Apr 27, 2015 at 10:29 PM, Brandon Williams  wrote:

> +1
>
> On Mon, Apr 27, 2015 at 9:46 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.1.5.
> >
> > sha1: 3c0a337ebc90b0d99349d0aa152c92b5b3494d8c
> > Git:
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.5-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1053/org/apache/cassandra/apache-cassandra/2.1.5/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1053/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/Coam8e (CHANGES.txt)
> > [2]: http://goo.gl/ClUkPI (NEWS.txt)
> >
>


-- 
http://twitter.com/tjake

Cassandra fixVersion JIRA change

[Jake Luciani]

Hi,


Currently in JIRA we mark an issue with a specific fixVersion upfront.
When doing releases this causes issues because once the release is cut
we need to bulk move all the unresolved issues for that release to the
next version.  This bulk move operation replaces the fixVersion field
and wipes out any other fixVersions an issue happened to have. like
2.1.5 and 2.0.15.

So I propose (actually this is Sylvain's idea) we create series
placeholder versions like 2.0.x 2.1.x 3.x which we use to mark the
series of a JIRA upfront.  On commit we then set the specific version
the ticket was committed for.

I've started migrating our series over to this already.  Please try to
remember to do this.

-Jake

Re: Cassandra fixVersion JIRA change

[Jake Luciani]

Perhaps we update the wiki? http://wiki.apache.org/cassandra/HowToContribute

On Wed, Apr 29, 2015 at 1:14 PM, Ariel Weisberg
 wrote:
> Hi,
>
> How are we going to communicate this convention to people that are being
> onboarded to Cassandra development?
>
> Ariel
>
> On Wed, Apr 29, 2015 at 12:56 PM, Jake Luciani  wrote:
>
>> Hi,
>>
>>
>> Currently in JIRA we mark an issue with a specific fixVersion upfront.
>> When doing releases this causes issues because once the release is cut
>> we need to bulk move all the unresolved issues for that release to the
>> next version.  This bulk move operation replaces the fixVersion field
>> and wipes out any other fixVersions an issue happened to have. like
>> 2.1.5 and 2.0.15.
>>
>> So I propose (actually this is Sylvain's idea) we create series
>> placeholder versions like 2.0.x 2.1.x 3.x which we use to mark the
>> series of a JIRA upfront.  On commit we then set the specific version
>> the ticket was committed for.
>>
>> I've started migrating our series over to this already.  Please try to
>> remember to do this.
>>
>> -Jake
>>



-- 
http://twitter.com/tjake

[RELEASE] Apache Cassandra 2.1.5 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/xjzhhE (CHANGES.txt)
[2]: http://goo.gl/skvzNS (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: Staging Branches

[Jake Luciani]

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

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

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



-- 
http://twitter.com/tjake

Re: Staging Branches

[Jake Luciani]

ah missed that. I still think this is overly complicated. We still
need to run CI before we release. So what does this buy us?

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



-- 
http://twitter.com/tjake

Re: Staging Branches

[Jake Luciani]

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

In this situation, if there was an untested follow on commit wouldn't
you need to force push?

On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith
 wrote:
>>
>> If we do it, we'll end up in weird situations which will be annoying for
>> everyone
>
>
> Such as? I'm not disputing, but if we're to assess the relative
> strengths/weaknesses, we need to have specifics to discuss.
>
> If we do go with this suggestion, we will most likely want to enable a
> shared git rerere cache, so that rebasing is not painful when there are
> future commits.
>
> If instead we go with "repairing" commits, we cannot have a "queue" of
> things to merge up to. Say you have a string of commits waiting for
> approval C1 to C4; you made C1, and it broke something. You introduce C5 to
> fix it, but the tests are still broken. Did you not really fix it? Or
> perhaps one of C2 to C4 are to blame, but which? And have you accidentally
> broken *them* with your commit? Who knows. Either way, we definitely cannot
> fast forward. At the very best we can hope that the new merge did not
> conflict or mess up the other people's C2 to C4 commits, and they have to
> now merge on top. But what if another merge comes in, C6, in the meantime;
> and C2 really did also break the tests in some way; how do we determine C2
> was to blame, and not C6, or C3 or C4? What do the committers for each of
> these do? We end up in a lengthy tussle, and aren't able to commit any of
> these to the mainline until all of them are resolved. Really we have to
> prevent any merges to the staging repository until the mistakes are fixed.
> Since our races in these scenario are the length of time taken for cassci
> to vet them, these problems are much more likely than current race to
> commit.
>
> In the scheme I propose, in this scenario, the person who broke the build
> rebases everyone's branches to his now fixed commit, and the next broken
> commit gets blamed, and all other commits being merged in on top can go in
> smoothly. The only pain point I can think of is the multi-branch rebase,
> but this is solved by git rerere.
>
> I agree running tests is painful, but at least for the build, this should
>> be the responsibility of the committer to build before merging
>
>
> Why make the distinction if we're going to have staging commits? It's a bit
> of a waste of time to run three ant real-clean && ant tasks, and increases
> the race window for merging (which is painful whether or not involves a
> rebase), and it is not a *typical* occurrence ("alarming" is subjective)
>
> On Thu, May 7, 2015 at 2:12 PM, Sylvain Lebresne 
> wrote:
>
>> > If one of them breaks, we go and edit the _staging branch in place to
>> correct
>> > the problem, and let CI run again.
>>
>> I would strongly advise against *in place* edits. If we do it, we'll end up
>> in
>> weird situations which will be annoying for everyone. Editing commits that
>> have
>> been shared is almost always a bad idea and that's especially true for
>> branch
>> that will have some amount of concurrency like those staging branches.
>>
>> Even if such problems are rare, better to avoid them in the first place by
>> simply
>> commit new "fixup" commits as we currently do. Granted this give you a
>> slightly
>> less clean history but to the best of my knowledge, this hasn't been a pain
>> point so far.
>>
>> > wait for CI; all clear
>> >
>> > git checkout cassandra-2.0; git merge cassandra-2.0_staging
>> > git checkout cassandra-2.1; git merge cassandra-2.1_staging
>> > git checkout trunk; git merge trunk_staging
>> >
>> > This does introduce some extra steps to the merge process
>>
>> If we do this, we should really automate that last part (have the CI
>> environment merge the staging branch to the non-staging ones on success).
>>
>> > It seems if we want an "always releasable" set of branches, we need
>> something
>> > along these lines.
>>
>> Agreed as far as having staging branches vetoed by CI goes. Less sure about
>> the edit-commit-in-place part as said above.
>>
>> > I certainly break tests by mistake, or the build itself, with alarming
>> regularity.
>>
>> I agree running tests is painful, but at least for the build, this should
>> be
>> the responsibility of the committer to build before merging. We all forget
>> it from
>> times to times and that's ok, but it's not ok if it's "alarmingly regular".
>>
>> --
>> Sylvain
>>



-- 
http://twitter.com/tjake

Re: Staging Branches

[Jake Luciani]

You then fetch and repair
your local version and try again.

This breaks your model of applying every commit ref by ref.

I'm all for trying to avoid extra work/stability but we already have
added a layer of testing every change before commit.  I'm not going to
accept we need to also add a layer of testing before every merge.




On Thu, May 7, 2015 at 10:36 AM, Benedict Elliott Smith
 wrote:
>>
>> wouldn't you need to force push?
>
>
> git push --force-with-lease
>
> This works essentially like CAS; if the remote repositories are not the
> same as the one you have modified, it will fail. You then fetch and repair
> your local version and try again.
>
> So what does this buy us?
>
>
> This buys us a clean development process. We bought into "always
> releasable". It's already a tall order; if we start weakening the
> constraints before we even get started, I am unconvinced we will
> successfully deliver. A monthly release cycle requires *strict* processes,
> not *almost* strict, or strict*ish*.
>
> Something that could also help make a more streamlined process: if actual
> commits were constructed on development branches ready for commit, with a
> proper commit message and CHANGES.txt updated. Even more ideally: with git
> rerere data for merging up to each of the branches. If we had that, and
> each of the branches had been tested in CI, we would be much closer than we
> are currently, as the risk-at-commit is minimized.
>
> On Thu, May 7, 2015 at 2:48 PM, Jake Luciani  wrote:
>
>> git rebase -i trunk_staging 
>> fix the problem
>> git rebase --continue
>>
>> In this situation, if there was an untested follow on commit wouldn't
>> you need to force push?
>>
>> On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith
>>  wrote:
>> >>
>> >> If we do it, we'll end up in weird situations which will be annoying for
>> >> everyone
>> >
>> >
>> > Such as? I'm not disputing, but if we're to assess the relative
>> > strengths/weaknesses, we need to have specifics to discuss.
>> >
>> > If we do go with this suggestion, we will most likely want to enable a
>> > shared git rerere cache, so that rebasing is not painful when there are
>> > future commits.
>> >
>> > If instead we go with "repairing" commits, we cannot have a "queue" of
>> > things to merge up to. Say you have a string of commits waiting for
>> > approval C1 to C4; you made C1, and it broke something. You introduce C5
>> to
>> > fix it, but the tests are still broken. Did you not really fix it? Or
>> > perhaps one of C2 to C4 are to blame, but which? And have you
>> accidentally
>> > broken *them* with your commit? Who knows. Either way, we definitely
>> cannot
>> > fast forward. At the very best we can hope that the new merge did not
>> > conflict or mess up the other people's C2 to C4 commits, and they have to
>> > now merge on top. But what if another merge comes in, C6, in the
>> meantime;
>> > and C2 really did also break the tests in some way; how do we determine
>> C2
>> > was to blame, and not C6, or C3 or C4? What do the committers for each of
>> > these do? We end up in a lengthy tussle, and aren't able to commit any of
>> > these to the mainline until all of them are resolved. Really we have to
>> > prevent any merges to the staging repository until the mistakes are
>> fixed.
>> > Since our races in these scenario are the length of time taken for cassci
>> > to vet them, these problems are much more likely than current race to
>> > commit.
>> >
>> > In the scheme I propose, in this scenario, the person who broke the build
>> > rebases everyone's branches to his now fixed commit, and the next broken
>> > commit gets blamed, and all other commits being merged in on top can go
>> in
>> > smoothly. The only pain point I can think of is the multi-branch rebase,
>> > but this is solved by git rerere.
>> >
>> > I agree running tests is painful, but at least for the build, this should
>> >> be the responsibility of the committer to build before merging
>> >
>> >
>> > Why make the distinction if we're going to have staging commits? It's a
>> bit
>> > of a waste of time to run three ant real-clean && ant tasks, and
>> increases
>> > the race window for merging (which is painful whether or not involves a
>> > rebase), and it is not a *typical* occur

Re: Staging Branches

[Jake Luciani]

Ok let's focus then on the idea that trunk is releasable.  Releasable
to me doesn't mean it can't contain a bad merge.

It means it doesn't contain some untested and unstable feature.  We
can always "release from trunk" and we still have a release process.

The idea that trunk must contain. a first time it hits the branch,
releasable code is way overboard

On Thu, May 7, 2015 at 10:50 AM, Benedict Elliott Smith
 wrote:
>>
>> This breaks your model of applying every commit ref by ref.
>
>
> How? The rebase only affects commits after the "real" branch, so it still
> cleanly fast forwards?
>
> Merging is *hard*. Especially 2.1 -> 3.0, with many breaking API changes
> (this is before 8099, which is going to make a *world* of hurt, and will
> stick around for a year). It is *very* easy to break things, with even the
> utmost care.
>
> On Thu, May 7, 2015 at 3:46 PM, Jake Luciani  wrote:
>
>> You then fetch and repair
>> your local version and try again.
>>
>> This breaks your model of applying every commit ref by ref.
>>
>> I'm all for trying to avoid extra work/stability but we already have
>> added a layer of testing every change before commit.  I'm not going to
>> accept we need to also add a layer of testing before every merge.
>>
>>
>>
>>
>> On Thu, May 7, 2015 at 10:36 AM, Benedict Elliott Smith
>>  wrote:
>> >>
>> >> wouldn't you need to force push?
>> >
>> >
>> > git push --force-with-lease
>> >
>> > This works essentially like CAS; if the remote repositories are not the
>> > same as the one you have modified, it will fail. You then fetch and
>> repair
>> > your local version and try again.
>> >
>> > So what does this buy us?
>> >
>> >
>> > This buys us a clean development process. We bought into "always
>> > releasable". It's already a tall order; if we start weakening the
>> > constraints before we even get started, I am unconvinced we will
>> > successfully deliver. A monthly release cycle requires *strict*
>> processes,
>> > not *almost* strict, or strict*ish*.
>> >
>> > Something that could also help make a more streamlined process: if actual
>> > commits were constructed on development branches ready for commit, with a
>> > proper commit message and CHANGES.txt updated. Even more ideally: with
>> git
>> > rerere data for merging up to each of the branches. If we had that, and
>> > each of the branches had been tested in CI, we would be much closer than
>> we
>> > are currently, as the risk-at-commit is minimized.
>> >
>> > On Thu, May 7, 2015 at 2:48 PM, Jake Luciani  wrote:
>> >
>> >> git rebase -i trunk_staging 
>> >> fix the problem
>> >> git rebase --continue
>> >>
>> >> In this situation, if there was an untested follow on commit wouldn't
>> >> you need to force push?
>> >>
>> >> On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith
>> >>  wrote:
>> >> >>
>> >> >> If we do it, we'll end up in weird situations which will be annoying
>> for
>> >> >> everyone
>> >> >
>> >> >
>> >> > Such as? I'm not disputing, but if we're to assess the relative
>> >> > strengths/weaknesses, we need to have specifics to discuss.
>> >> >
>> >> > If we do go with this suggestion, we will most likely want to enable a
>> >> > shared git rerere cache, so that rebasing is not painful when there
>> are
>> >> > future commits.
>> >> >
>> >> > If instead we go with "repairing" commits, we cannot have a "queue" of
>> >> > things to merge up to. Say you have a string of commits waiting for
>> >> > approval C1 to C4; you made C1, and it broke something. You introduce
>> C5
>> >> to
>> >> > fix it, but the tests are still broken. Did you not really fix it? Or
>> >> > perhaps one of C2 to C4 are to blame, but which? And have you
>> >> accidentally
>> >> > broken *them* with your commit? Who knows. Either way, we definitely
>> >> cannot
>> >> > fast forward. At the very best we can hope that the new merge did not
>> >> > conflict or mess up the other people's C2 to C4 commits, and they
>> have to
>> >> > now merge o

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

[Jake Luciani]

Overall +1.

I'm -0 on EOL of 2.0 once 2.2 is release. I'd rather keep 2.0 around
till 3.0 comes out.

As for 2.2 blockers, we might want to vet and make sure everything we
need in protocol v4 is finished before we release 2.2
https://issues.apache.org/jira/browse/CASSANDRA-8043


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



-- 
http://twitter.com/tjake

[VOTE] Release Apache Cassandra 2.0.15

[Jake Luciani]

I propose the following artifacts for release as 2.0.15.

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

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

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

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

Cassandra 2.2 and 3.0 dev notes

[Jake Luciani]

I've added the cassandra-2.2 branch. This means:

When you commit a change to 2.0 you must merge:


*cassandra-2.0 -> cassandra-2.1 -> cassandra-2.2 -> trunk*
or for 2.1 change


*cassandra-2.1 -> cassandra-2.2 -> trunk*

I've also closed #8168 so trunk will not compile with java 7.  This means
you should either switch to java 8 now or better add support for switching
between java versions on the fly.

For Linux you can add the following to your profile (assuming you installed
the oracle java package):

alias use-java7="sudo update-java-alternatives -s java-7-oracle"
alias use-java8="sudo update-java-alternatives -s java-8-oracle"

For OSX see
http://andrew-jones.com/blog/managing-multiple-versions-of-java-on-os-x/

For Windows see https://coderwall.com/p/gbek2g/java-6-and-java-7-on-windows

Happy coding.

[VOTE] Release Apache Cassandra 2.2.0-beta1

[Jake Luciani]

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

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

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

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

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

[RELEASE] Apache Cassandra 2.0.15 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/G050Kn (CHANGES.txt)
[2]: http://goo.gl/ZyvMnR (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE RESULT] Release Apache Cassandra 2.2.0-beta1

[Jake Luciani]

With 5 binding +1, 2 non-binding +1 and no -1 votes the release passes.

I'll publish the artifacts

-- Forwarded message --
From: Josh McKenzie 
Date: Mon, May 18, 2015 at 11:53 AM
Subject: Re: [VOTE] Release Apache Cassandra 2.2.0-beta1
To: dev@cassandra.apache.org


+1

On Mon, May 18, 2015 at 9:59 AM, Sylvain Lebresne 
wrote:

> +1
>
> On Mon, May 18, 2015 at 4:10 PM, Jonathan Ellis  wrote:
>
> > +1
> >
> > On Sun, May 17, 2015 at 9:34 PM, Jake Luciani  wrote:
> >
> > > I propose the following artifacts for release as 2.2.0-beta1.
> > >
> > > sha1: 1735249ebfdbf139ca95507d591a324dfe81da33
> > > Git:
> > >
> > >
> >
>
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-beta1-tentative
> > > Artifacts:
> > >
> > >
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1057/org/apache/cassandra/apache-cassandra/2.2.0-beta1/
> > > Staging repository:
> > >
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1057/
> > >
> > > The artifacts as well as the debian package are also available here:
> > > http://people.apache.org/~jake
> > >
> > > Since this is beta, the vote will be open for 24 hours.
> > >
> > > [1]: http://goo.gl/YsRffc (CHANGES.txt)
> > > [2]: http://goo.gl/jFb87y (NEWS.txt)
> > >
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>



--
Joshua McKenzie
DataStax -- The Apache Cassandra Company

[BETA-RELEASE] Apache Cassandra 2.2.0-beta1 released

[Jake Luciani]

The Cassandra team is pleased to announce the release of Apache Cassandra
version 2.2.0-beta1.

This release is *not* production ready. We are looking for testing of
existing and new features. If you encounter any problem please let us know
[1].

Cassandra 2.2 features major enhancements such as:

* Resume-able Bootstrapping
* JSON Support [4]
* User Defined Functions [5]
* Server-side Aggregation [6]
* Role based access control

Read [2] and [3] to learn about all the new features.

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

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

Enjoy!

-The Cassandra Team

[1]: https://issues.apache.org/jira/browse/CASSANDRA
[2]: http://goo.gl/MyOEib (NEWS.txt)
[3]: http://goo.gl/MBJd1S (CHANGES.txt)
[4]: http://cassandra.apache.org/doc/cql3/CQL-2.2.html#json
[5]: http://cassandra.apache.org/doc/cql3/CQL-2.2.html#udfs
[6]: http://cassandra.apache.org/doc/cql3/CQL-2.2.html#udas

[VOTE] Release Apache Cassandra 2.1.6

[Jake Luciani]

I propose the following artifacts for release as 2.1.6.

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

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

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

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

[VOTE] Release Apache Cassandra 2.2.0-rc1

[Jake Luciani]

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

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 2.2.0-rc1

[Jake Luciani]

With 6 Binding +1 and 2 non-binding +1 the vote passes. I will publish today


-- Forwarded message --
From: Alan Boudreault 
Date: Sun, Jun 7, 2015 at 5:28 PM
Subject: Re: [VOTE] Release Apache Cassandra 2.2.0-rc1
To: dev@cassandra.apache.org


+1 for this rc1 release. The last run of the DurationTest and the long
duration CommitLogStressTest were all good.

Some notes about the 2 tickets mentioned by Ryan:

* We need to do more test about the core dump we got.
* The stress regression is due to the java-driver. This will also be
investigated this week with the driver team.


On Fri, Jun 5, 2015 at 2:17 PM, Ryan McGuire  wrote:

> Two tickets that warrant attention:
>
> https://issues.apache.org/jira/browse/CASSANDRA-9557
> https://issues.apache.org/jira/browse/CASSANDRA-9558
>
> On Fri, Jun 5, 2015 at 2:15 PM, Jason Brown  wrote:
>
> > +1
> > On Friday, June 5, 2015, Sylvain Lebresne  wrote:
> >
> > > +1
> > >
> > > On Fri, Jun 5, 2015 at 5:41 PM, Brandon Williams  > > > wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, Jun 5, 2015 at 10:27 AM, Jake Luciani  > > > wrote:
> > > >
> > > > > I propose the following artifacts for release as 2.2.0-rc1.
> > > > >
> > > > > sha1: b0ae285bdc7377a64ed92f01c67ff46b40ecaac0
> > > > > Git:
> > > > >
> > > > >
> > > >
> > >
> >
>
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-rc1-tentative
> > > > > Artifacts:
> > > > >
> > > > >
> > > >
> > >
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1059/org/apache/cassandra/apache-cassandra/2.2.0-rc1/
> > > > > Staging repository:
> > > > >
> > > >
> > >
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1059/
> > > > >
> > > > > The artifacts as well as the debian package are also available
> here:
> > > > > http://people.apache.org/~jake
> > > > >
> > > > > The vote will be open for 72 hours (longer if needed).
> > > > >
> > > > > [1]: http://goo.gl/B6LLNm (CHANGES.txt)
> > > > > [2]: http://goo.gl/mr638q (NEWS.txt)
> > > > >
> > > >
> > >
> >
>



--

Alan Boudreault
Software Engineer in Test | alan.boudrea...@datastax.com

[VOTE RESULT] Release Apache Cassandra 2.1.6

[Jake Luciani]

With 6 binding +1 and no -1 the vote passes. I will publish today.

-- Forwarded message --
From: Sylvain Lebresne 
Date: Fri, Jun 5, 2015 at 12:17 PM
Subject: Re: [VOTE] Release Apache Cassandra 2.1.6
To: "dev@cassandra.apache.org" , Gary Dusbabek <
gdusba...@gmail.com>


+1

On Fri, Jun 5, 2015 at 5:32 PM, Gary Dusbabek  wrote:

> +1
>
> On Fri, Jun 5, 2015 at 10:05 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.1.6.
> >
> > sha1: e469f32be180a1e493227111649d067a35201e97
> > Git:
> >
> >
>
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.6-tentative
> > Artifacts:
> >
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1058/org/apache/cassandra/apache-cassandra/2.1.6/
> > Staging repository:
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1058/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/lTrkx1 (CHANGES.txt)
> > [2]: http://goo.gl/93P7VA (NEWS.txt)
> >
>

[RELEASE] Apache Cassandra 2.1.6 released

[Jake Luciani]

The Cassandra team is pleased to announce the release of Apache Cassandra
version 2.1.6.  We are now calling 2.1 series stable and suitable for
production.

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/8aR9L2 (CHANGES.txt)
[2]: http://goo.gl/dstU4D (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RELEASE] Apache Cassandra 2.2.0-rc1 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/pBjybx (CHANGES.txt)
[2]: http://goo.gl/E1RiHd (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 2.0.16

[Jake Luciani]

I propose the following artifacts for release as 2.0.16.

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

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

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

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

[VOTE] Release Apache Cassandra 2.1.7

[Jake Luciani]

I propose the following artifacts for release as 2.1.7.

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 2.0.16

[Jake Luciani]

With 7 binding +1, 1 non-binding +1 and no -1 the vote passes. I'll publish
artifacts

-- Forwarded message --
From: Michael Shuler 
Date: Mon, Jun 22, 2015 at 11:13 AM
Subject: Re: [VOTE] Release Apache Cassandra 2.0.16
To: dev@cassandra.apache.org


+1 non-binding


On 06/19/2015 07:56 AM, Jake Luciani wrote:

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

[VOTE RESULT] Release Apache Cassandra 2.1.7

[Jake Luciani]

With 8 Binding +1, 1 non-binding +1, no -1, and one extra vote from Sylvain
the vote definitely passed.   I'll publish the artifacts

-- Forwarded message --
From: Michael Shuler 
Date: Mon, Jun 22, 2015 at 11:13 AM
Subject: Re: [VOTE] Release Apache Cassandra 2.1.7
To: dev@cassandra.apache.org


+1 non-binding


On 06/19/2015 07:59 AM, Jake Luciani wrote:

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



-- 
http://twitter.com/tjake

[RELEASE] Apache Cassandra 2.0.16 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/XtSTxA (CHANGES.txt)
[2]: http://goo.gl/9NHMdH (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RELEASE] Apache Cassandra 2.1.7 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/0AxLpL (CHANGES.txt)
[2]: http://goo.gl/kkEDSi (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 2.1.8

[Jake Luciani]

I propose the following artifacts for release as 2.1.8.

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

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

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

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

[VOTE] Release Apache Cassandra 2.2.0-rc2

[Jake Luciani]

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

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

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

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

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

Re: Discussion: reviewing larger tickets

[Jake Luciani]

putting comments inline on a branch for the initial author to inspect

I agree and I think we can support this by using github pull requests for
review.

Pull requests live forever even if the source branch is removed. See
https://github.com/apache/cassandra/pull/4
They also allow for comments to be updated over time as new fixes are
pushed to the branch.

Once review is done we can just close them without committing and just
commit the usual way

Linking to the PR in JIRA for reference.


On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie  wrote:

> As some of you might have noticed, Tyler and I tossed around a couple of
> thoughts yesterday regarding the best way to perform larger reviews on
> JIRA.
>
> I've been leaning towards the approach Benedict's been taking lately
> w/putting comments inline on a branch for the initial author to inspect as
> that provides immediate locality for a reviewer to write down their
> thoughts and the same for the initial developer to ingest them. One
> downside to that approach is that the extra barrier to entry makes it more
> of a 1-on-1 conversation rather than an open discussion via JIRA comments.
> Also, if one deletes branches from github we then lose our discussion
> history on the review process which is a big problem for digging into why
> certain decisions were made or revised during the process.
>
> On the competing side, monster comments like this
> <
> https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221
> >
> (which
> is one of multiple to come) are burdensome to create and map into a JIRA
> comment and, in my experience, also a burden to map back into the code-base
> as a developer. Details are lost in translation; I'm comfortable labeling
> this a sub-optimal method of communication.
>
> So what to do?
>
> --
> Joshua McKenzie
>



-- 
http://twitter.com/tjake

Re: [VOTE] Release Apache Cassandra 2.2.0-rc2

[Jake Luciani]

We've discussed on https://issues.apache.org/jira/browse/CASSANDRA-9749

This is technically a general issue with how we deal with CL errors and it
should be fixed in 2.1 branch as well as with new compressed CL in 2.2 so
it shouldn't block this vote.



On Wed, Jul 8, 2015 at 10:50 AM, Blake Eggleston <
blake.eggles...@datastax.com> wrote:

> -1. I've found some problems with 2.2 commit log replay in
> https://issues.apache.org/jira/browse/CASSANDRA-9749 that could lose data
> in some situations.
>
>
> On Wed, Jul 8, 2015 at 7:19 AM Michael Shuler 
> wrote:
>
> > +1 non-binding
> >
> > On 07/06/2015 01:47 PM, Jake Luciani wrote:
> > > I propose the following artifacts for release as 2.2.0-rc2.
> > >
> > > sha1: ebc50d783505854f04f183297ad3009b9095b07e
> > > Git:
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-rc2-tentative
> > > Artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1065/org/apache/cassandra/apache-cassandra/2.2.0-rc2/
> > > Staging repository:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1065/
> > >
> > > The artifacts as well as the debian package are also available here:
> > > http://people.apache.org/~jake
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: http://goo.gl/C1QdHh (CHANGES.txt)
> > > [2]: http://goo.gl/NPABEq (NEWS.txt)
> > >
> >
> >
>



-- 
http://twitter.com/tjake

[VOTE RESULT] Release Apache Cassandra 2.1.8

[Jake Luciani]

With 6 Binding +1 and 2 non binding +1 and no -1 the vote passes.

-- Forwarded message --
From: Michael Shuler 
Date: Wed, Jul 8, 2015 at 10:19 AM
Subject: Re: [VOTE] Release Apache Cassandra 2.1.8
To: dev@cassandra.apache.org


+1 non-binding


On 07/06/2015 12:04 PM, Jake Luciani wrote:

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



-- 
http://twitter.com/tjake

[VOTE RESULT] Release Apache Cassandra 2.2.0-rc2

[Jake Luciani]

6 Binding +1,  2 non-binding +1, 1 non-binding -1 the vote passes


-- Forwarded message --
From: Jake Luciani 
Date: Thu, Jul 9, 2015 at 9:04 AM
Subject: Re: [VOTE] Release Apache Cassandra 2.2.0-rc2
To: "dev@cassandra.apache.org" 


We've discussed on https://issues.apache.org/jira/browse/CASSANDRA-9749

This is technically a general issue with how we deal with CL errors and it
should be fixed in 2.1 branch as well as with new compressed CL in 2.2 so
it shouldn't block this vote.



On Wed, Jul 8, 2015 at 10:50 AM, Blake Eggleston <
blake.eggles...@datastax.com> wrote:

> -1. I've found some problems with 2.2 commit log replay in
> https://issues.apache.org/jira/browse/CASSANDRA-9749 that could lose data
> in some situations.
>
>
> On Wed, Jul 8, 2015 at 7:19 AM Michael Shuler 
> wrote:
>
> > +1 non-binding
> >
> > On 07/06/2015 01:47 PM, Jake Luciani wrote:
> > > I propose the following artifacts for release as 2.2.0-rc2.
> > >
> > > sha1: ebc50d783505854f04f183297ad3009b9095b07e
> > > Git:
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-rc2-tentative
> > > Artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1065/org/apache/cassandra/apache-cassandra/2.2.0-rc2/
> > > Staging repository:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1065/
> > >
> > > The artifacts as well as the debian package are also available here:
> > > http://people.apache.org/~jake
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: http://goo.gl/C1QdHh (CHANGES.txt)
> > > [2]: http://goo.gl/NPABEq (NEWS.txt)
> > >
> >
> >
>



-- 
http://twitter.com/tjake

[RELEASE] Apache Cassandra 2.1.8 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/heI10N (CHANGES.txt)
[2]: http://goo.gl/BIe5dS (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RELEASE] Apache Cassandra 2.2.0-rc2 released

[Jake Luciani]

The Cassandra team is pleased to announce the release of Apache Cassandra
version 2.2.0-rc2.

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/pE0pPF (CHANGES.txt)
[2]: http://goo.gl/h5OJie (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 2.2.0

[Jake Luciani]

I propose the following artifacts for release as 2.2.0.

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 2.2.0

[Jake Luciani]

With 5 binding +1, 4 non-binding +1 and no -1 the vote passes. I'll publish
the artifacts

-- Forwarded message --
From: Jason Brown 
Date: Fri, Jul 17, 2015 at 7:43 PM
Subject: Re: [VOTE] Release Apache Cassandra 2.2.0
To: "dev@cassandra.apache.org" 


+1

On Fri, Jul 17, 2015 at 4:02 PM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On July 17, 2015 at 21:08:06, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 2.2.0.
>
> sha1: 437bb9de77f54aa5a4a6a634ab3d2c753a17b3fc
> Git:
>
>
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-tentative
> Artifacts:
>
>
https://repository.apache.org/content/repositories/orgapachecassandra-1067/org/apache/cassandra/apache-cassandra/2.2.0/
> Staging repository:
>
https://repository.apache.org/content/repositories/orgapachecassandra-1067/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/3FbKhG (CHANGES.txt)
> [2]: http://goo.gl/sMGs53 (NEWS.txt)
>

[RELEASE] Apache Cassandra 2.2.0 released

[Jake Luciani]

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

You can read about the release here:
http://www.datastax.com/dev/blog/cassandra-2-2

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/nUjs6O (CHANGES.txt)
[2]: http://goo.gl/Qk4ljt (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 3.0.0-alpha1

[Jake Luciani]

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

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 3.0.0-alpha1

[Jake Luciani]

With 5 binding +1,  4 non-binding +1, and no -1 the vote passes. I'll start
publishing.


-- Forwarded message --
From: Sylvain Lebresne 
Date: Sun, Aug 2, 2015 at 2:54 AM
Subject: Re: [VOTE] Release Apache Cassandra 3.0.0-alpha1
To: dev@cassandra.apache.org


+1
On Jul 31, 2015 7:00 PM, "Brandon Williams"  wrote:

> +1
>
> On Fri, Jul 31, 2015 at 8:42 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.0.0-alpha1.
> >
> > sha1: b090ed6938c0fad792e51757384bd5ac7f35a301
> > Git:
> >
> >
>
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-alpha1-tentative
> > Artifacts:
> >
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1070/org/apache/cassandra/apache-cassandra/3.0.0-alpha1/
> > Staging repository:
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1070/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/oowQCQ (CHANGES.txt)
> > [2]: http://goo.gl/s0RHg4 (NEWS.txt)
> >
>

[RELEASE] Apache Cassandra 3.0.0-alpha1 released

[Jake Luciani]

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

This is the first test build of Cassandra 3.0 that includes:

   * New storage engine
   * New sstable format
   * Materialized Views

We expect bugs in this release so test and report any issues please!


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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/qTe3Ed (CHANGES.txt)
[2]: http://goo.gl/eMIDGw (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: Proposal, add Epic to the set of issue types available in ASF Jira for Cassandra

[Jake Luciani]

Is the reason to use epics over labels simply because the agile board
doesn't support it?

On Wed, Aug 5, 2015 at 12:42 PM, Ariel Weisberg  wrote:

> Hi,
>
> At this stage I wasn't going to propose a process change. My goal is to
> observe and report mall cop style so I can present what happens the way we
> currently operate. Right now Epics are just a way for me to bucket and then
> rank things inside a release based on what they are, enhancement, core to
> the release (Materialized Views, 8099), bugs or failing tests.
>
> Regards,
> Ariel
>
> On Wed, Aug 5, 2015 at 11:43 AM, Gary Dusbabek 
> wrote:
>
> > Who would have the burden of assigning and managing epics?
> >
> > Thanks,
> >
> > Gary.
> >
> >
> >
> > On Tue, Aug 4, 2015 at 3:08 PM, Ariel Weisberg <
> > ariel.weisb...@datastax.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I am playing with using an Agile board to track what goes into each
> > > Cassandra release. What slips from release to release, as well as what
> is
> > > added after the initial set of tasks for a release is started.
> > >
> > > You can see the SCRUM agile board I created here
> > > <
> > >
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=83&view=planning.nodetail&selectedIssue=CASSANDRA-9908&epics=visible
> > > >
> > > .
> > >
> > > The board has two ways to bucket issues. One is the release in which
> the
> > > issue is supposed to be fixed. The other is Epics. Epics are not
> > associated
> > > with a release so a feature like 8099 might have an epic. Epics can be
> > used
> > > to bucket issues within a release or across releases.
> > >
> > > I would characterize Epics as being a lot like labels that integrate
> with
> > > the Agile board. You can use labels with Agile boards by adding quick
> > > filters to select on labels.
> > >
> > > The current set of issues types associated with the C* project in ASF
> > JIRA
> > > doesn't include Epic or Story. I don't use Story, but Epic would be
> > useful
> > > for further categorizing things.
> > >
> > > When I asked ASF Infra about it they said that this needs discussion
> and
> > > approval by the PMC.
> > >
> > > Thanks,
> > > Ariel
> > >
> >
>



-- 
http://twitter.com/tjake

[VOTE] Release Apache Cassandra 3.0.0-beta1

[Jake Luciani]

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

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 3.0.0-beta1

[Jake Luciani]

With 5 binding +1, 3 non-binding +1 and no -1 the vote passes.  I'll
publish shortly.


-- Forwarded message --
From: Josh McKenzie 
Date: Mon, Aug 24, 2015 at 7:50 AM
Subject: Re: [VOTE] Release Apache Cassandra 3.0.0-beta1
To: dev@cassandra.apache.org


+1

On Fri, Aug 21, 2015 at 11:14 PM, Jake Luciani  wrote:

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

[RELEASE] Apache Cassandra 3.0.0-beta1 released

[Jake Luciani]

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

You’ll need python-driver 3.0.0a2 (available on pypi) or java-driver
3.0.0-alpha2 (uploaded to Maven Central) to try out 3.0.0-beta1.

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/2TNRm5 (CHANGES.txt)
[2]: http://goo.gl/9xluWy (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 2.1.9

[Jake Luciani]

I propose the following artifacts for release as 2.1.9.

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

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

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

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

[VOTE] Release Apache Cassandra 2.2.1

[Jake Luciani]

I propose the following artifacts for release as 2.2.1.

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

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

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

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

Re: [VOTE] Release Apache Cassandra 2.2.1

[Jake Luciani]

Ok this vote failed.  Will try again.

On Wed, Aug 26, 2015 at 5:08 PM, Robert Stupp  wrote:

> -1
>
> UnbufferedDataOutputStreamPlus.writeUTF() is broken for empty strings and
> for strings with a serialized length > 8190 bytes.
> This method is used anywhere where strings are written to any DataOutput
> implementation.
>
> 2.2.0 is affected (but 2.1 releases are not)
>
> A fix is already there and Ariel will file a ticket soon.
>
> Robert
>
> > I propose the following artifacts for release as 2.2.1.
> >
> > sha1: 323890647718d6e061349cf8cbe857b95bd02b13
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.1-tentative
> >
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1074/org/apache/cassandra/apache-cassandra/2.2.1/
> >
> > Staging repository:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1074/
> > The artifacts as well as the debian package are also available here:
> >
> > http://people.apache.org/~jake
> >
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]:
> > http://goo.gl/3ifmBZ
> >  (CHANGES.txt)
> > [2]:
> > http://goo.gl/7rQrRR (NEWS.txt)
>
> —
> Robert Stupp
> @snazy
>
>


-- 
http://twitter.com/tjake

[VOTE RESULT] Release Apache Cassandra 2.1.9

[Jake Luciani]

With 5 binding +1 and no -1 the vote passes.  I'll start publishing...

On Tue, Aug 25, 2015 at 12:35 PM, Brandon Williams  wrote:

> +1
>
> On Tue, Aug 25, 2015 at 9:01 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.1.9.
> >
> > sha1: 7d74563a25cb34784ae3dca05fe503bdb60f5fe5
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.9-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1073/org/apache/cassandra/apache-cassandra/2.1.9/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1073/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/FRGAh2 (CHANGES.txt)
> > [2]: http://goo.gl/7HLc2N (NEWS.txt)
> >
>



-- 
http://twitter.com/tjake

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

[Jake Luciani]

I propose the following artifacts for release as 2.2.1.

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

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

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

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

[RELEASE] Apache Cassandra 2.1.9 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/xnYwFa (CHANGES.txt)
[2]: http://goo.gl/QDqPhN (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

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

[Jake Luciani]

With 5 binding +1, 1 non-binding +1 and no -1 the vote passes. I'll start
publishing

On Sat, Aug 29, 2015 at 6:13 AM, Robert Stupp  wrote:

> +1
>
> > On 28 Aug 2015, at 16:04, Jake Luciani  wrote:
> >
> > I propose the following artifacts for release as 2.2.1.
> >
> > sha1: 01a11fd2626d57bf0c8d0bce1e43060017592896
> > Git:
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.1-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1076/org/apache/cassandra/apache-cassandra/2.2.1/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1076/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/3ifmBZ (CHANGES.txt)
> > [2]: http://goo.gl/7rQrRR (NEWS.txt)
>
> —
> Robert Stupp
> @snazy
>
>


-- 
http://twitter.com/tjake

[RELEASE] Apache Cassandra 2.2.1 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/x6ilHu (CHANGES.txt)
[2]: http://goo.gl/FHwYLN (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 3.0.0-beta2

[Jake Luciani]

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

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 3.0.0-beta2

[Jake Luciani]

With 5 binding +1 and no -1 the vote passes. I'll publish shortly.

On Sun, Sep 6, 2015 at 7:51 AM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On September 5, 2015 at 01:58:05, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 3.0.0-beta2.
>
> sha1: 17528910b82391bd834f1fddce4ff7c9b34ad452
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-beta2-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1077/org/apache/cassandra/apache-cassandra/3.0.0-beta2/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1077/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 48 hours (longer if needed).
>
> [1]: http://goo.gl/h3McOM (CHANGES.txt)
> [2]: http://goo.gl/WGb5qo (NEWS.txt)
>



-- 
http://twitter.com/tjake

[RELEASE] Apache Cassandra 3.0.0-beta2 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/UWe5yb (CHANGES.txt)
[2]: http://goo.gl/xWOSDa (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 2.0.17

[Jake Luciani]

I propose the following artifacts for release as 2.0.17.

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

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

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

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

Re: [VOTE] Release Apache Cassandra 2.0.17

[Jake Luciani]

I'm not inclined to re-roll for a missing CR but if others feel strongly
about it I will do it.

On Wed, Sep 16, 2015 at 10:04 PM, Brandon Williams  wrote:

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



-- 
http://twitter.com/tjake

[VOTE RESULT] Release Apache Cassandra 2.0.17

[Jake Luciani]

The result failed. I will re-roll

On Thu, Sep 17, 2015 at 8:29 PM, Aleksey Yeschenko 
wrote:

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


-- 
http://twitter.com/tjake

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

[Jake Luciani]

I propose the following artifacts for release as 2.0.17.

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

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

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

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

[VOTE] Release Apache Cassandra 3.0.0-rc1

[Jake Luciani]

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

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

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

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

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

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

[Jake Luciani]

With 6 binding +1 votes, 1 non-binding +1 vote,  and no -1 votes the vote
passes. I'll publish.

On Mon, Sep 21, 2015 at 9:49 AM, Gary Dusbabek  wrote:

> [late] +1.
>
> On Fri, Sep 18, 2015 at 9:47 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.0.17.
> >
> > sha1: c4de752758c3cf7f5de5a92e4ede30e430a36255
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.17-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1079/org/apache/cassandra/apache-cassandra/2.0.17/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1079/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/1g0t58 (CHANGES.txt)
> > [2]: http://goo.gl/SHN2y3 (NEWS.txt)
> >
>



-- 
http://twitter.com/tjake

[VOTE RESULT] Release Apache Cassandra 3.0.0-rc1

[Jake Luciani]

With 5 binding +1 votes, 5 non-binding +1 votes and no -1 votes, the vote
passes. I'll publish



On Mon, Sep 21, 2015 at 10:52 AM, Michael Shuler 
wrote:

> non-binding +1
>
>
> On 09/19/2015 01:42 PM, Jake Luciani wrote:
>
>> I propose the following artifacts for release as 3.0.0-rc1.
>>
>> sha1: c95a7098cf77b5b8e96feb7c39aca8fec3a02f9c
>> Git:
>>
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-rc1-tentative
>> Artifacts:
>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1080/org/apache/cassandra/apache-cassandra/3.0.0-rc1/
>> Staging repository:
>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1080/
>>
>> The artifacts as well as the debian package are also available here:
>> http://people.apache.org/~jake
>>
>> The vote will be open for 24 hours (longer if needed).
>>
>> [1]: http://goo.gl/m3OPOV (CHANGES.txt)
>> [2]: http://goo.gl/Z0HNhw (NEWS.txt)
>>
>>
>


-- 
http://twitter.com/tjake

[RELEASE] Apache Cassandra 2.0.17 released

[Jake Luciani]

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

This is most likely the final release for the 2.0 release series.

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/QwruFc (CHANGES.txt)
[2]: http://goo.gl/fHlSqL (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RELEASE] Apache Cassandra 3.0.0-rc1 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/Oppn3S (CHANGES.txt)
[2]: http://goo.gl/zQFaj4 (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 2.1.10

[Jake Luciani]

I propose the following artifacts for release as 2.1.10.

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

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

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

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

[VOTE] Release Apache Cassandra 2.2.2

[Jake Luciani]

I propose the following artifacts for release as 2.2.2.

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 2.2.2

[Jake Luciani]

With 6 binding +1, 2 non-binding +1 and no -1 the vote passes.



On Fri, Oct 2, 2015 at 6:13 AM, Jacques-Henri Berthemet <
jacques-henri.berthe...@genesys.com> wrote:

> +1
>
> --
> Jacques-Henri Berthemet
>
> -Original Message-
> From: jak...@gmail.com [mailto:jak...@gmail.com] On Behalf Of Jake Luciani
> Sent: jeudi 1 octobre 2015 16:40
> To: dev@cassandra.apache.org
> Subject: [VOTE] Release Apache Cassandra 2.2.2
>
> I propose the following artifacts for release as 2.2.2.
>
> sha1: ae9b7e05222b2a25eda5618cf9eb17103e4d6d8b
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.2-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1082/org/apache/cassandra/apache-cassandra/2.2.2/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1082/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/wbbE4n (CHANGES.txt)
> [2]: http://goo.gl/EN7MxO (NEWS.txt)
>



-- 
http://twitter.com/tjake

[VOTE RESULT] Release Apache Cassandra 2.1.10

[Jake Luciani]

With 6 binding +1, 1 non-binding +1 and no -1 the vote passes.

On Thu, Oct 1, 2015 at 2:18 PM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On October 1, 2015 at 07:18:10, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 2.1.10.
>
> sha1: 78f2e7aa01d552454fd4270fee8d600c4433df5c
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.10-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1081/org/apache/cassandra/apache-cassandra/2.1.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1081/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/GLMVLb (CHANGES.txt)
> [2]: http://goo.gl/uFe1VN (NEWS.txt)
>



-- 
http://twitter.com/tjake

[RELEASE] Apache Cassandra 2.1.10 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/KE0tlf (CHANGES.txt)
[2]: http://goo.gl/0CW2iz (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RELEASE] Apache Cassandra 2.2.2 released

[Jake Luciani]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: http://goo.gl/d9xIEO (CHANGES.txt)
[2]: http://goo.gl/S64khA (NEWS.txt)
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra 2.1.11

[Jake Luciani]

I propose the following artifacts for release as 2.1.11.

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

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

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

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

[VOTE] Release Apache Cassandra 2.2.3

[Jake Luciani]

I propose the following artifacts for release as 2.2.3.

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

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

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

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

[VOTE RESULT] Release Apache Cassandra 2.1.11

[Jake Luciani]

The vota has failed I will open a new vote once the fixes are in.



On Mon, Oct 12, 2015 at 9:56 PM, Stefania Alborghetti <
stefania.alborghe...@datastax.com> wrote:

> -1
>
> The python driver was upgraded and this requires a fix in cqlsh for COPY
> FROM to work, more details in CASSANDRA-10507
> <https://issues.apache.org/jira/browse/CASSANDRA-10507>.
>
> On Tue, Oct 13, 2015 at 2:42 AM, Josh McKenzie 
> wrote:
>
> > +1
> >
> > On Mon, Oct 12, 2015 at 2:32 PM, Brandon Williams 
> > wrote:
> >
> > > +1
> > >
> > > On Mon, Oct 12, 2015 at 1:05 PM, Jake Luciani  wrote:
> > >
> > > > I propose the following artifacts for release as 2.1.11.
> > > >
> > > > sha1: 4acc3a69d319b0e7e00cbd37b27e988ebfa4df4f
> > > > Git:
> > > >
> > > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.11-tentative
> > > > Artifacts:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1084/org/apache/cassandra/apache-cassandra/2.1.11/
> > > > Staging repository:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1084/
> > > >
> > > > The artifacts as well as the debian package are also available here:
> > > > http://people.apache.org/~jake
> > > >
> > > > The vote will be open for 48 hours (longer if needed).
> > > >
> > > > [1]: http://goo.gl/cfjxJU (CHANGES.txt)
> > > > [2]: http://goo.gl/nOz2X6 (NEWS.txt)
> > > >
> > >
> >
>
>
>
> --
>
>
> [image: datastax_logo.png] <http://www.datastax.com/>
>
> Stefania Alborghetti
>
> Apache Cassandra Software Engineer
>
> |+852 6114 9265| stefania.alborghe...@datastax.com
>

[VOTE RESULT] Release Apache Cassandra 2.2.3

[Jake Luciani]

The vota has failed I will open a new vote once the fixes are in.


On Mon, Oct 12, 2015 at 9:56 PM, Stefania Alborghetti <
stefania.alborghe...@datastax.com> wrote:

> -1
>
> The python driver was upgraded and this requires a fix in cqlsh for COPY
> FROM to work, more details in CASSANDRA-10507
> <https://issues.apache.org/jira/browse/CASSANDRA-10507>.
>
> On Tue, Oct 13, 2015 at 2:42 AM, Josh McKenzie 
> wrote:
>
> > +1
> >
> > On Mon, Oct 12, 2015 at 2:32 PM, Brandon Williams 
> > wrote:
> >
> > > +1
> > >
> > > On Mon, Oct 12, 2015 at 1:27 PM, Jake Luciani  wrote:
> > >
> > > > I propose the following artifacts for release as 2.2.3.
> > > >
> > > > sha1: 0c051a46c54fd1a2f151e1a68f4556faca02be8d
> > > > Git:
> > > >
> > > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.3-tentative
> > > > Artifacts:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1085/org/apache/cassandra/apache-cassandra/2.2.3/
> > > > Staging repository:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1085/
> > > >
> > > > The artifacts as well as the debian package are also available here:
> > > > http://people.apache.org/~jake
> > > >
> > > > The vote will be open for 48 hours (longer if needed).
> > > >
> > > > [1]: http://goo.gl/dmpzjR (CHANGES.txt)
> > > > [2]: http://goo.gl/ACOC01 (NEWS.txt)
> > > >
> > >
> >
>
>
>
> --
>
>
> [image: datastax_logo.png] <http://www.datastax.com/>
>
> Stefania Alborghetti
>
> Apache Cassandra Software Engineer
>
> |+852 6114 9265| stefania.alborghe...@datastax.com
>