[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152252#comment-17152252 ]
Michael Semb Wever edited comment on CASSANDRA-15234 at 7/6/20, 7:09 PM: ------------------------------------------------------------------------- {quote}I am fine to be proved wrong in a justified way. Benedict Elliott Smith, Benjamin Lerer, Michael Semb Wever, do you agree with me on my suggestion(reorganizing the yaml file and doing the nested parameters approach later)? {quote} Let's keep listening to what everyone has to say. Some of us are better with the written word than others, it is a second language for some, and for me as a native-english-speaker it is still all too easy to miss things the first time they are said. On that, I believe everyone hears and recognises what [~e.dimitrova] is saying here regarding frustrations about such a substantial change being suggested so late in the game and the amount of time that's been asked to re-invest. Especially when an almost identical user experience improvement was presented two months ago. But it should be said again. On a side-note, it would have really helped me a lot if the comment [above|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17150521&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17150521] back-referenced [this discussion|https://github.com/apache/cassandra/pull/659#discussion_r449201020] where it originated. I know the ticket was referenced, but that discussion thread is the source of the suggestion. {quote}This ticket’s API replaces the current API, is mutually exclusive with the alternative proposal, and would be deprecated by it. If we introduce them both in 4.0-beta, we must maintain them both and go through the full deprecation process. So unfortunately no churn is avoided. {quote} AFAIK this is the only "grounded" justification for the veto. I don't agree that we are forced into that premise. We can get around those compatibility rules with a minimal amount of effort, by not deprecating the old API and not announcing (in docs or yaml) the new API. (I would expect everyone to intuitively treat private undocumented and un-referenced APIs, only ever available in alpha and beta releases, to be considered unsupported.) All that "compatibility change" can be left and just done once in the separate ticket. The underlying framework and bulk of this patch can still be merged. Based on that I see three possible courses of action: 1. Accept investigating the alternative proposal, and include it in this ticket, delaying our first 4.0-beta release, 2. As (1) but requesting this ticket to be merged during 4.0-beta, so we can release 4.0-beta now, 3. Spin out the new suggestion and all public API changes to a separate ticket, slated for 4.0-beta, and merging this ticket. I suspect, since you have offered to help [~benedict], that most are in favour of (2) ? was (Author: michaelsembwever): {quote}I am fine to be proved wrong in a justified way. Benedict Elliott Smith, Benjamin Lerer, Michael Semb Wever, do you agree with me on my suggestion(reorganizing the yaml file and doing the nested parameters approach later)? {quote} Let's keep listening to what everyone has to say. Some of us are better with the written word than others, it is a second language for some, and for me as a native-english-speaker it is still all too easy to miss things the first time they are said. On that, I believe everyone hears and recognises what [~e.dimitrova] is saying here regarding frustrations about such a substantial change being suggested so late in the game and the amount of time that's been asked to re-invest. Especially when an almost identical user experience improvement was presented two months ago. But it should be said again. On a side-note, it would have really helped me a lot if the comment above back-referenced [this discussion|https://github.com/apache/cassandra/pull/659#discussion_r449201020] where it originated. I know the ticket was referenced, but that discussion thread is the source of the suggestion. {quote}This ticket’s API replaces the current API, is mutually exclusive with the alternative proposal, and would be deprecated by it. If we introduce them both in 4.0-beta, we must maintain them both and go through the full deprecation process. So unfortunately no churn is avoided. {quote} AFAIK this is the only "grounded" justification for the veto. I don't agree that we are forced into that premise. We can get around those compatibility rules with a minimal amount of effort, by not deprecating the old API and not announcing (in docs or yaml) the new API. (I would expect everyone to intuitively treat private undocumented and un-referenced APIs, only ever available in alpha and beta releases, to be considered unsupported.) All that "compatibility change" can be left and just done once in the separate ticket. The underlying framework and bulk of this patch can still be merged. Based on that I see three possible courses of action: 1. Accept investigating the alternative proposal, and include it in this ticket, delaying our first 4.0-beta release, 2. As (1) but requesting this ticket to be merged during 4.0-beta, so we can release 4.0-beta now, 3. Spin out the new suggestion and all public API changes to a separate ticket, slated for 4.0-beta, and merging this ticket. I suspect, since you have offered to help [~benedict], that most are in favour of (2) ? > Standardise config and JVM parameters > ------------------------------------- > > Key: CASSANDRA-15234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15234 > Project: Cassandra > Issue Type: Bug > Components: Local/Config > Reporter: Benedict Elliott Smith > Assignee: Ekaterina Dimitrova > Priority: Normal > Fix For: 4.0-alpha > > Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt > > > We have a bunch of inconsistent names and config patterns in the codebase, > both from the yams and JVM properties. It would be nice to standardise the > naming (such as otc_ vs internode_) as well as the provision of values with > units - while maintaining perpetual backwards compatibility with the old > parameter names, of course. > For temporal units, I would propose parsing strings with suffixes of: > {{code}} > u|micros(econds?)? > ms|millis(econds?)? > s(econds?)? > m(inutes?)? > h(ours?)? > d(ays?)? > mo(nths?)? > {{code}} > For rate units, I would propose parsing any of the standard {{B/s, KiB/s, > MiB/s, GiB/s, TiB/s}}. > Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or > powers of 1000 such as {{KB/s}}, given these are regularly used for either > their old or new definition e.g. {{KiB/s}}, or we could support them and > simply log the value in bytes/s. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org