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

2016-11-11 Thread Eduard Tudenhoefner
-1 because internode_encryption is broken due to
https://issues.apache.org/jira/browse/CASSANDRA-12903

On Wed, Nov 9, 2016 at 9:16 PM, Jeff Jirsa 
wrote:

> -1 as well, #12877
>
>
>
> On 11/9/16, 5:20 AM, "Oleksandr Petrov" 
> wrote:
>
> >-1
> >
> >Sorry but I have to -1 that one, with the following explanation
> >
> >One of the features in 3.10 breaks SASI in quite a significant way. The
> >issue was introduced in #11990 [1] and described in #12877 [2]. If there
> >are more than 8 items in partition that have same index value, index file
> >will get corrupted and returned results will be incorrect.
> >
> >I think we should rather revert the patch and go ahead with a release
> >without it and change the patch to work correctly, possibly making it's
> >scope slightly bigger. I am working on a design document for the change.
> >
> >[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.
> apache.org_jira_browse_CASSANDRA-2D11990&d=DgIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_
> RF8g3otJoEFCZNVwQ38FDLHoRH2WpE&s=1LFYHLGHFPYzM7jDJ56_
> 7SKYBJIqpCHsxr0taxZ3nS4&e=
> >[2] https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.
> apache.org_jira_browse_CASSANDRA-2D12877&d=DgIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_
> RF8g3otJoEFCZNVwQ38FDLHoRH2WpE&s=1YjohT2-dB9Ye9MXGCUpVsGY6Ot1CH9v_
> PSHPS2eUkE&e=
> >
> >On Wed, Nov 9, 2016 at 11:19 AM Gary Dusbabek 
> wrote:
> >
> >> +1
> >>
> >> On Tue, Nov 8, 2016 at 8:09 PM, Michael Shuler 
> >> wrote:
> >>
> >> > I propose the following artifacts for release as 3.10.
> >> >
> >> > sha1: 072b5271a88328b909b230d0e30df1c7476fdb3f
> >> > Git:
> >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git-
> 2Dwip-2Dus.apache.org_repos_asf-3Fp-3Dcassandra.git-3Ba-3D&d=DgIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_
> RF8g3otJoEFCZNVwQ38FDLHoRH2WpE&s=Yf3E6uBirmkRTS3IE9xB7oPxz0EpbO
> c1rdiF9-qei-8&e=
> >> > shortlog;h=refs/tags/3.10-tentative
> >> > Artifacts:
> >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> repository.apache.org_content_repositories_&d=DgIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_
> RF8g3otJoEFCZNVwQ38FDLHoRH2WpE&s=V5SCV7GU7VFuWN4xr05zJpEUaz2FoP
> WBjlZQRZtLXDE&e=
> >> > orgapachecassandra-1133/org/apache/cassandra/apache-cassandra/3.10/
> >> > Staging repository:
> >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> repository.apache.org_content_repositories_&d=DgIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_
> RF8g3otJoEFCZNVwQ38FDLHoRH2WpE&s=V5SCV7GU7VFuWN4xr05zJpEUaz2FoP
> WBjlZQRZtLXDE&e=
> >> > orgapachecassandra-1133/
> >> >
> >> >
> >> >
> >> > The Debian packages are available here:
> >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__people.
> apache.org_-7Emshuler&d=DgIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
> hAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD
> 5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_RF8g3otJoEFCZNVwQ38FDLHoRH2WpE
> &s=tcexRsY-LYWRWDsXlNurHM0-GsKvwf4CQsz52uGNCcI&e=
> >> >
> >> >
> >> >
> >> > The vote will be open for 72 hours (longer if needed).
> >> >
> >> >
> >> >
> >> > [1]: (CHANGES.txt) https://urldefense.proofpoint.
> com/v2/url?u=https-3A__goo.gl_TZa9a7&d=DgIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_
> RF8g3otJoEFCZNVwQ38FDLHoRH2WpE&s=EJsg6DC55Ir-
> 63UXhcs2eTtjm8UwxU13WmDWyoqD62Q&e=
> >> >
> >> > [2]: (NEWS.txt) https://urldefense.proofpoint.
> com/v2/url?u=https-3A__goo.gl_FSI1a4&d=DgIBaQ&c=
> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=ibGDVaeFlUoJ_
> RF8g3otJoEFCZNVwQ38FDLHoRH2WpE&s=FXC91mnGnVTHsJd3v6wJ2isKVd2PEB
> H78JUyQtYDVyo&e=
> >> >
> >>
> >--
> >Alex Petrov
>



-- 

[image: DataStaxLogo copy3.png] 

Eduard Tudenhoefner

Software Engineer | +49 151 206 111 97 | eduard.tudenhoef...@datastax.com



 

 


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

2016-11-11 Thread Jake Luciani
-1 due to https://issues.apache.org/jira/browse/CASSANDRA-11039

It's a small fix but a critical bug. I'll patch shortly

On Nov 11, 2016 2:32 AM, "Tommy Stendahl" 
wrote:

> +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=sho
>> rtlog;h=refs/tags/3.0.10-tentative
>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapache
>> cassandra-1132/org/apache/cassandra/apache-cassandra/3.0.10/
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapache
>> cassandra-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: [VOTE] Release Apache Cassandra 3.0.10 (Take 2)

2016-11-11 Thread Jake Luciani
Should I merge the fix to just the 3.0.10 tag? or should we include the 3
new tickets that went into 3.0.11 already? I see no issue with the latter
since they are bugfixes

On Fri, Nov 11, 2016 at 8:48 AM, Jake Luciani  wrote:

> -1 due to https://issues.apache.org/jira/browse/CASSANDRA-11039
>
> It's a small fix but a critical bug. I'll patch shortly
>
> On Nov 11, 2016 2:32 AM, "Tommy Stendahl" 
> wrote:
>
>> +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=sho
>>> rtlog;h=refs/tags/3.0.10-tentative
>>> Artifacts:
>>> https://repository.apache.org/content/repositories/orgapache
>>> cassandra-1132/org/apache/cassandra/apache-cassandra/3.0.10/
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapache
>>> cassandra-1132/
>>>
>>> The Debian packages are available here: http://people.apache.org/~mshu
>>> ler
>>>
>>> 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
>>>
>>>
>>


-- 
http://twitter.com/tjake


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

2016-11-11 Thread Michael Shuler
I think cassandra-3.0 HEAD is good with me, too. We can adjust the
fixver for those that may say 3.0.11 currently.

-- 
Michael

On 11/11/2016 08:31 AM, Jake Luciani wrote:
> Should I merge the fix to just the 3.0.10 tag? or should we include the 3
> new tickets that went into 3.0.11 already? I see no issue with the latter
> since they are bugfixes
> 
> On Fri, Nov 11, 2016 at 8:48 AM, Jake Luciani  wrote:
> 
>> -1 due to https://issues.apache.org/jira/browse/CASSANDRA-11039
>>
>> It's a small fix but a critical bug. I'll patch shortly
>>
>> On Nov 11, 2016 2:32 AM, "Tommy Stendahl" 
>> wrote:
>>
>>> +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=sho
 rtlog;h=refs/tags/3.0.10-tentative
 Artifacts:
 https://repository.apache.org/content/repositories/orgapache
 cassandra-1132/org/apache/cassandra/apache-cassandra/3.0.10/
 Staging repository:
 https://repository.apache.org/content/repositories/orgapache
 cassandra-1132/

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

 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: [VOTE FAILED] Release Apache Cassandra 3.10 (Take 2)

2016-11-11 Thread Michael Shuler
Thanks for all the feedback, I'm changing to a -1, too.

Vote comes to 1 binding +1, 3 binding -1, 3 non-binding -1.

-- 
Kind regards,
Michael

On 11/08/2016 02:09 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.10.
> 
> sha1: 072b5271a88328b909b230d0e30df1c7476fdb3f
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1133/org/apache/cassandra/apache-cassandra/3.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1133/
> 
> 
> 
> 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/TZa9a7
> 
> [2]: (NEWS.txt) https://goo.gl/FSI1a4
> 



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

2016-11-11 Thread Michael Shuler
For the record, I'm changing my vote to a -1, as well.

-- 
Michael

On 11/11/2016 09:40 AM, Michael Shuler wrote:
> I think cassandra-3.0 HEAD is good with me, too. We can adjust the
> fixver for those that may say 3.0.11 currently.
> 



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

2016-11-11 Thread Aleksey Yeschenko
-1 for the reasons listed.

—
AY

On 11 November 2016 at 16:59:04, Michael Shuler (mich...@pbandjelly.org) wrote:

For the record, I'm changing my vote to a -1, as well.  

--  
Michael  

On 11/11/2016 09:40 AM, Michael Shuler wrote:  
> I think cassandra-3.0 HEAD is good with me, too. We can adjust the  
> fixver for those that may say 3.0.11 currently.  
>  



New 'cassandra-builds' git repo, or in-tree?

2016-11-11 Thread Michael Shuler
We're working on configuring new donated servers for Apache Cassandra
testing in the ASF Jenkins infrastructure. I have a preference to
request INFRA set up a new git repository specifically for
build/test_run/jenkins_template scripts, separate from the main Apache
Cassandra source, but I'm wondering how others feel about these just
being in-tree. If you have an opinion one way or the other, I'm interested.

I think a separate git repo would be preferable since the contents could
be used for any version, regardless of the checked out C* branch or sha,
it won't require backporting, and it will be tiny. It may also allow a
lower barrier for contributors interested in helping with specifically
build/test infrastructure.

Thanks!
Michael


Re: New 'cassandra-builds' git repo, or in-tree?

2016-11-11 Thread Jeffrey Jirsa
+1 to new repo.


On 11/11/16, 11:55 AM, "Michael Shuler"  wrote:

>We're working on configuring new donated servers for Apache Cassandra
>testing in the ASF Jenkins infrastructure. I have a preference to
>request INFRA set up a new git repository specifically for
>build/test_run/jenkins_template scripts, separate from the main Apache
>Cassandra source, but I'm wondering how others feel about these just
>being in-tree. If you have an opinion one way or the other, I'm
>interested.
>
>I think a separate git repo would be preferable since the contents could
>be used for any version, regardless of the checked out C* branch or sha,
>it won't require backporting, and it will be tiny. It may also allow a
>lower barrier for contributors interested in helping with specifically
>build/test infrastructure.
>
>Thanks!
>Michael




Re: New 'cassandra-builds' git repo, or in-tree?

2016-11-11 Thread Nate McCall
> It may also allow a
> lower barrier for contributors interested in helping with specifically
> build/test infrastructure.

Good point for new repo.

Thanks!


Re: New 'cassandra-builds' git repo, or in-tree?

2016-11-11 Thread Michael Shuler
On 11/11/2016 01:02 PM, Nate McCall wrote:
>> It may also allow a
>> lower barrier for contributors interested in helping with specifically
>> build/test infrastructure.
> 
> Good point for new repo.

Requested a new 'cassandra-builds' git repo! Thanks.

-- 
Michael



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

2016-11-11 Thread Michael Shuler
I count 3 binding +1, 1 non-binding +1, and 3 binding -1 votes. I'll
re-roll a new release, since the CASSANDRA-11039 fix has already been
committed.

-- 
Kind regards,
Michael

On 11/08/2016 02:08 PM, 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
> 



[VOTE] Release Apache Cassandra 3.0.10 (Take 3)

2016-11-11 Thread Michael Shuler
I propose the following artifacts for release as 3.0.10.

sha1: d6a3ef4863142c3f9fc1def911f28341fc78f2e8
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-1134/org/apache/cassandra/apache-cassandra/3.0.10/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1134/

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/4UxyAJ
[2]: (NEWS.txt) https://goo.gl/8tfmEU



signature.asc
Description: OpenPGP digital signature


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

2016-11-11 Thread Jeff Jirsa
+1

-- 
Jeff Jirsa


> On Nov 11, 2016, at 5:36 PM, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 3.0.10.
> 
> sha1: d6a3ef4863142c3f9fc1def911f28341fc78f2e8
> 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-1134/org/apache/cassandra/apache-cassandra/3.0.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1134/
> 
> 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/4UxyAJ
> [2]: (NEWS.txt) https://goo.gl/8tfmEU
> 


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

2016-11-11 Thread Anuj Wadehra
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 contribute to the discussion/fix . 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. Sometimes 
description of the defect is not sufficient.   For a new comer trying to 
understand a JIRA, this summary would be a good start to understand the problem 
upfront and then if you want to go into details, you can understand the long 
JIRA thread.
Also, some JIRAs are in dead state and you don't get a clue what's the current 
status after so much discussion over the ticket? Some JIRAs are neither 
rejected nor validated, so even if its a bug, some people would be reluctant to 
pick JIRAs which have not been validated yet.


ThanksAnuj


 

On Friday, 11 November 2016 1:40 AM, Jeremy Hanna 
 wrote:
 

 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: