[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152050#comment-17152050
]
Josh McKenzie commented on CASSANDRA-15234:
-------------------------------------------
{quote}{color:#172b4d}It is customary that, before work is committed,
alternative proposals are engaged with on their technical merits. It occurs to
me we recently worked to mandate this as part of the process, in fact. In this
case we {color}_seem_{color:#172b4d} in danger of subordinating this to beliefs
about scheduling.{color}
{quote}
{color:#172b4d}Unfortunately it's customary on this project to do that right up
until the last moment before something is committed (and even beyond) with no
weighting of the value on things actually being in the hands of users vs. in
tree and unreleased.{color}
{color:#172b4d}We have un-tested beliefs about a potentially superior design
against un-tested beliefs about the negative impact of the project on further
delay. This is not a situation in which we can expect to make progress on a
discussion until and unless both sides collect some empirical evidence about
their position as well as spend real time investigating and exploring the
position of other people engaged.{color}
{color:#172b4d}Unfortunately I'm well past the time I personally have available
to engage on this ticket; I'll defer to other people to take it from
here.{color}
> 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: [email protected]
For additional commands, e-mail: [email protected]
