netty version in binary cassandra-java-driver 3.6

[Michael]

Hello,

I wanted to use the driver with the included netty jars since the netty
version of debian stretch is too old.

But my program fails with NoClassDefFoundError: io/netty/util/NettyRuntime

The reason is that the driver tarball has netty 4.0.56 in the lib
directory but this version doesn't include the NettyRuntime class.

Did I downloaded the wrong tarball of the java driver? Or is the netty
version in this tarball also too old?

Thanks for helping,
 Michael


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

Re: Should we change 4.1 to G1 and offheap_objects ?

[Michael Shuler]

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


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


Kind regards,
Michael

Re: [VOTE] CEP-30 ANN Vector Search

[Michael Shuler]

+1, this is cool.

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

Let's make this official.

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


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



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

Re: [VOTE] CEP-8 Datastax Drivers Donation

[Michael Shuler]

+1

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

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

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


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


Jeremy

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

Re: [VOTE] Accept java-driver

[Michael Shuler]

+1

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

Kind regards,
Michael

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

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


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


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


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


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


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


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


regards,
Mick

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

[Michael Shuler]

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


Kind regards,
Michael

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

Hello Cassandra Developers!

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

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

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


Regards,
   Alexander

Re: CI's working, and repeatable !!

[Michael Shuler]

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

Warm regards,
Michael


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

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

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

[Michael Shuler]

+1

Michael

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

Hi everyone,

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


Proposal: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146 <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146>
JIRA under which it will be delivered: 
https://issues.apache.org/jira/browse/CASSANDRA-17457 
<https://issues.apache.org/jira/browse/CASSANDRA-17457>
Draft implementation: 
https://github.com/instaclustr/cassandra/tree/CEP-24-simplified 
<https://github.com/instaclustr/cassandra/tree/CEP-24-simplified>


Discuss threads:

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


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


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


Thanks,

Stefan Miklosovic

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Michael Shuler]

+1

Kind regards,
Michael

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


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


All consent from original authors of the donation, and tracking of 
collected CLAs, is found in:
  - https://github.com/gocql/gocql/issues/1751 
<https://github.com/gocql/gocql/issues/1751>
  - 
https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485 <https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485>

These do not require acknowledgement before thevote.

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


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


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


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


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


regards,
Mick

Re: Hi-Rez of Apache Cassandra logo??

[Michael Shuler]

Nice, thanks!

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

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


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

Add Apache Cassandra logos provided by Scott Andreas

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

--
Kind regards,
Michael

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

Hi Nate,

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

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

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

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

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

– Scott


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

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

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

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

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


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




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

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

[Michael Burman]

Hi,

Should definitely be cross compatible with Python 2/3. Most of the 
systems (such as those running on RHEL7 or distros based on it like 
CentOS) are shipping with 2.7 only by default. And these systems are 
probably going to be used for a long time to run Cassandra.


IIRC, there's no major distribution yet that defaults to Python 3 (I 
think Ubuntu & Debian are still defaulting to Python 2 also). This will 
happen eventually (maybe), but not yet. Discarding Python 2 support 
would mean more base-OS work for most people wanting to run Cassandra 
and that's not a positive thing.


For future, 2 & 3 compatibility would mean that we support larger amount 
of distributions out of the box.


  - Micke


On 06/01/2018 05:44 AM, Patrick Bannister wrote:

I propose porting cqlsh and cqlshlib to Python 3. End-of-life for Python 2.7
 is currently planned for 1
January 2020. We should prepare to port the tool to a version of Python
that will be officially supported.

I'm seeking input on three questions:
- Should we port it to straight Python 3, or Python 2/3 cross compatible?
- How much more testing is needed?
- Can we wait until after 4.0 for this?

I have an implementation
 to go with my
proposal. In parallel with getting the dtest cqlsh_tests working again, I
ported cqlsh.py and cqlshlib to Python 3. It passes with almost all of the
dtests and the unittests, so it's in pretty good shape, although it's not
100% done (more on that below).

*Python 3 or 2/3 cross compatible?* There are plenty of examples of Python
libraries that are compatible with both Python 2 and Python 3 (notably the
Cassandra Python driver), so I think this is achievable. The question is,
do we want to pay the price of cross compatibility? If we write cqlsh to be
2/3 cross compatible, we'll carry a long term technical debt to maintain
that feature. The value of continuing to support Python 2 will diminish
over time. However, a cross compatible implementation may ease the
transition for some users, especially if there are users who have made
significant custom modifications to the Python 2.7 implementation of cqlsh,
so I think we must at least consider the question.

*What additional testing is needed before we could release it?* I used
coverage.py to check on the code coverage of our existing dtest cqlsh_tests
and cqlshlib unittests. There are several blind spots in our current
testing that should be addressed before we release a port of cqlsh. Details
of this are available on JIRA ticket CASSANDRA-10190
 in the attachment
coverage_notes.txt
.
Beyond that, I've made no efforts to test on platforms other than Ubuntu
and CentOS, so Windows testing is needed if we're making efforts to support
Windows. It would also be preferable for some real users to try out the
port before it replaces the Python 2.7 cqlsh in a release.

Besides this, there are a couple of test failures I'm still trying to
figure out, notably tests involving user defined map types (a task made
more interesting by Python's general lack of support for immutable map
types).

*Can we wait until after 4.0 for this?* I don't think it's reasonable to
try to release this with 4.0 given the current consensus around a feature
freeze in the next few months. My feeling is that our testers and
committers are already very busy with the currently planned changes for
4.0. I recommend planning toward a release to occur after 4.0. If we run up
against Python 2.7 EOL before we can cut the next release, we could
consider releasing a ported cqlsh independently, for installation through
distutils or pip.

Patrick Bannister




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

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

[Michael Burman]

Hi,

Deprecating in this context does not mean removing it or it being 
replaced by 3 (RHEL 7.x will remain with Python 2.x as default). It 
refers to future versions (>7), but there are none at this point. It 
appears Ubuntu has deviated from Debian in this sense, but Debian has 
not changed yet (likely Debian 10 will, but that's not out yet and has 
no announced release date).


Thus, 2.x still remains the most used version for servers. And servers 
deployed at this point of time will use these versions for years.


  - Micke


On 06/01/2018 10:52 AM, Murukesh Mohanan wrote:

On 2018/06/01 07:40:04, Michael Burman  wrote:

IIRC, there's no major distribution yet that defaults to Python 3 (I
think Ubuntu & Debian are still defaulting to Python 2 also). This will
happen eventually (maybe), but not yet. Discarding Python 2 support
would mean more base-OS work for most people wanting to run Cassandra
and that's not a positive thing.


Ubuntu since 16.04 defaults to Python 3:


Python2 is not installed anymore by default on the server, cloud and the touch 
images, long live Python3! Python3 itself has been upgraded to the 3.5 series. 
- https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Python_3

RHEL 7.5 deprecates Python 2 
(https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality).



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




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

Re: 3.11.3

[Michael Shuler]

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

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

--
Michael

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

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

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

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


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

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

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

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






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

Re: Small improvement on website

[Michael Shuler]

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

Hi folks,

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


Thanks! Fixed.


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


Nah :)

--
Kind regards,
Michael

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

[VOTE] Release Apache Cassandra 2.2.13

[Michael Shuler]

I propose the following artifacts for release as 2.2.13.

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


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


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

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


--
Michael

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

[VOTE] Release Apache Cassandra 3.0.17

[Michael Shuler]

I propose the following artifacts for release as 3.0.17.

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


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


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

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


--
Michael

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

[VOTE] Release Apache Cassandra 3.11.3

[Michael Shuler]

I propose the following artifacts for release as 3.11.3.

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


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


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

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


--
Michael

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

[VOTE FAILED] Release Apache Cassandra 3.11.3

[Michael Shuler]

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

Kind regards,
Michael

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

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

[VOTE FAILED] Release Apache Cassandra 3.0.17

[Michael Shuler]

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

Kind regards,
Michael

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


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

[VOTE FAILED - VETO] Release Apache Cassandra 2.2.13

[Michael Shuler]

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

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

I'm vetoing this release.

Kind regards,
Michael

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


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

Re: Scratch an itch

[Michael Burman]

On 07/12/2018 07:38 PM, Stefan Podkowinski wrote:

this point? Also, if we tell someone that their contribution will be
reviewed and committed later after 4.0-beta, how is that actually making
a difference for that person, compared to committing it now for a 4.x
version. It may be satisfying to get a patch committed, but what matters
more is when the code will actually be released and deferring committing
contributions after 4.0-beta doesn't necessarily mean that there's any
disadvantage when it comes to that.

Deferring huge amount of commits gives rebase/redo hell. That's the 
biggest impact and the order in which these deferred commits are then 
actually committed can make it more painful or less painful depending on 
the commit. And that in turn will have to then wait for each contributor 
to rebase/redo their commit and those timings might make more rebase 
issues. If those committers will want to rebase something after n-months 
or have time at that point.


That's a problem for all Cassandra patches that take huge time to commit 
and if this block takes a lot of time, then that will for sure be even 
more painful. I know products such as Kubernetes does the same (I guess 
that's where this idea might have come from) "trunk patches only", but 
their block is quite short.


My wish is that this freeze does not last too long to kill enthusiasm 
towards committing to Cassandra. There are (I assume) many hobbyist who 
do this as a side-project instead of their daily work and might not have 
the capabilities to test 4.0 in a way that will trigger bugs (easy bugs 
are fixed quite quickly I hope). And if they feel like it's not worth 
the time at this point to invest time to Cassandra (because nothing they 
do will get merged) - they might move to another project. And there's no 
guarantee they will return. Getting stuff to the product is part of the 
satisfaction and without satisfaction there's no interest in continuing.


  - Micke

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

Re: [VOTE] Branching Change for 4.0 Freeze

[Michael Shuler]

+0

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

Michael

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


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

Re: reroll the builds?

[Michael Shuler]

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

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

Michael

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

[VOTE] Release Apache Cassandra 3.11.3 (Take 2)

[Michael Shuler]

I propose the following artifacts for release as 3.11.3.

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

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

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

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

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

[VOTE] Release Apache Cassandra 3.0.17 (Take 2)

[Michael Shuler]

I propose the following artifacts for release as 3.0.17.

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

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

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

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

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

[VOTE] Release Apache Cassandra 2.2.13

[Michael Shuler]

I propose the following artifacts for release as 2.2.13.

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

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

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

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

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

Re: [VOTE] Release Apache Cassandra 2.2.13

[Michael Shuler]

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

-- 
Warm regards,
Michael

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


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

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

[Michael Shuler]

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

-- 
Warm regards,
Michael


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


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

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

[Michael Shuler]

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

-- 
Warm regards,
Michael


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


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

[RELEASE] Apache Cassandra 2.2.13 released

[Michael Shuler]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

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

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

[RELEASE] Apache Cassandra 3.0.17 released

[Michael Shuler]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

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

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

[RELEASE] Apache Cassandra 3.11.3 released

[Michael Shuler]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

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

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

Re: Side Car New Repo vs not

[Michael Shuler]

+1 for a separate repository.

Michael

On 08/23/2018 07:30 PM, Murukesh Mohanan wrote:
> FWIW, I think it's possible to merge in a separate repository into a
> subdirectory while keeping git history, but I don't know if the other way
> will be possible if commits span other parts of the repo as well\* (which
> will likely happen sooner or later). So a separate repo is a choice we can
> backtrack from if it proves problematic later.
> 
> 
> \* it may be possible, but the commit messages might not make much sense
> after that.
> 
> On Fri, 24 Aug 2018, 09:12 Benedict Elliott Smith, 
> wrote:
> 
>> +1 also for separate repo
>>
>>> On 24 Aug 2018, at 01:11, Jeff Jirsa  wrote:
>>>
>>> +1 for separate repo
>>>
>>>
>>> --
>>> Jeff Jirsa
>>>
>>>
>>>> On Aug 23, 2018, at 1:00 PM, sankalp kohli 
>> wrote:
>>>>
>>>> Separate repo is in a majority so far. Please reply to this thread with
>>>> your responses.
>>>>
>>>> On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh <
>> rahul.xavier.si...@gmail.com>
>>>> wrote:
>>>>
>>>>> +1 for separate repo. Especially on git. Maybe make it a submodule.
>>>>>
>>>>> Rahul
>>>>> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski ,
>>>>> wrote:
>>>>>> I'm also currently -1 on the in-tree option.
>>>>>>
>>>>>> Additionally to what Aleksey mentioned, I also don't see how we could
>>>>>> make this work with the current build and release process. Our scripts
>>>>>> [0] for creating releases (tarballs and native packages), would need
>>>>>> significant work to add support for an independent side-car. Our ant
>>>>>> based build process is also not a great start for adding new tasks,
>> let
>>>>>> alone integrating other tool chains for web components for a potential
>>>>> UI.
>>>>>>
>>>>>> [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
>>>>>>
>>>>>>
>>>>>>> On 21.08.18 19:20, Aleksey Yeshchenko wrote:
>>>>>>> Sure, allow me to elaborate - at least a little bit. But before I do,
>>>>> just let me note that this wasn’t a veto -1, just a shorthand for “I
>> don’t
>>>>> like this option”.
>>>>>>>
>>>>>>> It would be nice to have sidecar and C* version and release cycles
>>>>> fully decoupled. I know it *can* be done when in-tree, but the way we
>> vote
>>>>> on releases with tags off current branches would have to change
>> somehow.
>>>>> Probably painfully. It would be nice to be able to easily enforce
>> freezes,
>>>>> like the upcoming one, on the whole C* repo, while allowing feature
>>>>> development on the sidecar. It would be nice to not have sidecar
>> commits in
>>>>> emails from commits@ mailing list. It would be nice to not have C* CI
>>>>> trigger necessarily on sidecar commits. Groups of people working on
>> the two
>>>>> repos will mostly be different too, so what’s the point in sharing the
>> repo?
>>>>>>>
>>>>>>> Having an extra repo with its own set of branches is cheap and easy -
>>>>> we already do that with dtests. I like cleanly separated things when
>>>>> coupling is avoidable. As such I would prefer the sidecar to live in a
>>>>> separate new repo, while still being part of the C* project.
>>>>>>>
>>>>>>> —
>>>>>>> AY
>>>>>>>
>>>>>>> On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com
>> )
>>>>> wrote:
>>>>>>>
>>>>>>> Hi Aleksey,
>>>>>>> Can you please elaborate on the reasons for your -1? This
>>>>>>> way we can make progress towards any one approach.
>>>>>>> Thanks,
>>>>>>> Sankalp
>>>>>>>
>>>>>>> On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko <
>> alek...@apple.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> FWIW I’m strongly -1 on in-tree approach, and would much prefer a
>>>>> separate
>>>>>>>> repo, dtest-styl

FYI: builds.apache.org is down

[Michael Shuler]

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

-- 
Kind regards,
Michael

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

Re: [Discuss] Accept GoCQL driver donation

[Michael Shuler]

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

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

-- 
Michael

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


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

Re: [Discuss] Accept GoCQL driver donation

[Michael Shuler]

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

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

-- 
Kind regards,
Michael

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

Re: Request for post-freeze merge exception

[Michael Shuler]

+1 to merge.

-- 
Michael

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


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

Re: Moving tickets out of 4.0 post freeze

[Michael Shuler]

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

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

-- 
Michael

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

Re: Moving tickets out of 4.0 post freeze

[Michael Shuler]

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

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

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

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

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

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

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

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


Michael

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


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

Re: Implicit Casts for Arithmetic Operators

[Michael Burman]

Hi,

I'm not sure if I would prefer the Postgres way of doing things, which is
returning just about any type depending on the order of operators.
Considering it actually mentions in the docs that using numeric/decimal is
slow and also multiple times that floating points are inexact. So doing
some math with Postgres (9.6.5):

SELECT 2147483647::bigint*1.0::double precision returns double
precision 2147483647
SELECT 2147483647::bigint*1.0 returns numeric 2147483647.0
SELECT 2147483647::bigint*1.0::real returns double
SELECT 2147483647::double precision*1::bigint returns double 2147483647
SELECT 2147483647::double precision*1.0::bigint returns double 2147483647

With + - we can get the same amount of mixture of returned types. There's
no difference in those calculations, just some casting. To me
floating-point math indicates inexactness and has errors and whoever mixes
up two different types should understand that. If one didn't want exact
numeric type, why would the server return such? The floating point value
itself could be wrong already before the calculation - trying to say we do
it lossless is just wrong.

Fun with 2.65:

SELECT 2.65::real * 1::int returns double 2.6509536743
SELECT 2.65::double precision * 1::int returns double 2.65

SELECT round(2.65) returns numeric 4
SELECT round(2.65::double precision) returns double 4

SELECT 2.65 * 1 returns double 2.65
SELECT 2.65 * 1::bigint returns numeric 2.65
SELECT 2.65 * 1.0 returns numeric 2.650
SELECT 2.65 * 1.0::double precision returns double 2.65

SELECT round(2.65) * 1 returns numeric 3
SELECT round(2.65) * round(1) returns double 3

So as we're going to have silly values in any case, why pretend something
else? Also, exact calculations are slow if we crunch large amount of
numbers. I guess I slightly deviated towards Postgres' implemention in this
case, but I wish it wasn't used as a benchmark in this case. And most
importantly, I would definitely want the exact same type returned each time
I do a calculation.

  - Micke

On Fri, Oct 12, 2018 at 4:29 PM Benedict Elliott Smith 
wrote:

> As far as I can tell we reached a relatively strong consensus that we
> should implement lossless casts by default?  Does anyone have anything more
> to add?
>
> Looking at the emails, everyone who participated and expressed a
> preference was in favour of the “Postgres approach” of upcasting to decimal
> for mixed float/int operands?
>
> I’d like to get a clear-cut decision on this, so we know what we’re doing
> for 4.0.  Then hopefully we can move on to a collective decision on Ariel’s
> concerns about overflow, which I think are also pressing - particularly for
> tinyint and smallint.  This does also impact implicit casts for mixed
> integer type operations, but an approach for these will probably fall out
> of any decision on overflow.
>
>
>
>
>
>
> > On 3 Oct 2018, at 11:38, Murukesh Mohanan 
> wrote:
> >
> > I think you're conflating two things here. There's the loss resulting
> from
> > using some operators, and loss involved in casting. Dividing an integer
> by
> > another integer to obtain an integer result can result in loss, but
> there's
> > no implicit casting there and no loss due to casting.  Casting an integer
> > to a float can also result in loss. So dividing an integer by a float,
> for
> > example, with an implicit cast has an additional avenue for loss: the
> > implicit cast for the operands so that they're of the same type. I
> believe
> > this discussion so far has been about the latter, not the loss from the
> > operations themselves.
> >
> > On Wed, 3 Oct 2018 at 18:35 Benjamin Lerer 
> > wrote:
> >
> >> Hi,
> >>
> >> I would like to try to clarify things a bit to help people to understand
> >> the true complexity of the problem.
> >>
> >> The *float *and *double *types are inexact numeric types. Not only at
> the
> >> operation level.
> >>
> >> If you insert 676543.21 in a *float* column and then read it, you will
> >> realize that the value has been truncated to 676543.2.
> >>
> >> If you want accuracy the only way is to avoid those inexact types.
> >> Using *decimals
> >> *during operations will mitigate the problem but will not remove it.
> >>
> >>
> >> I do not recall PostgreSQL behaving has described. If I am not mistaken
> in
> >> PostgreSQL *SELECT 3/2* will return *1*. Which is similar to what MS SQL
> >> server and Oracle do. So all thoses databases will lose precision if you
> >> are not carefull.
> >>
> >> If you truly need precision you can have it by using exact numeric types
> >> for your data types. Of course it has a cost on performance, memory and
> >> disk usage.
> >>
> >> The advantage of the current approach is that it give you the choice.
> It is
> >> up to you to decide what you need for your application. It is also in
> line
> >> with the way CQL behave everywhere else.
> >>
> > --
> >
> > Muru
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cass

Re: CASSANDRA-13241 lower default chunk_length_in_kb

[Michael Shuler]

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

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

-- 
Michael

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

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

[Michael Shuler]

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

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

Michael




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

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

[Michael Burman]

On 11/12/18 5:37 PM, Michael Shuler wrote:

Issue with upstream links to:
https://github.com/hyperic/sigar/issues/77


.. clip. Considering the Sigar has been unmaintained for years (and has 
large amount of unfixed bugs), should we consider removing it from the 
project? It's not used much, so finding suitable replacement for those 
few functions shouldn't be that big of a deal.


  - Micke

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

Re: Implicit Casts for Arithmetic Operators

[Michael Burman]

gt;>>>
> >>>>> I agree with what's been said about expectations regarding
> expressions
> >> involving floating point numbers. I think that if one of the inputs is
> >> approximate then the result should be approximate.
> >>>>>
> >>>>> One thing we could look at for inspiration is the SQL spec. Not to
> >> follow dogmatically necessarily.
> >>>>>
> >>>>> From the SQL 92 spec regarding assignment
> >> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt section 4.6:
> >>>>> "
> >>>>>   Values of the data types NUMERIC, DECIMAL, INTEGER, SMALLINT,
> >>>>>   FLOAT, REAL, and DOUBLE PRECISION are numbers and are all
> >> mutually
> >>>>>   comparable and mutually assignable. If an assignment would
> >> result
> >>>>>   in a loss of the most significant digits, an exception
> condition
> >>>>>   is raised. If least significant digits are lost,
> implementation-
> >>>>>   defined rounding or truncating occurs with no exception
> >> condition
> >>>>>   being raised. The rules for arithmetic are generally governed
> by
> >>>>>   Subclause 6.12, "".
> >>>>> "
> >>>>>
> >>>>> Section 6.12 numeric value expressions:
> >>>>> "
> >>>>>   1) If the data type of both operands of a dyadic arithmetic
> >> opera-
> >>>>>  tor is exact numeric, then the data type of the result is
> >> exact
> >>>>>  numeric, with precision and scale determined as follows:
> >>>>> ...
> >>>>>   2) If the data type of either operand of a dyadic arithmetic
> op-
> >>>>>  erator is approximate numeric, then the data type of the re-
> >>>>>  sult is approximate numeric. The precision of the result is
> >>>>>  implementation-defined.
> >>>>> "
> >>>>>
> >>>>> And this makes sense to me. I think we should only return an exact
> >> result if both of the inputs are exact.
> >>>>>
> >>>>> I think we might want to look closely at the SQL spec and especially
> >> when the spec requires an error to be generated. Those are sometimes in
> the
> >> spec to prevent subtle paths to wrong answers. Any time we deviate from
> the
> >> spec we should be asking why is it in the spec and why are we deviating.
> >>>>>
> >>>>> Another issue besides overflow handling is how we determine precision
> >> and scale for expressions involving two exact types.
> >>>>>
> >>>>> Ariel
> >>>>>
> >>>>>> On Fri, Oct 12, 2018, at 11:51 AM, Michael Burman wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm not sure if I would prefer the Postgres way of doing things,
> >> which is
> >>>>>> returning just about any type depending on the order of operators.
> >>>>>> Considering it actually mentions in the docs that using
> >> numeric/decimal is
> >>>>>> slow and also multiple times that floating points are inexact. So
> >> doing
> >>>>>> some math with Postgres (9.6.5):
> >>>>>>
> >>>>>> SELECT 2147483647 <(214)%20748-3647>::bigint*1.0::double precision
> returns double
> >>>>>> precision 2147483647 <(214)%20748-3647>
> >>>>>> SELECT 2147483647 <(214)%20748-3647>::bigint*1.0 returns numeric
> 2147483647 <(214)%20748-3647>.0
> >>>>>> SELECT 2147483647 <(214)%20748-3647>::bigint*1.0::real returns
> double
> >>>>>> SELECT 2147483647 <(214)%20748-3647>::double precision*1::bigint
> returns double
> >> 2147483647 <(214)%20748-3647>
> >>>>>> SELECT 2147483647 <(214)%20748-3647>::double precision*1.0::bigint
> returns double
> >> 2147483647 <(214)%20748-3647>
> >>>>>>
> >>>>>> With + - we can get the same amount of mixture of returned types.
> >> There's
> >>>>>> no difference in those calculations, just some casting. To me
> >>>>>> floating-point math indicates inexactness and

Re: RES: Implicit Casts for Arithmetic Operators

[Michael Shuler]

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

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

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

-- 
Kind regards,
Michael

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

Re: RES: RES: Implicit Casts for Arithmetic Operators

[Michael Shuler]

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

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

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


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

Re: [VOTE] Change Jira Workflow

[Michael Shuler]

+1

-- 
Michael

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


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

Re: Git Repo Migration

[Michael Shuler]

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

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

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

Michael

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


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

Re: Git Repo Migration

[Michael Shuler]

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

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

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

Michael

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

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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

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

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

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

Michael

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


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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

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

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

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

Michael

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


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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

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

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

Michael

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


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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

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

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

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

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

Michael

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

Re: [DISCUSS] releasing next 3.0 & 3.11

[Michael Shuler]

No problem, thanks for asking :)

Michael

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


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

EOL 2.1 series?

[Michael Shuler]

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

Michael

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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

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

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

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

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

Michael

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

Re: Who should be in our distribution KEYS file?

[Michael Shuler]

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

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

Michael

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

Re: [DISCUSS] releasing next 3.0 & 3.11

[Michael Shuler]

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

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

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

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

-- 
Michael

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

[VOTE] Release Apache Cassandra 2.2.14

[Michael Shuler]

I propose the following artifacts for release as 2.2.14.

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

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

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

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



signature.asc
Description: OpenPGP digital signature

[VOTE] Release Apache Cassandra 3.0.18

[Michael Shuler]

I propose the following artifacts for release as 3.0.18.

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

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

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

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



signature.asc
Description: OpenPGP digital signature

[VOTE] Release Apache Cassandra 2.1.21

[Michael Shuler]

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



I propose the following artifacts for release as 2.1.21.

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

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

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

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



signature.asc
Description: OpenPGP digital signature

[VOTE] Release Apache Cassandra 3.11.4

[Michael Shuler]

I propose the following artifacts for release as 3.11.4.

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

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

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

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



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Cassandra 2.1.21

[Michael Shuler]

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

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

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

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

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

Michael

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


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

Re: [VOTE PASSED] Release Apache Cassandra 3.11.4

[Michael Shuler]

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

Kind regards,
Michael

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




signature.asc
Description: OpenPGP digital signature

Re: [VOTE PASSED] Release Apache Cassandra 3.0.18

[Michael Shuler]

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

Kind regards,
Michael

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




signature.asc
Description: OpenPGP digital signature

Re: [VOTE PASSED] Release Apache Cassandra 2.2.14

[Michael Shuler]

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

Kind regards,
Michael

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




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Cassandra 2.1.21

[Michael Shuler]

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

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

Kind regards,
Michael

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




signature.asc
Description: OpenPGP digital signature

[RELEASE] Apache Cassandra 3.11.4 released

[Michael Shuler]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

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

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

[RELEASE] Apache Cassandra 3.0.18 released

[Michael Shuler]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

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

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

[RELEASE] Apache Cassandra 2.2.14 released

[Michael Shuler]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

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

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

[RELEASE] Apache Cassandra 2.1.21 released

[Michael Shuler]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

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

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

Re: CASSANDRA-14482

[Michael Shuler]

+0.5

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

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

-- 
Michael

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


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

Re: Looking for common cases in cassandra fit to autoheal

[Michael Shuler]

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

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

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


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

Re: Both Java 8 and Java 11 required for producing a tarball

[Michael Shuler]

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

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

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

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

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

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

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

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

cd cassandra-builds/

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

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

After all that, here's my tar artifacts:

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

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

-- 
Kind regards,
Michael

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

Re: Cassandra repo keys are revoked

[Michael Shuler]

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


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

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

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

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

Drop that bogus key from apt-keys:

apt-key del D46C5ECBFE4B2BDA

This message is signed with the correct key.

-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature

Re: Cassandra repo keys are revoked

[Michael Shuler]

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

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

-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature

Re: Choosing a supported Python 3 major version for cqlsh

[Michael Shuler]

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

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

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

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

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

-- 
Michael

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

Re: Choosing a supported Python 3 major version for cqlsh

[Michael Shuler]

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

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

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

Michael

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

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

[Michael Shuler]

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

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


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


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


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


--
Warm regards,
Michael

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

Re: Time for a new 3.0/3.11 release?

[Michael Shuler]

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

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


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


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


--
Kind regards,
Michael

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

Re: Time for a new 3.0/3.11 release?

[Michael Shuler]

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

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


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


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


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


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


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


Kind regards,
Michael



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


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



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

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

regards, Mick

-


To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org 
<mailto:dev-unsubscr...@cassandra.apache.org>

For additional commands, e-mail: dev-h...@cassandra.apache.org
<mailto:dev-h...@cassandra.apache.org>





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

Request for review - 2 jiras for 3.0/3.11

[Michael Shuler]

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


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

Michael

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

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

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

Thanks,
Jay

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




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


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

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

regards,
Mick

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





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

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

[Michael Shuler]

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


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

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

BUILD SUCCESSFUL
Total time: 1 minute 32 seconds

--
Kind regards,
Michael

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

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



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

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

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

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



Thank you!

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

-



To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org

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




-



To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org

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




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

Re: Apache Cassandra Virtual meetings

[Michael Shuler]

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

shared Google Calendar


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


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


--
Warm regards,
Michael

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

Re: Contributing cassandra-diff

[Michael Shuler]

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


Thanks for the neat looking utility!

Michael

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

A different repo will be better


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

Very powerful tool indeed, thanks for sharing!

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

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

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


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

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


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


I weakly prefer contrib.


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


wrote:



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

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

more

contributed tools in the future

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

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

it

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

configuration

variable “reverse_read_probability” the rows are either read
forward or

in

reverse order.

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

make

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

bugs we

have found using this tool:

* CASSANDRA-14823: Legacy sstables with range tombstones spanning

multiple

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

/Marcus

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





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



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


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



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

Re: Stability of MaterializedView in 3.11.x | 4.0

[Michael Shuler]

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


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

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


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

--
Michael

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

Hello,



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



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



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



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



Regards

Pankaj.



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

Re: 4.0 alpha before apachecon?

[Michael Shuler]

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


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


--
Michael

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

Hey folks,

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

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

Jon



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

Re: Builds email notifications

[Michael Shuler]

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



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

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



Done.


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


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

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


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


--
Kind regards,
Michael

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

Re: Builds email notifications

[Michael Shuler]

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



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



Quick or the dead around here :-)

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

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


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


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


--
Michael

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

Re: 4.0 alpha before apachecon?

[Michael Shuler]

Quick update on 4.0-alpha1 builds:

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


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


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

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


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


Michael

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

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

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

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

What do people think?
-Joey

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


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

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

--
Michael

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

Hey folks,

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

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

Jon



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



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



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

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

[Michael Shuler]

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

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


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


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

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


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

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

[Michael Shuler]

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

--
Michael

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

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

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

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

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


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


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

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

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



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

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

[Michael Shuler]

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


Michael

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

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

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

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

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

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

j8_upgradetests-no-vnodes: 3923 failures

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

-Joey


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


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

Will report back with results shortly,
-Joey

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


+1

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


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

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git:

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

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

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

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

[1]: CHANGES.txt:

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

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

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




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



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

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

[Michael Shuler]

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


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


--
Kind regards,
Michael

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

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

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

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

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


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


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

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

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



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

[RELEASE] Apache Cassandra 4.0-alpha1 released

[Michael Shuler]

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


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


 http://cassandra.apache.org/

Downloads of source and binary distributions for 4.0-alpha1:


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

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

Debian and Redhat configurations

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

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

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


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


Enjoy!

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

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

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

Re: moving the site from SVN to git

[Michael Shuler]

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


Michael

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



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



Yes. I need the history in *git*.


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

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



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

Re: moving the site from SVN to git

[Michael Shuler]

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

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


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


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

Michael

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

Daniel referred me to the GitBox self service system.

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

command failed: r922600
git checkout -f master

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

Jon

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


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

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


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

Michael

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



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

actually

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



Yes. I need the history in *git*.


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

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



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






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

Re: moving the site from SVN to git

[Michael Shuler]

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


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


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


Michael

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

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

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


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

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

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

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

Michael

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

Daniel referred me to the GitBox self service system.

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

but

after a couple hours it died with this message:

command failed: r922600
git checkout -f master

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

you'll

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

again

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

Jon

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


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

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


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

Michael

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



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

actually

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



Yes. I need the history in *git*.


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

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



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






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






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

Re: moving the site from SVN to git

[Michael Shuler]

committed! :)

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

Michael

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

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

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


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

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

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

Michael

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

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

me

:)

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


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

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

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

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

Michael

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

Daniel referred me to the GitBox self service system.

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

but

after a couple hours it died with this message:

command failed: r922600
git checkout -f master

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

you'll

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

size

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

again

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

you

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

Jon

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


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

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

mich...@pbandjelly.org>

wrote:


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

migrations

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

Michael

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



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

actually

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



Yes. I need the history in *git*.


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



-

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



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






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






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






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

Re: Can we kick off a release?

[Michael Shuler]

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

Thanks,
Michael

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

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