tldr; make sure to read the new instructions in the .circleci directory,
if you’re a circleci user:
It’s been a while since I last reached out on dev- regarding proposed
changes to our CircleCI setup . Meanwhile Marcus and I have
Previous discussion can be found here:
On 11.02.19 19:58, Ariel Weisberg wrote:
Do you mean Python 2/3 compatibility?
This has been discussed earlier and I think
4 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
What are we voting on here? Rele
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
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
I don't see any reason to have any keys in there, except from release
managers who are signing releases. Additional keys from other developers
may even harm security, by creating more opportunities for compromising
On 07.01.19 11:29, Mick Semb Wever wrote:
And when should it get
Thanks Benedict and everyone involved putting up the proposal! It really
deserves some more feedback and I realize that I'm a bit late for that
and probably missed a good deal of the conversation so far. I'd still
like to share some of my notes that I've taken while reading through it,
Thanks for sorting out components across all these tickets. I really
like the idea of having predefined reports.
Looking at how tickets are grouped between 4.0, 4.0.x and 4.x, we should
probably do some cleanup for the "fix version" attribute as well. We use
to set a ultimate version once a patch
My goal for a side car would be to enable more people to contribute to
the project, by making it more accessible for anyone who’s not familiar
with the Cassandra code base, or not familiar with Java development in
general. Although most of the functionality described in the proposal
I'd like to give you a quick update on the work that has been done
lately on running tests using CircleCI. Please let me know if you have
any objections or don't think this is going into the right direction, or
have any other feedback!
We've been using CircleCI for a while now and results are
There already have been some discussions on this here:
The mentioned blocker there on the token allocation shouldn't exist
anymore. Although it would be good to get more feedback on it, in case
we want to enable it by default, along with new
Does it have to be a single project with functionality provided by
multiple plugins? Designing a plugin API at this point seems to be a bit
early and comes with additional complexity around managing plugins in
I was more thinking into the direction of: "what can we do to enable
I really don't see any benefit at all in having any additional Java 1.7
specific build and testing changes for the 2.2 branch. The 2.2 version
is reaching EOL and will only get critical patches until then anyways. I
also can't remember any reports on regressions in 2.2 bug fix releases
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
 for creating releases (tarballs and native packages), would need
significant work to add support for an
On 18.08.18 17:44, Sankalp Kohli wrote:
> The thread for side car is months old and no one has opposed to it and hence
> someone developed it. I am not sure how else you get consensus.
> Regarding separate repo, how do we get consensus?
>> On Aug 18, 2018, at 05:19, Stef
I don't see that we have reached sufficient consensus on this yet. We've
had a brief discussion about the pros and cons of in-tree cassandra vs
separate ASF repo here, but let's not frame it like it's either or. From
my perspective, there hasn't been any final decision yet whether the
+1 for worklog option
Here's an example ticket from Arrow, where they seem to be using the
On 05.08.2018 09:56, Mick Semb Wever wrote:
>> I find this a bit annoying while subscribed to commits@,
>> especially since we created pr@
On 30.07.2018 02:04, Scott Andreas wrote:
> I’m curious on the dev community’s thoughts on how best to organize
> information like this. My thinking is that by having a space to share this,
> the community can be more informed on each others’ work toward testing, build
> health, and active
Looks like we had some active PRs recently to discuss code changes in
detail on GitHub, which I think is something we agreed is perfectly
fine, in addition to the usual Jira ticket.
What bugs me a bit is that for some reasons any comments on the PR would
be posted to the Jira ticket as well. I'm
(assuming merging patches on documentation will always be possible, as
it's not effecting the code base)
On 11.07.18 23:46, sankalp kohli wrote:
> As discussed in the thread, we are proposing that we will not branch
> on 1st September but will only allow following merges into
These are some valid concerns. But I don’t really see it that way after
thinking about it. We already have restrictions and consensus based
practices in place that may discourage new contributors. E.g. if someone
submits a patch to enable a different GC by default in 2.1, that’s
probably not going
On 02.07.2018 22:10, Michael Shuler wrote:
> I propose the following artifacts for release as 2.2.13.
> sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
Jaydeep, thanks for taking this discussion to the dev list. I think it's
the best place to introduce new idea, discuss them in general and how
they potentially fit in. As already mention in the ticket, I do share
your assessment that we should try to improve making operational issue
Sounds like an older issue that I tried to address two years ago:
As you can see, the result hasn't been as expected and we got some
unintended side effects based on the patch. I'm not sure I'd be willing
to give this another try, considering
right Java version -
>> and not let the package manger just pull the newest available.
>> The version-string from adoptopenjdk for example is one of these “minor
>> Robert Stupp
>> On 28. May 2018, at 15:46, S
The main issue that I see, for supporting both Java 8 + 11, is testing.
We should first decide how this would effect builds.apache.org, or how
we're going to do CI testing in general for that situation.
There are probably also smaller issues that we're not aware of yet, such
as which Java
Maybe people would have preferred to know early about potential
deadlines, before investing a lot of time into "pet ticket"
contributions? It's hard enough to make assumptions about if and when
contributions make it into a release, but with feature freeze deadlines
falling from the sky any time,
June is too early.
On 05.04.18 19:32, Josh McKenzie wrote:
> Just as a matter of perspective, I'm personally mentally diffing from
> when 3.0 hit, not 3.10.
>> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
>> Author: T Jake Luciani
>> Date: Fri Nov 6 14:38:34 2015 -0500
I think it's pretty safe to assume that Java 8 will stay around much
longer than by the end of the year, after Oracle dropped their official
maintainer role. I also think that we don't have to worry that much how
exactly Java 8 is going to be supported. It's a mature enough version
that I wouldn't
The idea was not about building a custom JDK and ship it along with
Cassandra, rather than using the new modular run-time images feature 
introduced in Java 9. See also the link posted by Jason  for an
On 21.03.2018 15:41, Ariel Weisberg wrote:
> I'm not clear on what building and bundling our own JRE/JDK accomplishes?
If we talk about OpenJDK, there will be only a single Java version
supported at any time and that is the latest Java version (11, 12, ..).
There is no overlap between supported
There's also another option, which I just want to mention here for the
sake of discussion.
Quoting the Oracle Support Roadmap:
"Instead of relying on a pre-installed standalone JRE, we encourage
application developers to deliver JREs with their applications."
I've played around with Java 9 a
Are you suggesting to move all messages currently logged via debug() to
info() with the additional marker set, or only particular messages?
On 19.03.2018 19:51, Paulo Motta wrote:
> Thanks for the constructive input and feedback! From this discussion
> it seems like overloading the DEBUG level
I'd agree that INFO should be the default. Turning on the DEBUG logging
can cause notable performance issues and I would not enable it on
production systems unless I really have to. That's why I created
CASSANDRA-12696 for 4.0, so you'll be able to at least only partially
enable DEBUG based on
>> Comments Inline: Thanks for giving this a go!!
>>> On Jan 2, 2018, at 6:10 AM, Stefan Podkowinski <s...@apache.org> wrote:
>>> I was giving this a try today with some mixed results. First of all,
I was giving this a try today with some mixed results. First of all,
running pytest locally would fail with an "ccmlib.common.ArgumentError:
Unknown log level NOTSET" error for each test. Although I created a new
virtualenv for that as described in the readme (thanks for updating!)
and use both of
There's nothing that stops people from using github to discuss code
changes. Many jiras already link to gh branches that can be used to
review and comment code. But it's not always the best place to do so.
The high level discussion should always take place on Jira. Although I'd
have no problem to
assing. having logic you need
>> to fix in 3 repos isn’t ideal at all.
>>> On Nov 27, 2017, at 4:05 AM, Stefan Podkowinski <s...@apache.org> wrote:
>>> Just wanted to bring a recent discussion about how to use ccm from
Just wanted to bring a recent discussion about how to use ccm from
dtests to your attention:
Basically the idea is to not depend on a released ccm artifact, but to
use a dedicated git branch in the ccm repo instead for executing dtests.
I've been recently looking into how we could improve security in
Cassandra by integrating external solutions. There are very interesting
projects out there, such as Vault, but also a growing list of
security related APIs offered by cloud providers.
Today Cassandra can already be customized by
Introducing feature flags for enabling or disabling different code paths
is not sustainable in the long run. It's hard enough to keep up with
integration testing with the couple of Jenkins jobs that we have.
Running jobs for all permutations of flags that we keep around, would
Can we forward notifications for the new cassandra-dtest repo there as well?
On 24.03.2017 18:59, Jeff Jirsa wrote:
> With 6 binding +1s, 6 non-binding +1s, and no -1s of any kind, the vote
> passes, I'll ask for a new mailing list and get this transitioned.
> - Jeff
> On 2017-03-20 15:32
Thanks your responses! Seems like all of you prefer to have both trivial
and non-trivial updates in CHANGES.txt. I'm going to keep that in mind,
but will continue to omit them for documentation edits.
On 18.07.2017 23:49, kurt greaves wrote:
> I agree that all patches should be added to
Has there been any consensus in the past about what goes into
CHANGES.txt and what not? My naive assumption was that the intended
audience for the file are users who want to know about changes between
new releases. Having that in mind, I skipped changes.txt once in a while
for updates that have no
I haven't been able to reproduce this on Ubuntu or CentOS. Which OS do
you use? Did you install a pre-build package or tarball?
On 18.07.2017 11:43, Micha wrote:
> when calling sstabledump from cassandra 3.11 I get the error:
> "There is an incompatible JNA native library
Thanks for being interested in contributing to Apache Cassandra.
Creating a new compaction strategy is not an easy task and there are
several things you can do to make it more obvious for other developers
to understand what you're up to.
First of all, if using github, changes to the
I'd suggest to use the git docs for the new pages, so we can accept pull
requests for adding other plugins. 
We can also link there from the main pages. Maybe the community page
would be a good place for that.
Just a quick heads up for everyone interested in the jobs history at
builds.apache.org or who wants to run devbranch jobs there. A couple of
Jenkins nodes are not working correctly, which is causing jobs to abort
abnormally during start. You'd either have to rebuild until you hit a
On 31.05.2017 09:34, Stefania Alborghetti wrote:
> There shouldn't be too many people with 3.0.13 in
> production however, since upgrading to 3.0.13 is broken in the first place.
Keep in mind that there are always people upgrading from 2.x, especially
since we had a couple of important bug fixes
I don't see any reasons not to make this part of our guidelines. The
idea of having a list of what should be tested in each kind of test
makes sense. I also like the examples how to improve tests dealing with
Some of the integration test cases, such as "dry
As nobody seems to object, you can now find a patch for the proposed
document in the corresponding Jira ticket:
On 03/17/2017 08:33 PM, Stefan Podkowinski wrote:
> There's recently been a discussion about the wiki and how we sho
reset --soft origin/trunk
git commit (add proper commit message and a "Merges #" text to
automatically close the PR)
On 03/17/2017 09:03 PM, Jeff Jirsa wrote:
> On 2017-03-17 12:33 (-0700), Stefan Podkowinski <s...@apache.org> wrote:
>> As you can se
There's recently been a discussion about the wiki and how we should
continue to work on the documentation in general. One of my suggestions
was to start giving users a clearer guideline how they are able to
contribute to our documentation, before having a technical discussion
around tools and
> We're thankfully still in a place where these tickets are at least being
> created, but unless there's a body of people that are digging in to fix
> those test failures they're just going to keep growing.
> On Fri, Mar 10, 2017 at 5:03 AM, Stefan Podkowinsk
Agreed. Let's not give up on this as quickly. My suggestion is to at
least provide a getting started guide for writing docs, before
complaining about too few contributions. I'll try to draft something up
What people are probably not aware of is how easy it is to contribute
If I remember correctly, the requirement of providing test results along
with each patch was because of tick-tock, where the goal was to have
stable release branches at all times. Without CI for testing each
individual commit on all branches, this just won't work anymore. But
would that really be
I think the best way to catch up with the motivation behind this is by
reading the following dev post and linked jiras:
What are your suggestions to improve
t think we should force a major just because n months have
> >passed. I think we should up the major only when we have significant
> > (possibly breaking) changes/features. It would seem odd to have a 6.0
> >that's basically the same as 4.0 (in terms of features and
I honestly don't understand the release cadence discussion. The 3.x branch
is far from production ready. Is this really the time to plan the next
major feature releases on top of it, instead of focusing to stabilize 3.x
first? Who knows how long that would take, even if everyone would
I’d like to suggest an option similar to what Jeremiah described and that
would basically follow the Ubuntu LTS release model , but with shorter
time periods. The idea would be to do a stable release every 6 months with
1 year bug fixing support. At the same time, every third stable release
>From my understanding, this will also effect EOL dates of other branches.
"We will maintain the 2.2 stability series until 4.0 is released, and 3.0
for six months after that.".
On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall wrote:
> Agreed. As long as we have a goal I don't
There has been a lot of discussions about diversity and getting new
contributors and I think this aspect should be kept in mind as well when
talking about a roadmap, additionally to the listed tickets that are
already in the pipeline. What can inspiring developers contribute to 4.0
that would move
>From my perspective, one of the most important reasons for RxJava would be
the strategic option to integrate reactive streams  in the overall
Cassandra architecture at some point in the future. Reactive streams would
allow to design back pressure fundamentally different compared to what we
Mail list logo