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

[Tommy Stendahl]

+1 (non-binding)


On 2016-11-08 21:08, Michael Shuler wrote:

I propose the following artifacts for release as 3.0.10.

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

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

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

[1]: (CHANGES.txt) https://goo.gl/mnmZgI
[2]: (NEWS.txt) https://goo.gl/F1kAmR

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

[Jeremy Hanna]

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 experience those who resolve tickets as duplicates 
are generally pretty good.

I think the safest bet to start is to look at How To Contribute page and the 
lhf labeled tickets.

[1] https://wiki.apache.org/cassandra/HowToContribute 

[2] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved
 


> On Nov 10, 2016, at 12:06 PM, Anuj Wadehra  
> wrote:
> 
> 
> 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 new comer is LOST, even though the exact fix may be much simpler.
> 2. Dead JIRA discussions with no clue on the current status of the ticket.
> 3. No response on new JIRAs raised. Response time  to validate/reject the 
> problem is important. Should I pick? Is it really a bug? Maybe some expert 
> can confirm it first and then I can pick it..
> 4.Ping Pong JIRAs: Your read 10 comments of a ticket then see duplicates and 
> related ones..then read 30 more comments and then so on till you land up on 
> same JIRA which is not concluded yet.
> Possible Solution for above 4 points:
> A. Add a new JIRA field to crisply summarize what conclusive discussion has 
> taken place till now ,what's the status of current JIRA, proposed/feasible 
> solution etc.
> B. Mark low hanging fruits regularly.
> C. Validate/Reject newly reported JIRAs on priority. Using dev list to 
> validate/reject the issue before logging the JIRA??
> D. Make sure that duplicates are real proven duplicates.
> 
> 5. Insufficient code comments. 
> Solution: Coding comments should be a mandatory part of code review 
> checklist. It makes reviews faster and encourage people to understand the 
> flow and fix things on their own.
> 6. Insufficient Design documentation.
> Solution:Detailed documentation for at least new features so that people are 
> comfortable with the design. Reading English and understanding diagrams/flows 
> is much simpler than just jumping into the code upfront.
> 7. No/Little formal communication on active development and way forward.
> Solution: What about a monthly summary of New/Hot/critical JIRAs and new 
> feature development (with JIRA links so that topics of interest are 
> accessible)? 
> 
> ThanksAnuj
> 
> 
>  On Thu, 10 Nov, 2016 at 7:09 AM, Nate McCall wrote:   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 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 feel If we can have the high level goals, it would be easy to pick the
>> jiras to be included in the release.
>> 
>> Does it make sense?
>> 
>> Thanks
>> Dikang.
>> 
>> On Mon, Nov 7, 2016 at 11:22 AM, Oleksandr Petrov <
>> oleksandr.pet...@gmail.com> wrote:
>> 
>>> 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 and can play some role in improving diversity / increasing an
>>> amount of involved people.
>>> 
>>> Same thing with tests. There are some areas where tests need some
>>> refactoring / improvements, or even just splitting them from one file to
>>> multiple. It's a good way to experience the process and get involved into
>>> discussion.
>>> 
>>> For that, we could add some issues with subtasks (just a few for starters)
>>> or even just a wiki page with a doc/test wishlist where everyone could add
>>> a couple of points.
>>> 
>>> Docs and tests could be used in addition to lhf issues, helping people,
>>> having comprehensive and quick process and everything else that was
>>> mentioned in this thread.
>>> 
>>> Thank you.
>>> 
>>> [1]
>>> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%
>>> 3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwks

spark-cassandra-connector support for Spark 2.0.1 Structured Streaming

[shyla deshpande]

Hello everyone,

Anyone able to use Cassandra with structured streaming.  Please help

Thanks

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

[Anuj Wadehra]

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 
new comer is LOST, even though the exact fix may be much simpler.
2. Dead JIRA discussions with no clue on the current status of the ticket.
3. No response on new JIRAs raised. Response time  to validate/reject the 
problem is important. Should I pick? Is it really a bug? Maybe some expert can 
confirm it first and then I can pick it..
4.Ping Pong JIRAs: Your read 10 comments of a ticket then see duplicates and 
related ones..then read 30 more comments and then so on till you land up on 
same JIRA which is not concluded yet.
Possible Solution for above 4 points:
A. Add a new JIRA field to crisply summarize what conclusive discussion has 
taken place till now ,what's the status of current JIRA, proposed/feasible 
solution etc.
B. Mark low hanging fruits regularly.
C. Validate/Reject newly reported JIRAs on priority. Using dev list to 
validate/reject the issue before logging the JIRA??
D. Make sure that duplicates are real proven duplicates.

5. Insufficient code comments. 
Solution: Coding comments should be a mandatory part of code review checklist. 
It makes reviews faster and encourage people to understand the flow and fix 
things on their own.
6. Insufficient Design documentation.
Solution:Detailed documentation for at least new features so that people are 
comfortable with the design. Reading English and understanding diagrams/flows 
is much simpler than just jumping into the code upfront.
7. No/Little formal communication on active development and way forward.
Solution: What about a monthly summary of New/Hot/critical JIRAs and new 
feature development (with JIRA links so that topics of interest are 
accessible)? 

ThanksAnuj

 
  On Thu, 10 Nov, 2016 at 7:09 AM, Nate McCall wrote:   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 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 feel If we can have the high level goals, it would be easy to pick the
> jiras to be included in the release.
>
> Does it make sense?
>
> Thanks
> Dikang.
>
> On Mon, Nov 7, 2016 at 11:22 AM, Oleksandr Petrov <
> oleksandr.pet...@gmail.com> wrote:
>
>> 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 and can play some role in improving diversity / increasing an
>> amount of involved people.
>>
>> Same thing with tests. There are some areas where tests need some
>> refactoring / improvements, or even just splitting them from one file to
>> multiple. It's a good way to experience the process and get involved into
>> discussion.
>>
>> For that, we could add some issues with subtasks (just a few for starters)
>> or even just a wiki page with a doc/test wishlist where everyone could add
>> a couple of points.
>>
>> Docs and tests could be used in addition to lhf issues, helping people,
>> having comprehensive and quick process and everything else that was
>> mentioned in this thread.
>>
>> Thank you.
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%
>> 3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwksinpt6rr9pop...@mail.gmail.com%3E
>>
>> On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko 
>> wrote:
>>
>> > Agreed.
>> >
>> > --
>> > AY
>> >
>> > On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com)
>> > wrote:
>> >
>> > ‘Accepted’ JIRA status seems useful, but would encourage something more
>> > explicit like ‘Concept Accepted’ or similar to denote that the concept is
>> > agreed upon, but the actual patch itself may not be accepted yet.
>> >
>> > /bikeshed.
>> >
>> > On 11/7/16, 2:56 AM, "Ben Slater"  wrote:
>> >
>> > >Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a
>> > >better name).
>> > >
>> > >One other thing I noted from the Mesos process - they have an “Accepted”
>> > >jira status that comes after open and means “at least one Mesos
>> developer
>> > >thought that the ideas proposed in the issue are worth pursuing
>> further”.
>> > >Might also be something to consider as part of a process like this?
>> > >
>> > >Cheers
>> > >Ben
>> > >
>> > >On Mon, 7 Nov 2016 at 09:37 Dave Lester  wrote:
>> > >
>

[GitHub] cassandra pull request #84: removed local bind for outbound connections

[mmajercik]

GitHub user mmajercik opened a pull request:

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

removed local bind for outbound connections

Fix for CASSANDRA-12673

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mmajercik/cassandra 12673-2.2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/84.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #84


commit a3058bce8e8eff7f44205712d93c15eda1548a0b
Author: mmajercik 
Date:   2016-11-10T15:31:03Z

removed local bind for outbound connections




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra issue #83: 12796 2.2

[ifesdjeen]

Github user ifesdjeen commented on the issue:

https://github.com/apache/cassandra/pull/83
  
Cassandra does't take pull requests via github (as the primary repository 
is hosted elsewhere), you have to create an issue and submit a patch via 
https://issues.apache.org/jira/browse/cassandra/. Please see guidelines here: 
https://wiki.apache.org/cassandra/HowToContribute

I apologise for the noise.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra pull request #83: 12796 2.2

[mmajercik]

GitHub user mmajercik opened a pull request:

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

12796 2.2

This is a proposed patch for CASSANDRA-12796

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mmajercik/cassandra 12796-2.2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/83.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #83


commit de57fc5ddc3fffdd6a1eed2dee53a638d5053fab
Author: mmajercik 
Date:   2016-10-14T13:54:02Z

Changed operation group granularity to page rathen than partition when 
rebuilding secondary index

commit f5d4f1cfb8dbaf550bb1685408279cd6935d3cbf
Author: mmajercik 
Date:   2016-11-10T08:22:24Z

replaced tabs with spaces




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra pull request #82: 12796 2.2

[mmajercik]

Github user mmajercik closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra issue #82: 12796 2.2

[ifesdjeen]

Github user ifesdjeen commented on the issue:

https://github.com/apache/cassandra/pull/82
  
It looks like the branch is based on top of Cassandra trunk rather than 
current apollo master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra pull request #82: 12796 2.2

[mmajercik]

GitHub user mmajercik opened a pull request:

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

12796 2.2

This is a proposed fix for CASSANDRA-12796

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mmajercik/cassandra 12796-2.2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/82.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #82


commit caaa9fc82cd51b7321da4dad0715ebc561d180dd
Author: Josh McKenzie 
Date:   2016-04-01T15:46:15Z

Merge branch 'cassandra-2.1' into cassandra-2.2

commit c662259fe9e1e25e10e58eb1146de80c53e69867
Author: Yuki Morishita 
Date:   2016-02-16T18:45:36Z

Use canonical path for directory in SSTable descriptor

patch by yukim; reviewed by Paulo Motta for CASSANDRA-10587

commit 0ac2072bb2cc6d8e069e07f5cbcdf2e83cdc5b5c
Author: Andrzej Ludwikowski 
Date:   2016-03-07T18:27:54Z

DatabaseDescriptor should log stacktrace in case of Eception during seed 
provider creation

patch by Andrzej Ludwikowski; reviewed by jasobrown for CASSANDRA-11312

commit ea9b42e7d7bf9003dd6ed911035d3a85a2d99bac
Author: Benjamin Lerer 
Date:   2016-04-02T15:55:04Z

Fix paging for COMPACT tables without clustering columns

patch by Benjamin Lerer; reviewed by Tyler Hobbs for CASSANDRA-11467

commit 2ed855592ab77399e061f03f73a943aefbd44eaf
Author: Benjamin Lerer 
Date:   2016-04-02T15:59:37Z

Merge branch cassandra-2.1 into cassandra-2.2

commit 1ff9df75c46edb02bf1f994e7ecc651e29b277fb
Author: Marcus Olsson 
Date:   2016-03-24T14:06:23Z

Remove duplicate logging of sending MerkleTree request

Patch by Marcus Olsson; reviewed by marcuse for CASSANDRA-11486

commit a33038be23e4114f5b6f0736887d35656b0aa40f
Author: Ryan Magnusson 
Date:   2016-04-04T12:09:54Z

IncomingStreamingConnection version check message wrong

patch by Ryan Magnusson reviewed by Robert Stupp for CASSANDRA-11462

commit 96c53e0a5e73046acb77e2ac2a3aa9d9ef64fc65
Author: Josh McKenzie 
Date:   2016-04-06T22:37:08Z

Fix launch with whitespace in path on Windows

Patch by jmckenzie; reviewed by pmotta for CASSANDRA-11515

commit 2dd244b439049baa1a9f175237acf802e1946d74
Author: Benjamin Lerer 
Date:   2016-04-11T07:41:44Z

Ninja: fix typo in CommitLog error message

commit e22faeb8c5463a34b630aff8e265aefbe950b58d
Author: Benjamin Lerer 
Date:   2016-04-11T07:43:56Z

Merge branch cassandra-2.1 into cassandra-2.2

commit 3557d2e05c8d1059562de2a91c1b33b4fcfcc6eb
Author: Paulo Motta 
Date:   2016-04-05T19:58:06Z

Make deprecated repair methods backward-compatible with previous 
notification service

patch by Paulo Motta; reviewed by Yuki Morishita for CASSANDRA-11430

commit c1b1d3bccf30a7ee1deb633d2bc2dfbd7b9c542f
Author: Stefania Alborghetti 
Date:   2016-04-08T03:52:17Z

Checking if an unlogged batch is local is inefficient

patch by Stefania Alborghetti; reviewed by Paulo Motta for CASSANDRA-11529

commit ab2b8a60c4b6d27081d632fefa0e19ee13816e2c
Author: Aleksey Yeschenko 
Date:   2016-04-11T18:14:41Z

Merge branch 'cassandra-2.1' into cassandra-2.2

commit 19b4b637ac79b5d53b9384bd95bed8e08b43f111
Author: Jacek Lewandowski 
Date:   2016-04-08T15:31:00Z

CqlConfigHelper no longer requires both a keystore and truststore to work.

patch by Jacek Lewandowski; reviewed by Jeremiah Jordan for CASSANDRA-11532

commit 69edeaa46b78bb168f7e9d0b1c991c07b90f41ca
Author: Alex Petrov 
Date:   2016-04-14T10:26:52Z

Allow only DISTINCT queries with partition keys restrictions

patch by Alex Petrov; reviewed by Benjamin Lerer for CASSANDRA-11339

commit 220e4f62db7fe14c4d6c0e499c52059f7ebc5a53
Author: T Jake Luciani 
Date:   2016-04-15T14:00:04Z

2.2.6 version bump

commit 5c5c5b44c6d952d4d6f8170fa4ef239060275b76
Author: T Jake Luciani 
Date:   2016-04-15T14:30:21Z

2.1.14 version bump

commit 37f63ecc5d3b36fc115fd7ae98e4fc1f4bc2d1d6
Author: T Jake Luciani 
Date:   2016-04-15T14:34:48Z

Merge branch 'cassandra-2.1' into cassandra-2.2

commit 77ab77328e7e263a8e93ff24ff9b5d4be33e7c27
Author: Artem Aliev 
Date:   2016-04-18T14:24:12Z

Always close cluster with connection in CqlRecordWriter

patch by Artem Aliev; reviewed by Aleksey Yeschenko for CASSANDRA-11553

commit d200d137823d5b250406bccb35473a8fc2f14faf
Author: Ruoran Wang 
Date:   2016-04-18T22:49:30Z

Replace sstables on DataTracker before marking them as non-compacting 
during anti-compaction

Patch by Ruoran Wang; reviewed by Paulo Motta for CASSANDRA-11548

commit 209ebd380b641c4f065e9687186f546f8a50b242
Author: Paulo Motta 
Date:   2016-04-18T21:44:07Z

Add unit test for CASSANDRA-11548

Patch by Paulo Motta; reviewed by Marcus Eriksson for CASSANDRA-11548

commit 97a432610f5f57678c69ca674