[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151344#comment-17151344
]
Josh McKenzie commented on CASSANDRA-15234:
-------------------------------------------
{quote}bq. To be more explicit: I am (binding) -1 knowingly shipping an
_interim_ solution for a public API. It is user unfriendly.
{quote}
We as a project need to mindfully balance when something is "good enough" and
when the trade-off is in favor of getting a release out vs. pursuing another
incremental improvement to an API. In my opinion this is classic bike-shedding.
Given a day focused on nothing but thinking of how to improve our config API I
firmly believe we could come up with something that a simple majority
considered an improvement over what's proposed on this ticket + config grouping
in a vacuum. _I personally prefer the config param grouping_, but not when
weighed against delaying the beta when it's this been long since a prior
release.
I perceive on balance what is in our users' best interests is having a release
with all the defect fixes and features available in 4.0. This point of view
stems from the empirical evidence of multiple users asking if the project is
dead and expressing a strong interest in running 4.0 having heard of the
proximity of the beta. I have no evidence of users stating that a lack of
configuration grouping in the project causes them equal or greater pain, nor
have I seen a cogent argument for that point of view.
The underlying question we face is how we balance the value to end-users of
having as optimal of an API as we can possibly come up in a specific domain vs.
the value to end-users of the other things that are delayed due to that effort.
Your point of view [~benedict] _appears to be_ that delaying the beta and the
engagement of the user community's testing of the 4.0 release is justified by
the value gained in grouping config params and not having a renamed paradigm
for 4.0 and subsequent grouping paradigm in our next major. My apologies if I'm
mis-characterizing your point of view here.
It's within any committers prerogative to binding -1 things on justified
technical grounds. I'd be curious what your perspective is on how we determine
what qualifies as justified [~benedict], [~mck2] , and [~maedhroz] in a context
such as this, as you all have expressed points of view here.
> 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
