[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553773#comment-17553773
]
Ekaterina Dimitrova edited comment on CASSANDRA-16844 at 6/13/22 7:33 PM:
--------------------------------------------------------------------------
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it explicitly on the mailing list or have a list that
should be big enough to justify that bump in time (which I believe might
demotivate people to be on a waiting list, IMHO).
I think it is probably a good time to get into some agreement with the PMC on
this topic (how to approach those changes) so that people can actually plan
what they will work on or hit the mailing list to agree whether it makes sense
or not at this point in time. Some changes people probably feel do not deserve
CEP but we all know they can be a breaking change.
was (Author: e.dimitrova):
{quote}We don't have any pending tickets which justify the extra burden of 5.0,
so moving trunk 5.0 adds extra cost to everyone maintaining, I am against
switching to 5.0 at the moment.
{quote}
That is an interesting question that I believe It deserves broader agreement.
Up to now I was always hearing - we are 4.x until someone adds something
breaking compatibility and considered 5.0, then we will bump. No one was saying
- we need to approve it explicitly on the mailing list or have a list that
should be big enough to justify that bump in time (which I believe might
demotivate people to be on a waiting list, IMHO).
I think it is probably a good time to get into some agreement with the PMC on
this topic so that people can actually plan what they will work on or hit the
mailing list to agree whether it makes sense or not at this point in time. Some
changes people probably feel do not deserve CEP but we all know they can be a
breaking change.
> Add number of sstables in a compaction to compactionstats output
> ----------------------------------------------------------------
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
> Reporter: Brendan Cicchi
> Assignee: Brandon Williams
> Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
