[DISCUSS] Adding dependency to the Big-Math library from eobermuhlner

[Benjamin Lerer]

Hi everybody,

I wanted to discuss the addition of the Big-Math library(
http://eobermuhlner.github.io/big-math/)  as a dependency by
CASSANDRA-17221 
which add support for abs, exp, log, log10, and round Math function. The
library was added for providing those functions for the Cassandra decimal
type (java BigDecimal).

This patch has been started a long time ago and went through multiple
rounds of reviews and rework. In my enthusiasm to finally commit this patch
I forgot to raise the discussion to the mailing list about the dependency.
I apologize for that.

Does anybody have some concerns with the addition of that Library as a
dependency?

Re: [DISCUSS] Adding dependency to the Big-Math library from eobermuhlner

[Josh McKenzie]

I'm pleased with the rigor he shows on his explanations of implementation and 
performance: http://obermuhlner.ch/wordpress/2016/06/02/bigdecimalmath/

Seems like it's probably stable given the infrequency of changes to it and he's 
still actively merging patches submit by others: 
https://github.com/eobermuhlner/big-math/commits/master as of 8 days ago. Only 
4 issues open on the repo at this time as well for a reasonably starred / 
forked library.

I guess my one concern: this appears to be a library maintained primarily by 1 
person; that's a worst-case bus factor. Should he abandon the project is it 
something we'd plan to fork and bring into tree and maintain ourselves? Given 
how mature and stable it is I wouldn't be too worried, but worth considering 
the worst-case.


On Mon, Nov 28, 2022, at 3:48 AM, Benjamin Lerer wrote:
> Hi everybody,
> 
> I wanted to discuss the addition of the Big-Math 
> library(http://eobermuhlner.github.io/big-math/)  as a dependency by  
> CASSANDRA-17221  which 
> add support for abs, exp, log, log10, and round Math function. The library 
> was added for providing those functions for the Cassandra decimal type (java 
> BigDecimal).
> 
> This patch has been started a long time ago and went through multiple rounds 
> of reviews and rework. In my enthusiasm to finally commit this patch I forgot 
> to raise the discussion to the mailing list about the dependency. I apologize 
> for that.
> 
> Does anybody have some concerns with the addition of that Library as a 
> dependency?

Re: [DISCUSSION] Cassandra's code style and source code analysis

[Maxim Muzafarov]

Thank you all for the feedback and productive discussion.


I couldn't have formed my thoughts on the build tools for the product
better and provided such good examples than Scott did. Rephrasing what
I wrote in the first letter, seeing Maven/Gradle in the project
underfoot, a modern IDE will take care of all the necessary files and
configurations for themselves much better than we do with scripts. I
fully agree that there is no rush with such migration, and the
databases in such cases must be more conservative than progressive,
and not change anything without strong benefits and a broad consensus
on it. I still believe this consensus can be reached in future and
when (and if) the consensus will be reached, a clear migration plan
should be developed for several releases ahead as well. There's still
a lot of work to be done here that's why I mentioned it at the end of
my proposal, so as not to pay too much attention to this question at
this moment.
I've added a link to this thread to the JIRA issue [1], so we don't
lose the insights mentioned by members above.


I want to take away your concerns about lints expansion for now. I
thought first of all about making all the source code-checking tools
more convenient for use with a minimal set of already existing lints
rather than adding or forcing new rules. I really want to avoid here
cases with storing multiple configurations for a single tool e.g.
having different configurations for 'optional' or 'mandatory' checks
as well as different configurations for 'production' or 'tests'.

Thus, the ideal picture in my mind of all discussed above is :

We have:
- checkstyle
- SpotBugs
- Sonar

They work the same way for:
- Jenkins builds
- CirleCI builds
- GitHub pull requests
- build on the local machine

For all that, we have the code style webpage [2] (and wiki [3]) is
pretty well described, there is no need to expand checking tools with
new rules until we will get working these tools on the minimal set of
rules. For instance, we can pick up for the checkstyle 'Unused
imports', 'Import order', for the SpotBugs 'AutoCloseable',
'Number.valueOf', for Sonar - only reports to monitor the source code
trends.

I agree that adding new lints require a broad consensus, so I'd like
to avoid such debatable questions for now. Moreover, even with the
lints already agreed upon, it is still risky to implement some of them
because they can contain a lot of boilerplate changes and may affect
more important fixes ready for merge.


So, as a first step, I can invest my time into the checkstyle tool and
make it work everywhere with the same configuration.
WDYT?


P.S.

For IntelliJ with the Checkstyle Plugin it's easy to import the
checkstyle.xml the following way:
Preferences -> Code Style -> Show Scheme Actions (wheel) -> Import
scheme -> Checkstyle configuration.


[1] https://issues.apache.org/jira/browse/CASSANDRA-17015
[2] https://cassandra.apache.org/_/development/code_style.html
[3] https://cwiki.apache.org/confluence/display/CASSANDRA2/CodeStyle

On Sun, 27 Nov 2022 at 13:17, Josh McKenzie  wrote:
>
> My .02 on the build discussion is we should try and keep the guts of that in 
> one place, be it the other email thread or on JIRA. Some insightful points 
> made on this thread but would hate to see this thread derailed on a complex 
> independent topic as well as see some of these points lost on the other 
> discussion.
>
> I think there needs to be a lot of community consensus on the broad expansion 
> of lints that can reject patches.
>
> +1. It may be worthwhile to configure 2 tiers of lints, optional and 
> required, so we can move to a more gradual process of cleaning up lint 
> violations for those that are interested in that type of work. I know in the 
> past we've seen value in looking at the diff in linting violations even w/a 
> 1k+ noisy violation environment.
>
>
> On Fri, Nov 25, 2022, at 12:41 PM, sc...@paradoxica.net wrote:
>
> For me, the strongest arguments in favor of adopting a modern build tool like 
> Maven or Gradle are their ecosystems - both explicit (in terms of plugins), 
> and implicit (in terms of nearly all build tooling supporting both of them, 
> but not ant).
>
> Investment in Ant - and in tooling that integrates with Ant - fell off years 
> ago. This makes integrating build-phase aspects of Cassandra with other 
> tooling a very frustrating task that users of most build tools get for free. 
> Many tools built in the last several years don’t support it, or do so only as 
> an afterthought.
>
> Two recent examples that have caused pain for me, which I suspect are felt by 
> many:
>
> – Integration with internal build systems at many companies that develop 
> Cassandra. Because ant has fallen into disuse, this integration is heavily 
> manual instead of automatic and free. It usually requires forking the 
> project’s build.xml, developing custom tooling around it, or creating a mock 
> Gradle build that wraps ant lifecycle tasks (which also requir

Re: [DISCUSSION] Cassandra's code style and source code analysis

[David Capwell]

I am strong +1 to new linters, I have been working on SpotBugs but not sent a 
patch due to sickness and holidays…

About the check style as the source of truth for the style guides, I am +1 to 
this as well… I feel that wiki is a bad place for this and we can use the check 
style file to generate the wiki text (no idea if there are tools for this…).  
About the comment on “hard” requirements… my understanding has been that new 
changes must follow and I know several reviewers who act this way in the review 
process…. If we agree on a style, why do we want to keep allowing ignoring it?

> There’s always a handful of people asking for it, but notably few if any of 
> the full time contributors doing the majority of the core development of 
> Cassandra.


I don’t agree with that statement, I know several committers/PMC who want to 
switch, but every 6 months this gets brought up and gets shot down… so we just 
give up trying… 

> I never really see a good argument articulated for the migration, besides 
> general hand waving that ant is old, and people like newer build systems. Ant 
> is working fine, so there isn’t a strong technical reason to replace it, and 
> there are good organisational reasons not to.

I don’t know how Mick feels, but I tend to find that maintaining our current 
Ant build is a big waste of my time, and that every time I need to go to this 
layer its far more brittle than it should be…. There are pushes to refactor to 
try to get more order in the build (side conversation between Mick and I), but 
these tend to hide the complexity from most…. I strongly feel that our current 
build is duct taping things together, this isn’t a complaint of the maintainers 
but more how Ant works…

And there are a few things I feel newer build systems offer that actually make 
my life better:

1) cache -  I hate running tests in a loop as this always has the same pattern: 
rebuild everything from scratch for 1m to run a single test that takes 30 
milliseconds…. With ant we “could” force our tasks to cache, but then we have 
to go do that for everything… we are basically rewriting and reimplementing 
what other builds have

2) consistency - CI runs tests using 1 task, but people like to run tests using 
a different task… they tend to have different setup and act slightly 
differently… I had to go improve this for jvm-dtest and see that simulator is 
in the same shape (if you run simulator tests using the normal CI task, they 
will fail; you need the bulk task that doesn’t have the same features as the CI 
version)

3) reusable work, avoid copy/paste - when we add new jars/artifacts we need to 
copy/paste a set of tasks to implement a “sub-module” or “sub-project” 
(depending on build tool you prefer), not only is this very easy to get wrong, 
it discourages splitting work into these units (we talked about moving 
utils/concurrent into its own jar for Accord…)

4) only having to know 1 build system - right now we are Ant + Maven; to 
maintain this project you need to understand both… you can get by not knowing 
this until you touch dependencies, and if you need tasks that also know about 
those dependencies… you need to see how this is taped together and grasp that 
logic…

Maybe I am bitter as it took a whole day to get SpotBugs working with Ant… and 
it is just the following in other builds:

Gradle: apply plugin: “com.github.spotbugs"
Maven: 



  
com.github.spotbugs
spotbugs-maven-plugin
  

  


> On Nov 28, 2022, at 10:46 AM, Maxim Muzafarov  wrote:
> 
> Thank you all for the feedback and productive discussion.
> 
> 
> I couldn't have formed my thoughts on the build tools for the product
> better and provided such good examples than Scott did. Rephrasing what
> I wrote in the first letter, seeing Maven/Gradle in the project
> underfoot, a modern IDE will take care of all the necessary files and
> configurations for themselves much better than we do with scripts. I
> fully agree that there is no rush with such migration, and the
> databases in such cases must be more conservative than progressive,
> and not change anything without strong benefits and a broad consensus
> on it. I still believe this consensus can be reached in future and
> when (and if) the consensus will be reached, a clear migration plan
> should be developed for several releases ahead as well. There's still
> a lot of work to be done here that's why I mentioned it at the end of
> my proposal, so as not to pay too much attention to this question at
> this moment.
> I've added a link to this thread to the JIRA issue [1], so we don't
> lose the insights mentioned by members above.
> 
> 
> I want to take away your concerns about lints expansion for now. I
> thought first of all about making all the source code-checking tools
> more convenient for use with a minimal set of already existing lints
> rather than adding or forcing new rules. I really want to avoid here
> cases with storing multiple configurati

Re: [DISCUSSION] If we fix code that used default encoding to now be UTF-8... is this a regression?

[David Capwell]

> It probably has to be done on a  case-by-case basis


Yeah, this is what I feel as well… 

> Does the linter provide more detail than just the list?


Not really, it shows how to fix but can’t really say if the fix will cause 
issues… If you are not running with UTF-8 we do the right thing most of the 
time, but some files “may” break… this would also be true if you backup/restore 
these files on a different environment...


> On Nov 10, 2022, at 12:44 PM, Derek Chen-Becker  wrote:
> 
> This seems fraught with peril. I think that it should be fixed, but I
> also wonder what the testing requirements would be to validate no
> regression. It probably has to be done on a  case-by-case basis. Is it
> as simple as auditing places where we're calling getBytes or
> PrintReader/PrintWriter without an explicit encoding? Some of them,
> like 
> https://github.com/apache/cassandra/blob/30ad754d7e95501ffa916bf986e4cfda1aa5e441/src/java/org/apache/cassandra/tools/HashPassword.java#L128,
> look like that would be easy to address, but others seem like they
> could be complicated.
> 
> Does the linter provide more detail than just the list?
> 
> Cheers,
> 
> Derek
> 
> On Fri, Nov 4, 2022 at 2:09 PM David Capwell  wrote:
>> 
>> Testing out linter trying to see if it can solve a case for Simulator and 
>> see we have 25 cases where we don’t add the encoding and rely on default, 
>> which is based off the system…
>> 
>> If we attempt to fix these cases, I am wondering if this is a regression… it 
>> “might” be the case someone set -Dfile.encoding=ascii or updated env LANG to 
>> something non-UTF based…
>> 
>> Here is the list reported
>> 
>> org.apache.cassandra.cql3.functions.JavaBasedUDFunction since first 
>> historized release
>> org.apache.cassandra.db.ColumnFamilyStore since first historized release
>> org.apache.cassandra.db.compaction.CompactionLogger$CompactionLogSerializer 
>> since first historized release
>> org.apache.cassandra.db.filter.RowFilter$CustomExpression since first 
>> historized release
>> org.apache.cassandra.db.lifecycle.LogTransaction since first historized 
>> release
>> org.apache.cassandra.gms.FailureDetector since first historized release
>> org.apache.cassandra.index.sasi.analyzer.StandardTokenizerImpl since first 
>> historized release
>> org.apache.cassandra.io.sstable.SSTable since first historized release
>> org.apache.cassandra.io.util.FileReader since first historized release
>> org.apache.cassandra.io.util.FileReader since first historized release
>> org.apache.cassandra.io.util.FileWriter since first historized release
>> org.apache.cassandra.io.util.FileWriter since first historized release
>> org.apache.cassandra.metrics.SamplingManager since first historized release
>> org.apache.cassandra.metrics.SamplingManager since first historized release
>> org.apache.cassandra.schema.IndexMetadata since first historized release
>> org.apache.cassandra.security.PEMBasedSslContextFactory since first 
>> historized release
>> org.apache.cassandra.tools.HashPassword since first historized release
>> org.apache.cassandra.tools.JMXTool$Dump$Format$3 since first historized 
>> release
>> org.apache.cassandra.tools.NodeTool$NodeToolCmd since first historized 
>> release
>> org.apache.cassandra.tools.SSTableMetadataViewer since first historized 
>> release
>> org.apache.cassandra.transport.Client since first historized release
>> org.apache.cassandra.utils.ByteArrayUtil since first historized release
>> org.apache.cassandra.utils.FBUtilities since first historized release
>> org.apache.cassandra.utils.GuidGenerator since first historized release
>> org.apache.cassandra.utils.HeapUtils since first historized release
>> 
> 
> 
> -- 
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+

Re: [DISCUSSION] Cassandra's code style and source code analysis

[Benedict]

Scott makes some valid points about legitimate benefits. I personally doubt the 
high upfront cost of migration will take less than a decade to pay back in time 
saved managing shims. But, it’s a tangible justification. Conveniently the bulk 
of my contributions are also at Scott’s prerogative, so if he’s fine with me 
(and others) wasting their time battling Gradle or Maven, or losing time to the 
migration, then I think my complaint is functionally neutered.

I think, though, that those pushing such a disruptive change into others had 
better work very darn hard to deliver a smooth experience.

> I tend to find that maintaining our current Ant build is a big waste of my 
> time, and that every time I need to go to this layer its far more brittle 
> than it should be

Whereas I find Ant an absolute pleasure, and Gradle a nightmare, and already 
regret using it for Accord. I wasted more than a day just trying to get some 
test artefacts in one module exposed in another, and eventually gave up. I have 
made dozens of forays into our Ant build and *never* abandoned my goal because 
I couldn’t accomplish it. I think people are really glossing over all the pain 
other build systems bring - even without our complex build requirements. 

If you’re going to make the project adopt your preferred build system, you 
become responsible for the experience of everyone using it. Make sure you’re 
ready for that.


> I think those pushing such a disruptive change on others had better work very 
> darn hard to deliver a smooth experience.



> On 28 Nov 2022, at 20:18, David Capwell  wrote:
> 
> I am strong +1 to new linters, I have been working on SpotBugs but not sent 
> a patch due to sickness and holidays…
> 
> About the check style as the source of truth for the style guides, I am +1 to 
> this as well… I feel that wiki is a bad place for this and we can use the 
> check style file to generate the wiki text (no idea if there are tools for 
> this…).  About the comment on “hard” requirements… my understanding has been 
> that new changes must follow and I know several reviewers who act this way in 
> the review process…. If we agree on a style, why do we want to keep allowing 
> ignoring it?
> 
>> There’s always a handful of people asking for it, but notably few if any of 
>> the full time contributors doing the majority of the core development of 
>> Cassandra.
> 
> 
> I don’t agree with that statement, I know several committers/PMC who want to 
> switch, but every 6 months this gets brought up and gets shot down… so we 
> just give up trying… 
> 
>> I never really see a good argument articulated for the migration, besides 
>> general hand waving that ant is old, and people like newer build systems. 
>> Ant is working fine, so there isn’t a strong technical reason to replace it, 
>> and there are good organisational reasons not to.
> 
> I don’t know how Mick feels, but I tend to find that maintaining our current 
> Ant build is a big waste of my time, and that every time I need to go to this 
> layer its far more brittle than it should be…. There are pushes to refactor 
> to try to get more order in the build (side conversation between Mick and I), 
> but these tend to hide the complexity from most…. I strongly feel that our 
> current build is duct taping things together, this isn’t a complaint of the 
> maintainers but more how Ant works…
> 
> And there are a few things I feel newer build systems offer that actually 
> make my life better:
> 
> 1) cache -  I hate running tests in a loop as this always has the same 
> pattern: rebuild everything from scratch for 1m to run a single test that 
> takes 30 milliseconds…. With ant we “could” force our tasks to cache, but 
> then we have to go do that for everything… we are basically rewriting and 
> reimplementing what other builds have
> 
> 2) consistency - CI runs tests using 1 task, but people like to run tests 
> using a different task… they tend to have different setup and act slightly 
> differently… I had to go improve this for jvm-dtest and see that simulator is 
> in the same shape (if you run simulator tests using the normal CI task, they 
> will fail; you need the bulk task that doesn’t have the same features as the 
> CI version)
> 
> 3) reusable work, avoid copy/paste - when we add new jars/artifacts we need 
> to copy/paste a set of tasks to implement a “sub-module” or “sub-project” 
> (depending on build tool you prefer), not only is this very easy to get 
> wrong, it discourages splitting work into these units (we talked about moving 
> utils/concurrent into its own jar for Accord…)
> 
> 4) only having to know 1 build system - right now we are Ant + Maven; to 
> maintain this project you need to understand both… you can get by not knowing 
> this until you touch dependencies, and if you need tasks that also know about 
> those dependencies… you need to see how this is taped together and grasp that 
> logic…
> 
> Maybe I am bitter as it took a whole day t

Re: [DISCUSSION] Cassandra's code style and source code analysis

[Benedict]

On the topic of code style, the wiki not only covers many elements of style 
that are impossible to encode in a linter, but explicitly uses terminology on 
many lintable items that is not “hard.” I should know, I formulated it this way 
deliberately, and made this explicit in the discussion while shepherding it 
through a vote - only quite recently.

For both these reason I think it is impossible to make checkstyle the source of 
truth.

We can vote for a subset of rules we want everyone to follow without any 
exception, and translate these into a checkstyle.xml without a vote. But:

1) I personally have seen limited value to strict style enforcement on projects 
where I’ve interacted with it. Expressing code neatly involves a lot of 
authorship decisions that a linter simply cannot understand.
2) There’s already a broad array of styles in the project, and this is fine. We 
don’t have to check-in identical looking code, so long as it is all the same 
flavour. 
3) It would anyway be hugely disruptive to apply to PRs to existing code.

I think if you’re keen on this it would be best to start by selecting your 
preferred subset of hard rules.

> About the check style as the source of truth for the style guides, I am +1 to 
> this as well… I feel that wiki is a bad place for this and we can use the 
> check style file to generate the wiki text (no idea if there are tools for 
> this…).  About the comment on “hard” requirements… my understanding has been 
> that new changes must follow and I know several reviewers who act this way in 
> the review process…. If we agree on a style, why do we want to keep allowing 
> ignoring it?


> On 28 Nov 2022, at 20:18, David Capwell  wrote:
> 
> I am strong +1 to new linters, I have been working on SpotBugs but not sent 
> a patch due to sickness and holidays…
> 
> About the check style as the source of truth for the style guides, I am +1 to 
> this as well… I feel that wiki is a bad place for this and we can use the 
> check style file to generate the wiki text (no idea if there are tools for 
> this…).  About the comment on “hard” requirements… my understanding has been 
> that new changes must follow and I know several reviewers who act this way in 
> the review process…. If we agree on a style, why do we want to keep allowing 
> ignoring it?
> 
>> There’s always a handful of people asking for it, but notably few if any of 
>> the full time contributors doing the majority of the core development of 
>> Cassandra.
> 
> 
> I don’t agree with that statement, I know several committers/PMC who want to 
> switch, but every 6 months this gets brought up and gets shot down… so we 
> just give up trying… 
> 
>> I never really see a good argument articulated for the migration, besides 
>> general hand waving that ant is old, and people like newer build systems. 
>> Ant is working fine, so there isn’t a strong technical reason to replace it, 
>> and there are good organisational reasons not to.
> 
> I don’t know how Mick feels, but I tend to find that maintaining our current 
> Ant build is a big waste of my time, and that every time I need to go to this 
> layer its far more brittle than it should be…. There are pushes to refactor 
> to try to get more order in the build (side conversation between Mick and I), 
> but these tend to hide the complexity from most…. I strongly feel that our 
> current build is duct taping things together, this isn’t a complaint of the 
> maintainers but more how Ant works…
> 
> And there are a few things I feel newer build systems offer that actually 
> make my life better:
> 
> 1) cache -  I hate running tests in a loop as this always has the same 
> pattern: rebuild everything from scratch for 1m to run a single test that 
> takes 30 milliseconds…. With ant we “could” force our tasks to cache, but 
> then we have to go do that for everything… we are basically rewriting and 
> reimplementing what other builds have
> 
> 2) consistency - CI runs tests using 1 task, but people like to run tests 
> using a different task… they tend to have different setup and act slightly 
> differently… I had to go improve this for jvm-dtest and see that simulator is 
> in the same shape (if you run simulator tests using the normal CI task, they 
> will fail; you need the bulk task that doesn’t have the same features as the 
> CI version)
> 
> 3) reusable work, avoid copy/paste - when we add new jars/artifacts we need 
> to copy/paste a set of tasks to implement a “sub-module” or “sub-project” 
> (depending on build tool you prefer), not only is this very easy to get 
> wrong, it discourages splitting work into these units (we talked about moving 
> utils/concurrent into its own jar for Accord…)
> 
> 4) only having to know 1 build system - right now we are Ant + Maven; to 
> maintain this project you need to understand both… you can get by not knowing 
> this until you touch dependencies, and if you need tasks that also know about 
> those dependencies… you need to se

Re: [DISCUSSION] Cassandra's code style and source code analysis

[Łukasz Dywicki]

I can put few sentences in this context, because my involvement into 
Cassandra mailing list started with looking at build system. It was 8 or 
maybe 9 years ago.


Simple fact that Cassandra core team do understand their chain of Ant 
task execution doesn't automatically make all other contributors and 
interested parties understand it. More over, another person outside of 
present core team with prior knowledge of Ant, will require some amount 
of time to dive into task definitions and how they are being invoked. 
There is a reason why usage of Ant fade away over time, its because 
maintenance of builds such Cassandra takes with time more and more effort.
Maven is built around convention over configuration, most of external 
contributors who worked with it before will come with enough of 
knowledge to understand what your build is doing and how. A lot of hate 
people feel to Maven is caused by its limitations which they try to 
overcome for some reason. Gradle is closer in its flexibility to Ant and 
gives much more power, but requires a bit of though to not complicate 
things too much.
Switching to standardized build requires a work, but usually it improves 
architecture and separation of concerns. System you build might have a 
complex logic because of business, standards or technology requirements, 
but your build is not part of that complexity. If you assume it is then 
you just double amount of troubles as your technology will depend on 
over-engineered pipeline. One of major pain points I found back in 2013 
or 2014 was that Cassandra had a lot of cross dependencies between 
packages making it impossible to simplify build in first place. Today I 
am even scared to look at it now. Whether these cross dependencies are 
needed or not - I was not able to answer myself, yet most of properly 
designed systems tend to build directed dependencies free of cycles.


From looking at history of root build.xml I see 75 contributors who 
touched it. It is not a small number, I would say that for project witch 
such small amount of external dependencies it is a lot.
It is still a fair question if you will benefit from using other build 
tool. Yet I could put opposite question - where you would be, if you 
would make a change 7 years ago? How many hours of tweaking of Ant you 
would save?


With regard to linters I saw it used in openHAB, I know Apache Maven is 
looking to adopt an unified code style as well. In both cases ecosystem 
of these projects is quite large and amount of people doing 
contributions is larger than core team. Yet, even if cassandra is 
smaller in terms of people contributing patches, it has serious 
enterprise use cases. Spotless, the-last-npe and other build time 
plugins can assure that you never get a PR or patch with amended 
whitespaces or code formatting. Unnecessary parts will be fixed by tool 
so patch will contain only needed change. Whether you will enforce it by 
CI or by hand, that's other question. For sure staying with Ant doesn't


Best regards,
Łukasz


On 28.11.2022 22:19, Benedict wrote:
Scott makes some valid points about legitimate benefits. I personally 
doubt the high upfront cost of migration will take less than a decade to 
pay back in time saved managing shims. But, it’s a tangible 
justification. Conveniently the bulk of my contributions are also at 
Scott’s prerogative, so if he’s fine with me (and others) wasting their 
time battling Gradle or Maven, or losing time to the migration, then I 
think my complaint is functionally neutered.


I think, though, that those pushing such a disruptive change into others 
had better work very darn hard to deliver a smooth experience.


I tend to find that maintaining our current Ant build is a big waste 
of my time, and that every time I need to go to this layer its far 
more brittle than it should be


Whereas I find Ant an absolute pleasure, and Gradle a nightmare, and 
already regret using it for Accord. I wasted more than a day just trying 
to get some test artefacts in one module exposed in another, and 
eventually gave up. I have made dozens of forays into our Ant build and 
*never* abandoned my goal because I couldn’t accomplish it. I think 
people are really glossing over all the pain other build systems bring - 
even without our complex build requirements.


If you’re going to make the project adopt your preferred build system, 
you become responsible for the experience of everyone using it. Make 
sure you’re ready for that.



I think those pushing such a disruptive change on others had better 
work very darn hard to deliver a smooth experience.




On 28 Nov 2022, at 20:18, David Capwell  wrote:

I am strong +1 to new linters, I have been working on SpotBugs but 
not sent a patch due to sickness and holidays…


About the check style as the source of truth for the style guides, I 
am +1 to this as well… I feel that wiki is a bad place for this and we 
can use the check style file to generate the wiki text (no idea 

Re: [DISCUSS] Adding dependency to the Big-Math library from eobermuhlner

[Derek Chen-Becker]

Overall the library appears to be high quality, even going so far as
to have regression tests between versions. I do, however, think that
the long-term maintenance risk needs to be acknowledged here. I think
the *absolute* worst case scenario would be corruption or deletion of
source and artifacts, requiring the Cassandra community to either
re-implement the functions or remove them from CQL support. More
likely (having seen it happen once or twice) would be abandonment by
the author, requiring a fork and maintenance along with some
dependency modification (assuming the fork would have to be published
under a different group/artifact ID). I'm +1 for the addition of the
dependency on the basis of the apparent stability of the project, and
with the understanding that the functionality offered here is
ancillary to core Cassandra functionality.

Cheers,

Derek

On Mon, Nov 28, 2022 at 5:30 AM Josh McKenzie  wrote:
>
> I'm pleased with the rigor he shows on his explanations of implementation and 
> performance: http://obermuhlner.ch/wordpress/2016/06/02/bigdecimalmath/
>
> Seems like it's probably stable given the infrequency of changes to it and 
> he's still actively merging patches submit by others: 
> https://github.com/eobermuhlner/big-math/commits/master as of 8 days ago. 
> Only 4 issues open on the repo at this time as well for a reasonably starred 
> / forked library.
>
> I guess my one concern: this appears to be a library maintained primarily by 
> 1 person; that's a worst-case bus factor. Should he abandon the project is it 
> something we'd plan to fork and bring into tree and maintain ourselves? Given 
> how mature and stable it is I wouldn't be too worried, but worth considering 
> the worst-case.
>
>
> On Mon, Nov 28, 2022, at 3:48 AM, Benjamin Lerer wrote:
>
> Hi everybody,
>
> I wanted to discuss the addition of the Big-Math 
> library(http://eobermuhlner.github.io/big-math/)  as a dependency by  
> CASSANDRA-17221 which add support for abs, exp, log, log10, and round Math 
> function. The library was added for providing those functions for the 
> Cassandra decimal type (java BigDecimal).
>
> This patch has been started a long time ago and went through multiple rounds 
> of reviews and rework. In my enthusiasm to finally commit this patch I forgot 
> to raise the discussion to the mailing list about the dependency. I apologize 
> for that.
>
> Does anybody have some concerns with the addition of that Library as a 
> dependency?
>
>


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: [DISCUSS] Adding dependency to the Big-Math library from eobermuhlner

[J. D. Jordan]

Seems well maintained and MIT licensed. +1 from me.

> On Nov 28, 2022, at 6:35 PM, Derek Chen-Becker  wrote:
> 
> Overall the library appears to be high quality, even going so far as
> to have regression tests between versions. I do, however, think that
> the long-term maintenance risk needs to be acknowledged here. I think
> the *absolute* worst case scenario would be corruption or deletion of
> source and artifacts, requiring the Cassandra community to either
> re-implement the functions or remove them from CQL support. More
> likely (having seen it happen once or twice) would be abandonment by
> the author, requiring a fork and maintenance along with some
> dependency modification (assuming the fork would have to be published
> under a different group/artifact ID). I'm +1 for the addition of the
> dependency on the basis of the apparent stability of the project, and
> with the understanding that the functionality offered here is
> ancillary to core Cassandra functionality.
> 
> Cheers,
> 
> Derek
> 
>> On Mon, Nov 28, 2022 at 5:30 AM Josh McKenzie  wrote:
>> 
>> I'm pleased with the rigor he shows on his explanations of implementation 
>> and performance: http://obermuhlner.ch/wordpress/2016/06/02/bigdecimalmath/
>> 
>> Seems like it's probably stable given the infrequency of changes to it and 
>> he's still actively merging patches submit by others: 
>> https://github.com/eobermuhlner/big-math/commits/master as of 8 days ago. 
>> Only 4 issues open on the repo at this time as well for a reasonably starred 
>> / forked library.
>> 
>> I guess my one concern: this appears to be a library maintained primarily by 
>> 1 person; that's a worst-case bus factor. Should he abandon the project is 
>> it something we'd plan to fork and bring into tree and maintain ourselves? 
>> Given how mature and stable it is I wouldn't be too worried, but worth 
>> considering the worst-case.
>> 
>> 
>> On Mon, Nov 28, 2022, at 3:48 AM, Benjamin Lerer wrote:
>> 
>> Hi everybody,
>> 
>> I wanted to discuss the addition of the Big-Math 
>> library(http://eobermuhlner.github.io/big-math/)  as a dependency by  
>> CASSANDRA-17221 which add support for abs, exp, log, log10, and round Math 
>> function. The library was added for providing those functions for the 
>> Cassandra decimal type (java BigDecimal).
>> 
>> This patch has been started a long time ago and went through multiple rounds 
>> of reviews and rework. In my enthusiasm to finally commit this patch I 
>> forgot to raise the discussion to the mailing list about the dependency. I 
>> apologize for that.
>> 
>> Does anybody have some concerns with the addition of that Library as a 
>> dependency?
>> 
>> 
> 
> 
> -- 
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+