[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151948#comment-17151948
]
Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/6/20, 10:38 AM:
------------------------------------------------------------------------------
bq. The valid concern around the api churn it introduces is addressed by
committing the new ticket to 4.0-beta.
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.
> I'd be curious what your perspective is on how we determine what qualifies as
> justified
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 _seem_ in danger
of subordinating this to beliefs about scheduling.
If you like, I can formulate a legally airtight veto, but my goal is only for
you to engage briefly with the proposal and determine for yourselves which is
superior. If the new proposal is _technically_* superior, and of similar
complexity, then you are my justification. If you disagree, however - and
importantly we agree that we do not intend to pursue the alternative approach
in future - I would consider my veto invalid (and would anyway withdraw it).
> having heard of the proximity of the beta
Perhaps we can also directly address people’s thoughts on deferral to 4.0-beta?
This should surely alleviate concerns around delaying 4.0? I do understand
the imperative to get 4.0 out the door, but I also know we all want to ship the
best product we can as well. If we can achieve both, we should. APIs matter,
and avoiding API churn is an important part of our user/operator story.
\* I _hope_ we can avoid an epistemic battle about the word "technical," and
accept that API design is a technical endeavour to convey meaning.
was (Author: benedict):
bq. The valid concern around the api churn it introduces is addressed by
committing the new ticket to 4.0-beta.
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.
> I'd be curious what your perspective is on how we determine what qualifies as
> justified
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 _seem_ in danger
of subordinating this to beliefs about scheduling.
If you like, I can formulate a legally airtight veto, but my goal is only for
you to engage briefly with the proposal and determine for yourselves which is
superior. If the new proposal is _technically_* superior, and of similar
complexity, then you are my justification. If you disagree, however - and
importantly we agree that we do not intend to pursue the alternative approach
in future - I would consider my veto invalid (and would anyway withdraw it).
> having heard of the proximity of the beta
Perhaps we can also directly address people’s thoughts on deferral to 4.0-beta?
This should surely alleviate concerns around delaying 4.0? I do understand
the imperative to get 4.0 out the door, but I also know we all want to ship the
best product we can as well. If we can achieve both, we should. APIs matter,
and avoiding API churn is an important part of our user/operator story.
* I _hope_ we can avoid an epistemic battle about the word "technical," and
accept that API design is a technical endeavour to convey meaning.
> 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]
