Proposal to include CASSANDRA-14482 (ZSTD Support) in 4.0 release

[Sushma Devendrappa]

Hi,

I am checking to see if we can include CASSANDRA-1448 in 4.0 release which 
provides ZSTD compressor for Cassandra. Currently changes are under review, 
implementation has unit test coverage similar to other compressors, also tested 
in Instagram’s shadow clusters.
Implementation structure is similar to other Cassandra’s iCompressor, but with 
extra compression_level configuration which is table/CF level. ZSTD supports 
levels 1-22. 1 being fastest and 22 being best at compression ratio.
According to benchmarks most of the use cases that I have tested gives better 
speed with ZSTD  than LZ4 and Deflate at same compression ratio.
ZSTD Compressor changes will not affect any tests, adding it to 4.0 gives an 
advantage to experiment and use ZSTD in production systems and enhance further. 
There is additional discussions on the Jira with a good summary given by Joey 
based on his testing of ZSTD as well.
--Sushma

Re: JIRA Workflow Proposals

[Dinesh Joshi]

I agree with this. I generally am on the side of freedom and responsibility. 
Limiting edits to certain fields turns people off. Something I want to very 
much avoid if we can. 

Dinesh

> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan  
> wrote:
> 
> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>  wrote:
>> 
>>> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
>>> 
>>> Hi,
>>> 
>>> RE #1, does this mean if you submit a ticket and you are not a contributor 
>>> you can't modify any of the fields including description or adding/removing 
>>> attachments?
>> 
>> Attachment operations have their own permissions, like comments.  
>> Description would be prohibited though.  I don’t see this as a major 
>> problem, really; it is generally much more useful to add comments.  If we 
>> particularly want to make a subset of fields editable there is a workaround, 
>> though I’m not sure anybody would have the patience to implement it:  
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>>  
>> 
>> 
> 
> That would be disappointing. Descriptions with broken or no formatting
> aren't rare (say, command output without code formatting). And every
> now and then the description might need to be updated. For example, in
> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
> paper had rotted, but I managed to find a new one, so I could edit it
> in. If such a change had to be posted as a comment, it might easily
> get lost in some of the more active issues.
> 
> -
> 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: JIRA Workflow Proposals

[Murukesh Mohanan]

On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
 wrote:
>
> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> >
> > Hi,
> >
> > RE #1, does this mean if you submit a ticket and you are not a contributor 
> > you can't modify any of the fields including description or adding/removing 
> > attachments?
>
> Attachment operations have their own permissions, like comments.  Description 
> would be prohibited though.  I don’t see this as a major problem, really; it 
> is generally much more useful to add comments.  If we particularly want to 
> make a subset of fields editable there is a workaround, though I’m not sure 
> anybody would have the patience to implement it:  
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>  
> 
>

That would be disappointing. Descriptions with broken or no formatting
aren't rare (say, command output without code formatting). And every
now and then the description might need to be updated. For example, in
https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
paper had rotted, but I managed to find a new one, so I could edit it
in. If such a change had to be posted as a comment, it might easily
get lost in some of the more active issues.

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

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> 
> Hi,
> 
> RE #1, does this mean if you submit a ticket and you are not a contributor 
> you can't modify any of the fields including description or adding/removing 
> attachments?

Attachment operations have their own permissions, like comments.  Description 
would be prohibited though.  I don’t see this as a major problem, really; it is 
generally much more useful to add comments.  If we particularly want to make a 
subset of fields editable there is a workaround, though I’m not sure anybody 
would have the patience to implement it:  
https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
 


> RE #2, while bugs don't necessarily have a priority it's helpful to have it 
> sort logically with other issue types on that field. Seems like ideally what 
> we want to preserve is a useful sort order without having to populate the 
> field manually.

Do you have a suggestion that achieves this besides auto-populating (if that’s 
even possible)?  More than happy to add suggestions to the list.

> RE #4, Do we need to keep wish at all?

I’m unclear on what you’re asking?  I included exactly this question, directly 
in response to your opinion that it should not be kept.  If you have more to 
add to your earlier view, please feel free to share it.

> Not voting yet just because I'm not sure on some.
> 
> Ariel
> 
> On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote:
>> New questions.  This is the last round, before I call a proper vote on 
>> the modified proposal (so we can take a mandate to Infra to modify our 
>> JIRA workflows).  
>> 
>> Thanks again to everyone following and contributing to this discussion.  
>> I’m not sure any of these remaining questions are critical, but for the 
>> best democratic outcome it’s probably worth running them through the 
>> same process.  I also forgot to include (1) on the prior vote.
>> 
>> 1. Limit edits to JIRA ‘contributor’ role: +1/-1
>> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) 
>> leave it.  Please rank.
>> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation 
>> of why I chose Urgent 
>> >  
>> >.
>> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
>> 
>> For 2, if we cannot remove it, we can make it non-editable and default 
>> to Normal; for auto-populate I propose using Severity (Low->Low, Normal-
>>> Normal, Critical->Urgent).  No guarantees entirely on what we can 
>> achieve, so a ranked choice would be ideal.
>> 
>> I have avoided splitting out another vote on the Platform field, since 
>> everyone was largely meh on the question of mandatoriness; it won by 
>> only a slim margin, because everyone was +/- 0, and nobody responded to 
>> back Ariel’s dissenting view.
>> 
>> My votes are:
>> 1: +1
>> 2: B,C,A
>> 3: A
>> 4: +0.5
>> 
>> 
>> For tracking, the new consensus from the prior vote is:
>> 1: A (+10)
>> 2: +9 -0.1
>> 3: +10
>> 4: +6 -2 (=+4)
>> 5: +2; a lot of meh.
>> 6: +9
>> 
>> 
>> 
>>> On 7 Dec 2018, at 17:52, Ariel Weisberg  wrote:
>>> 
>>> Hi,
>>> 
>>> Late but.
>>> 
>>> 1. A
>>> 2. +1
>>> 3. +1
>>> 4. -1
>>> 5. -0
>>> 6. +1
>>> 
>>> RE 4, I think blocker is an important priority. High and urgent mean the 
>>> same thing to me. Wish is fine, but that is too similar to low if you ask 
>>> me. My ideal would be low, medium, high, blocker. Medium feels weird, but 
>>> it's a real thing, it's not high priority and we really want it done, but 
>>> it's not low enough that we might skip it/not get to it anytime soon.
>>> 
>>> RE 5. I don't think I have ever used the environment field or used the 
>>> contents populated in it. Doesn't mean someone else hasn't, but in terms of 
>>> making the easy things easy it seems like making it required isn't so high 
>>> value? I don't populate it myself usually I put it in the description or 
>>> the subject without thinking.
>>> 
>>> It seems like the purpose of a field is to make it indexable and possibly 
>>> structured. How often do we search or require structure on this field?
>>> 
>>> Ariel
>>> 
>>> On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith wrote:
 Ok, so after an initial flurry everyone has lost interest :)
 
 I think we should take a quick poll (not a vote), on people’s positions 
 on the questions raised so far.  If people could try to take the time to 
 stake a +1/-1, or A/B, for each item, that would be really great.  This 
 poll will not be the end of discussions, but will (hopefully) at least 
 draw a line under the current open questions.

Re: JIRA Workflow Proposals

[Ariel Weisberg]

Hi,

RE #1, does this mean if you submit a ticket and you are not a contributor you 
can't modify any of the fields including description or adding/removing 
attachments?

RE #2, while bugs don't necessarily have a priority it's helpful to have it 
sort logically with other issue types on that field. Seems like ideally what we 
want to preserve is a useful sort order without having to populate the field 
manually.

RE #4, Do we need to keep wish at all?

Not voting yet just because I'm not sure on some.

Ariel

On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote:
> New questions.  This is the last round, before I call a proper vote on 
> the modified proposal (so we can take a mandate to Infra to modify our 
> JIRA workflows).  
> 
> Thanks again to everyone following and contributing to this discussion.  
> I’m not sure any of these remaining questions are critical, but for the 
> best democratic outcome it’s probably worth running them through the 
> same process.  I also forgot to include (1) on the prior vote.
> 
> 1. Limit edits to JIRA ‘contributor’ role: +1/-1
> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) 
> leave it.  Please rank.
> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation 
> of why I chose Urgent 
> .
> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> 
> For 2, if we cannot remove it, we can make it non-editable and default 
> to Normal; for auto-populate I propose using Severity (Low->Low, Normal-
> >Normal, Critical->Urgent).  No guarantees entirely on what we can 
> achieve, so a ranked choice would be ideal.
> 
> I have avoided splitting out another vote on the Platform field, since 
> everyone was largely meh on the question of mandatoriness; it won by 
> only a slim margin, because everyone was +/- 0, and nobody responded to 
> back Ariel’s dissenting view.
> 
> My votes are:
> 1: +1
> 2: B,C,A
> 3: A
> 4: +0.5
> 
> 
> For tracking, the new consensus from the prior vote is:
> 1: A (+10)
> 2: +9 -0.1
> 3: +10
> 4: +6 -2 (=+4)
> 5: +2; a lot of meh.
> 6: +9
> 
> 
> 
> > On 7 Dec 2018, at 17:52, Ariel Weisberg  wrote:
> > 
> > Hi,
> > 
> > Late but.
> > 
> > 1. A
> > 2. +1
> > 3. +1
> > 4. -1
> > 5. -0
> > 6. +1
> > 
> > RE 4, I think blocker is an important priority. High and urgent mean the 
> > same thing to me. Wish is fine, but that is too similar to low if you ask 
> > me. My ideal would be low, medium, high, blocker. Medium feels weird, but 
> > it's a real thing, it's not high priority and we really want it done, but 
> > it's not low enough that we might skip it/not get to it anytime soon.
> > 
> > RE 5. I don't think I have ever used the environment field or used the 
> > contents populated in it. Doesn't mean someone else hasn't, but in terms of 
> > making the easy things easy it seems like making it required isn't so high 
> > value? I don't populate it myself usually I put it in the description or 
> > the subject without thinking.
> > 
> > It seems like the purpose of a field is to make it indexable and possibly 
> > structured. How often do we search or require structure on this field?
> > 
> > Ariel
> > 
> > On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith wrote:
> >> Ok, so after an initial flurry everyone has lost interest :)
> >> 
> >> I think we should take a quick poll (not a vote), on people’s positions 
> >> on the questions raised so far.  If people could try to take the time to 
> >> stake a +1/-1, or A/B, for each item, that would be really great.  This 
> >> poll will not be the end of discussions, but will (hopefully) at least 
> >> draw a line under the current open questions.
> >> 
> >> I will start with some verbiage, then summarise with options for 
> >> everyone to respond to.  You can scroll to the summary immediately if 
> >> you like.
> >> 
> >> - 1. Component: Multi-select or Cascading-select (i.e. only one 
> >> component possible per ticket, but neater UX)
> >> - 2. Labels: rather than litigate people’s positions, I propose we do 
> >> the least controversial thing, which is to simply leave labels intact, 
> >> and only supplement them with the new schema information.  We can later 
> >> revisit if we decide it’s getting messy.
> >> - 3. "First review completed; second review ongoing": I don’t think we 
> >> need to complicate the process; if there are two reviews in flight, the 
> >> first reviewer can simply comment that they are done when ready, and the 
> >> second reviewer can move the status once they are done.  If the first 
> >> reviewer wants substantive changes, they can move the status to "Change 
> >> Request” before the other reviewer completes, if they like.  Everyone 
> >> involved can probably negotiate this fairly well, but we can introduce 
> >> some specific guidance on how to conduct yourself here in a follow-up.  
> >> - 4. Prio

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

New questions.  This is the last round, before I call a proper vote on the 
modified proposal (so we can take a mandate to Infra to modify our JIRA 
workflows).  

Thanks again to everyone following and contributing to this discussion.  I’m 
not sure any of these remaining questions are critical, but for the best 
democratic outcome it’s probably worth running them through the same process.  
I also forgot to include (1) on the prior vote.

1. Limit edits to JIRA ‘contributor’ role: +1/-1
2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) leave 
it.  Please rank.
3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of why I 
chose Urgent 
.
4. Priority keep ‘Wish’ (to replace issue type): +1/-1

For 2, if we cannot remove it, we can make it non-editable and default to 
Normal; for auto-populate I propose using Severity (Low->Low, Normal->Normal, 
Critical->Urgent).  No guarantees entirely on what we can achieve, so a ranked 
choice would be ideal.

I have avoided splitting out another vote on the Platform field, since everyone 
was largely meh on the question of mandatoriness; it won by only a slim margin, 
because everyone was +/- 0, and nobody responded to back Ariel’s dissenting 
view.

My votes are:
1: +1
2: B,C,A
3: A
4: +0.5


For tracking, the new consensus from the prior vote is:
1: A (+10)
2: +9 -0.1
3: +10
4: +6 -2 (=+4)
5: +2; a lot of meh.
6: +9



> On 7 Dec 2018, at 17:52, Ariel Weisberg  wrote:
> 
> Hi,
> 
> Late but.
> 
> 1. A
> 2. +1
> 3. +1
> 4. -1
> 5. -0
> 6. +1
> 
> RE 4, I think blocker is an important priority. High and urgent mean the same 
> thing to me. Wish is fine, but that is too similar to low if you ask me. My 
> ideal would be low, medium, high, blocker. Medium feels weird, but it's a 
> real thing, it's not high priority and we really want it done, but it's not 
> low enough that we might skip it/not get to it anytime soon.
> 
> RE 5. I don't think I have ever used the environment field or used the 
> contents populated in it. Doesn't mean someone else hasn't, but in terms of 
> making the easy things easy it seems like making it required isn't so high 
> value? I don't populate it myself usually I put it in the description or the 
> subject without thinking.
> 
> It seems like the purpose of a field is to make it indexable and possibly 
> structured. How often do we search or require structure on this field?
> 
> Ariel
> 
> On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith wrote:
>> Ok, so after an initial flurry everyone has lost interest :)
>> 
>> I think we should take a quick poll (not a vote), on people’s positions 
>> on the questions raised so far.  If people could try to take the time to 
>> stake a +1/-1, or A/B, for each item, that would be really great.  This 
>> poll will not be the end of discussions, but will (hopefully) at least 
>> draw a line under the current open questions.
>> 
>> I will start with some verbiage, then summarise with options for 
>> everyone to respond to.  You can scroll to the summary immediately if 
>> you like.
>> 
>> - 1. Component: Multi-select or Cascading-select (i.e. only one 
>> component possible per ticket, but neater UX)
>> - 2. Labels: rather than litigate people’s positions, I propose we do 
>> the least controversial thing, which is to simply leave labels intact, 
>> and only supplement them with the new schema information.  We can later 
>> revisit if we decide it’s getting messy.
>> - 3. "First review completed; second review ongoing": I don’t think we 
>> need to complicate the process; if there are two reviews in flight, the 
>> first reviewer can simply comment that they are done when ready, and the 
>> second reviewer can move the status once they are done.  If the first 
>> reviewer wants substantive changes, they can move the status to "Change 
>> Request” before the other reviewer completes, if they like.  Everyone 
>> involved can probably negotiate this fairly well, but we can introduce 
>> some specific guidance on how to conduct yourself here in a follow-up.  
>> - 4. Priorities: Option A: Wish, Low, Normal, High, Urgent; Option B: 
>> Wish, Low, Normal, Urgent
>> - 5. Mandatory Platform and Feature. Make mandatory by introducing new 
>> “All” and “None” (respectively) options, so always possible to select an 
>> option.
>> - 6. Environment field: Remove?
>> 
>> I think this captures everything that has been brought up so far, except 
>> for the suggestion to make "Since Version” a “Version” - but that needs 
>> more discussion, as I don’t think there’s a clear alternative proposal 
>> yet.
>> 
>> Summary:
>> 
>> 1: Component. (A) Multi-select; (B) Cascading-select
>> 2: Labels: leave alone +1/-1
>> 3: No workflow changes for first/second review: +1/-1
>> 4: Priorities: Including High +1/-1
>> 5: Mandatory Platform and Feature: +1/-1
>> 6: Re

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

The “Impact” field idea sounds like a good potential follow-up discussion.  I’d 
prefer not to complicate this process when we’re seemingly nearing consensus, 
particularly as I’m not personally sure what form such a field would take.  But 
it would be a relatively small modification, if you want to come up with a 
proposal when we’ve finished modifying JIRA with whatever consensus we reach 
here.  Does that sound reasonable?

Similarly, the CIP process is something I think we need to drive a separate 
discussion on, similar to this one.  It’s a huge rabbit hole that could easily 
derail this discussion.


> On 9 Dec 2018, at 03:03, Mick Semb Wever  wrote:
> 
> 
> 
>> Of course, if we remove Priority from the Bug type, I agree with others 
>> that the top level priority ceases to mean anything, and there probably 
>> shouldn’t be one.
> 
> 
> Benedict, another idea, and this might be for down the road, is to have 
> "Severity" or bug types and "Impact" on non-bug types. Removing everywhere 
> the need for a subjective Priority field. Such an "Impact" field would permit 
> more descriptive values for improvements and features. We can also add some 
> documentation as to what qualifies for the different values to both Severity 
> and Impact. 
> 
> And on the topic of Feature types, what are people's thoughts on the 
> "Cassandra improvement Proposal" written up at 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
> 
> If we agree on this then can we have a (mandatory) field on Feature for the 
> CIP? If people are entering requests for new Features then shouldn't they 
> also be willing to do some homework and write up a CIP?
> 
> 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