It's not marked fixed, it's marked resolved and the resolution is duplicate.
This is how all dupes are marked in jira.
On Fri, Nov 18, 2016 at 2:30 PM, Edward Capriolo
wrote:
> These tickets claim to duplicate each other:
>
>
These tickets claim to duplicate each other:
https://issues.apache.org/jira/browse/CASSANDRA-12674
https://issues.apache.org/jira/browse/CASSANDRA-12746
But one is marked fixed and the other is still open.
What is the status here?
On Thu, Nov 17, 2016 at 5:20 PM, DuyHai Doan
s/materialised views/aggregates/
also we expect to have our first larger production 3.7 LTS cluster in the
next few months.
On Thu, 17 Nov 2016 at 15:38 Ben Bromhead wrote:
> We have a few small customers clusters running on our 3.7 LTS release...
> though we are not
We have a few small customers clusters running on our 3.7 LTS release...
though we are not calling it production ready yet.
We also just moved our internal metrics cluster from 2.2 to 3.7 LTS to get
materialised views and to get some 3.x production experience.
On Thu, 17 Nov 2016 at 14:27 Carlos
No Cluster in tick-tock.
Actually reverted a couple to 3.0.x
Regards,
Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
Pythian - Love your data
rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
*linkedin.com/in/carlosjuzarterolo
Be very careful, there is a serious bug about AND/OR semantics, not solved
yet and not going to be solved any soon:
https://issues.apache.org/jira/browse/CASSANDRA-12674
On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa
wrote:
>
> We’ll be voting in the very near future on
We should continue with 3.X until all the 4.0 blockers have been
>> committed - and there are quite a few of them remaining yet.
>
>
And… are we right to presume that all the "roadmap 4.0" issues that don't
break any compatibility will be released in the 3.X tock releases leading
up to 4.0?
@Jeff
"But since you asked, I have ONE tick/tock (3.9) cluster being qualified
for production because it needs SASI."
You are brave :)
On Thu, Nov 17, 2016 at 10:32 AM, Jeff Jirsa
wrote:
>
> We’ll be voting in the very near future on timing of major releases and
>
We’ll be voting in the very near future on timing of major releases and release
strategy. 4.0 won’t happen until that vote takes place.
But since you asked, I have ONE tick/tock (3.9) cluster being qualified for
production because it needs SASI.
- Jeff
On 11/17/16, 9:59 AM, "Jonathan
I think it might be worth considering adopting the release strategy before
4.0 release. Are any PMC members putting tick tock in prod? Does anyone
even trust it? What's the downside of changing the release cycle
independently from 4.0?
On Thu, Nov 17, 2016 at 9:03 AM Jason Brown
Jason,
That's a separate topic, but we will have a different vote on how the
branching/release strategy should be for the future.
On Thursday, November 17, 2016, jason zhao yang
wrote:
> Hi,
>
> Will we still use tick-tock release for 4.x and 4.0.x ?
>
> Stefan
Hi,
Will we still use tick-tock release for 4.x and 4.0.x ?
Stefan Podkowinski 于2016年11月16日周三 下午4:52写道:
> 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
>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
Agreed. As long as we have a goal I don't see why we have to adhere to
arbitrary date for 4.0.
On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" wrote:
> I’ll comment on the broader issue, but right now I want to elaborate on
> 3.11/January/arbitrary cutoff date.
>
> Doesn’t
On 16 November 2016 at 11:45, Aleksey Yeschenko
wrote:
>
> Doesn’t matter what the original plan was. We should continue with 3.X
> until all the 4.0 blockers have been
> committed - and there are quite a few of them remaining yet.
Thanks for the clarity, the quick
I’ll comment on the broader issue, but right now I want to elaborate on
3.11/January/arbitrary cutoff date.
Doesn’t matter what the original plan was. We should continue with 3.X until
all the 4.0 blockers have been
committed - and there are quite a few of them remaining yet.
So given all the
On Sun, Nov 13, 2016 at 1:13 AM, Ben Slater wrote:
> For anyone that’s interested, I’ve submitted my doc changes for point 2
> below (emphasising contributions other than new features) here:
> https://issues.apache.org/jira/browse/CASSANDRA-12906
>
> I haven’t added
For anyone that’s interested, I’ve submitted my doc changes for point 2
below (emphasising contributions other than new features) here:
https://issues.apache.org/jira/browse/CASSANDRA-12906
I haven’t added anything about the sponsor/shepherd idea as doesn’t seem to
be agreed at this point.
>
> I strongly feel that there should be a better way e.g. a summary field in
> JIRA which filters out the discussions, arguments, solutions etc.and just
> crisply summarizes the problem, solution under discussion and the current
> status.
I've personally found that attaching a design doc for
Thanks for the information Jeremy.
My main concern is around making JIRAs easy to understand. I am not sure how
community feels about it. But, I have personally observed that long discussion
thread on JIRAs is not user friendly for someone trying to understand the
ticket or may be trying to
Regarding low hanging fruit, on the How To Contribute page [1] we’ve tried to
keep a list of lhf tickets [2] linked to help people get started. They are
usually good starting points and don’t require much context. I rarely see
duplicates from lhf tickets.
Regarding duplicates, in my
Hi,
We need to understand that time is precious for all of us. Even if a developer
has intentions to contribute, he may take months to contribute his first patch
or may be longer. Some common entry barriers are:
1. Difficult to identify low hanging fruits. 30 JIRA comments on a ticket and a
I like the idea of a goal-based approach. I think that would make
coming to a consensus a bit easier particularly if a larger number of
people are involved.
On Tue, Nov 8, 2016 at 8:04 PM, Dikang Gu wrote:
> My 2 cents. I'm wondering is it a good idea to have some high level
My 2 cents. I'm wondering is it a good idea to have some high level goals
for the major release? For example, the goals could be something like:
1. Improve the scalability/reliability/performance by X%.
2. Add Y new features (feature A, B, C, D...).
3. Fix Z known issues (issue A, B, C, D...).
I
Also https://issues.apache.org/jira/browse/CASSANDRA-12676
--
Jeff Jirsa
> On Nov 4, 2016, at 11:51 AM, Jason Brown wrote:
>
> +1 to epaxos
>
>> On Fri, Nov 4, 2016 at 11:40 AM, Jonathan Haddad wrote:
>>
>> epaxos would be nice, it's been about
Recently there was another discussion on documentation and comments [1]
On one hand, documentation and comments will help newcomers to familiarise
themselves with the codebase. On the other - one may get up to speed by
reading the code and adding some docs. Such things may require less
oversight
Agreed.
--
AY
On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com) wrote:
‘Accepted’ JIRA status seems useful, but would encourage something more
explicit like ‘Concept Accepted’ or similar to denote that the concept is
agreed upon, but the actual patch itself may not be
‘Accepted’ JIRA status seems useful, but would encourage something more
explicit like ‘Concept Accepted’ or similar to denote that the concept is
agreed upon, but the actual patch itself may not be accepted yet.
/bikeshed.
On 11/7/16, 2:56 AM, "Ben Slater" wrote:
Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a
better name).
One other thing I noted from the Mesos process - they have an “Accepted”
jira status that comes after open and means “at least one Mesos developer
thought that the ideas proposed in the issue are worth pursuing
Hi Ben,
A few ideas to add to your suggestions [inline]:
On 2016-11-06 13:51 (-0800), Ben Slater wrote:
> Hi All,
>
> I thought I would add a couple of observations and suggestions as someone
> who has both personally made my first contributions to the project in
Ben,
Thank you for providing two thoughtful, concrete recommendations.
There is some good feedback in general on this thread, but I'm calling
Ben's response out because point #1 is important to discuss and point
#2 is immediately actionable.
> 1) I think some process of assigning a committer of a
Hi All,
I thought I would add a couple of observations and suggestions as someone
who has both personally made my first contributions to the project in the
last few months and someone in a leadership role in an organisation
(Instaclustr) that is feeling it’s way through increasing our
On 11/04/2016 06:43 PM, Jeff Beck wrote:
> I run the local Cassandra User Group and I would love to help get the
> community more involved. I would propose holding a night to add patches to
> Cassandra some will be simple things like making sure some asserts have
> proper messages with them etc,
On Sat, Nov 5, 2016 at 9:19 AM, Benedict Elliott Smith
wrote:
> Hi Ed,
>
> I would like to try and clear up what I perceive to be some
> misunderstandings.
>
> Aleksey is relating that for *complex* tickets there are desperately few
> people with the expertise necessary to
Hi Tyler,
There is a nice guide now in the docs on how to contribute[1].
If you try it and find holes you can also help by contributing to those
docs.
-Jake
[1]: http://cassandra.apache.org/doc/latest/development/index.html
On Sat, Nov 5, 2016 at 11:08 AM, Tyler Tolley
Just want to weigh in my 2 cents. I've been following the dev list for
quite a while and wanted to contribute. As I approached trying to handle
some lhf, I couldn't find any instructions on how to check out, build, test
or any guidance on coding standards and best practices. Maybe these existed
Hi Ed,
I would like to try and clear up what I perceive to be some
misunderstandings.
Aleksey is relating that for *complex* tickets there are desperately few
people with the expertise necessary to review them. In some cases it can
amount to several weeks' work, possibly requiring multiple
"I’m sure users running Cassandra in production would prefer actual proper
reviews to non-review +1s."
Again, you are implying that only you can do a proper job.
Lets be specific here: You and I are working on this one:
https://issues.apache.org/jira/browse/CASSANDRA-10825
Now, Ariel reported
I run the local Cassandra User Group and I would love to help get the
community more involved. I would propose holding a night to add patches to
Cassandra some will be simple things like making sure some asserts have
proper messages with them etc, but some may be slightly larger. The goal
being
Dunno. A sneaky correctness or data corruption bug. A performance regression.
Or something that can take a node/cluster down.
Of course no process is bullet-proof. The purpose of review is to minimise the
odds of such a thing happening.
I’m sure users running Cassandra in production would
"There is also the issue of specialisation. Very few people can be trusted
with review of arbitrary
Cassandra patches. I can count them all on fingers of one hand."
I have to strongly disagree here. The Cassandra issue tracker is over
12000 tickets. I do not think that cassandra has added 12000
I’m sure that impactful, important, and/or potentially destabilising patches
will continue getting reviewed
by those engineers.
As for patches that no organisation with a strong enough commercial interest
cares about, they probably won’t.
Engineering time is quite expensive, most employers are
This has always been a concern. We’ve always had a backlog on unreviewed
patches.
Reviews (real reviews, not rubber-stamping a +1 formally) are real work, often
taking as much work
as creating the patch in question. And taking as much expertise (or more).
It’s also not ‘fun’ and doesn’t lend
To be clear, getting the community more involved is a super hard,
critically important problem to which I don't have a concrete answer
other than I'm going to keep reaching out for opinions, ideas and
involvement.
Just like this.
Please speak up here if you have ideas on how this could work.
On
Hi Stefan,
Thank you very much for bringing this up. I moved this to a new thread
because, though closely related, I think it is a very important
discussion to have on it's own as it does have a big impact.
Thanks,
-Nate
On Sat, Nov 5, 2016 at 9:15 AM, Stefan Podkowinski
[Moved to a new thread because this topic is important by itself]
There are some excellent points here - thanks for bringing this up.
> What can inspiring developers contribute to 4.0
> that would move the project forward to it’s goals and would be very likely
> included in the final release?
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
+1 to epaxos
On Fri, Nov 4, 2016 at 11:40 AM, Jonathan Haddad wrote:
> epaxos would be nice, it's been about 2 years since it was started, and
> Blake asked for a first review well over a year ago. the benchmarks and
> thorough test suite look like a huge improvement over
epaxos would be nice, it's been about 2 years since it was started, and
Blake asked for a first review well over a year ago. the benchmarks and
thorough test suite look like a huge improvement over the current situation.
https://issues.apache.org/jira/browse/CASSANDRA-6246
On Fri, Nov 4, 2016
I would like to propose features around seeds:
https://issues.apache.org/jira/browse/CASSANDRA-12627
I have other follow up issues like getting seeds from Amazon API, or from
JNDI/ DNS, etc.
I was hoping 12627 was an easy way to grease the wheels.
On Fri, Nov 4, 2016 at 8:39 AM, Jason Brown
Hey Nate,
I'd like to add CASSANDRA-11559 (Enhance node representation) to the list,
including the comment I made on the ticket (different storage ports for
each node). For us, it's a great "would really like to have" as our group
will probably need this in production within the next 1 year or
List looks really good. I will let you know if there is something else we
plan to add to this list.
On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall wrote:
> It was brought up recently at the PMC level that our goals as a
> project are not terribly clear.
>
> This is a pretty
52 matches
Mail list logo