[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152252#comment-17152252
]
Michael Semb Wever commented on CASSANDRA-15234:
------------------------------------------------
{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
