[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151396#comment-17151396
]
Michael Semb Wever commented on CASSANDRA-15234:
------------------------------------------------
I'm struggling to see how a request to break work down into separate tickets
and steps constitutes a technical reasoning that should block the work. The
valid concern around the api churn it introduces is addressed by committing the
new ticket to 4.0-beta.
The more we can do incrementally the better. From reviewing, to testing, to the
compartmentalising of jira ticket discussions. (I still miss jira comment
threads, even if folk never really used them consistently.)
bq. … everyone has since agreed (or implied) this is a superior approach.
Not on my behalf. And I don't believe all others presumed answers to all
questions that need to be asked for it to be a validated proposal. For my part,
it is a good suggestion that warrants further investigation. It still needs to
be investigated and spec'd out.
bq. If we change our minds and agree the current approach is the final and
superior solution, that is another matter.
Not sure I agree with the onus here, based on this being an un-investigated and
un-specified suggestion. The onus I think should be the opposite: those wanting
this to be a blocker should do the work in determining the value
(investigation) and design (specification) to the suggestion.
The suggestion is not a fault or bug in this ticket, there is nothing in the
suggestion that *breaks* the patch, it is imho rather a subsequent suggested
improvement. Even if it was a suggestion that replaced this patch it should be
dealt with in the same way. And of course making such a suggestion first here
is natural because the author _may_ take it on in-stride, but it should be the
author's prerogative to request it be "the next step".
In a new ticket: we can better investigate the value that grouping brings and
other questions like…
- how many settings does it apply to?
- is taxonomy based on a technical or user perspective?
- if user/operator based, how many people need to be involved to get it right?
- if user/operator based, what if one property applies to multiple concerns?
- how does the {{@Replace}} annotation work between levels in the grouping?
- does this introduce more complexity/variations in what has to be tested?
(since yaml can consist of old and new setting names)
> 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
