[ 
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152590#comment-17152590
 ] 

Benedict Elliott Smith commented on CASSANDRA-15234:
----------------------------------------------------

bq. We can ... not deprecat[e] the old API and not announc[e] ... the new API

This would be fine by me.  My -1 as expressed applied only to the public API 
changes.  All of the other changes in this ticket are absolutely good to go 
(once review is completed, of course).

Also to reiterate again (since things easily get lost in such a contentious 
exchange): 
* I think this work is great, and am really glad [~e.dimitrova] undertook it.
* I don't personally mind too strongly _which_ API we settle on, just expect 
that we settle on one upfront before committing the userbase to it.
* I think it's a shame that this has seemingly turned into a heightened and 
acrimonious exchange.
* It's worth remembering this situation is not unique; we have all experienced 
having to revisit work (or abandon it, even - my GitHub is a graveyard of good 
intentions) to our frustration and disappointment; it's a part of OSS 
development.


> 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

Reply via email to