Changeset size is ~300 files - much smaller than the thousands of files touched by spotless.
The tangible benefits being that error messages are no longer "assertion failed" but instead say what was different in the case of arrays the two arrays or in the case of some equals the two values. This in and of itself is a huge benefit to those debugging tests. So this isn't just stylistsic - it is actually improving the error message on failed tests. Regarding backporting stuff - the changes are over 300 files but most of the files have ~4-20 lines changed. They are in a few assertions - not most of them. So there is very little impact on backporting. The caveat being a few tests that had a lot of changes (~5 files?) - SQL and streaming expressions followed a bad pattern originally and so that is where there are ~1500 lines changed - but they are again simple changes and make the tests easier to read instead of just assertTrue everywhere. I don't think these hinder ongoing efforts in the right direction at all. This effort has uncovered different tests that weren't extending SolrTestCase so missing benefits like known randomization and thread leak checks. These little things add up over time and lead to harder to maintain code bases. This effort tries to get the code base back to a reasonable state for tests. It also provides good examples for those making new tests instead of copying the old. I know this clean up work doesn't seem like it is worth the effort - but I know it ends up leading to finding latent bugs and fixing real issues. These small cleanups make things like https://github.com/apache/solr/pull/1039 much easier since the tests have been standardized. These are all building blocks towards building a better Solr and hardening the code base we have. Kevin Risden On Tue, Oct 18, 2022 at 10:44 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I agree that these changes are good for the codebase. But, I am very much > disturbed by the changeset size. It will make backporting, working on > existing changes etc. a massive pain. I don't see the benefit enough to > outweigh the massive loss in productivity. Solr needs improvement in > efficiency, performance, ease of use etc. most urgently. Stylistic changes > like these don't contribute much there, rather hinder ongoing efforts in > the right direction. > > I'm -0 on this merge. > > On Tue, Oct 18, 2022 at 7:06 PM Eric Pugh <ep...@opensourceconnections.com > > > wrote: > > > Hi all, > > > > I started, and Kevin pushed to completion > > https://issues.apache.org/jira/browse/SOLR-16311, which is to simplify > > our assert logic. > > > > It touches 330 files, all various tests…. I think it’s a great > > enhancement, but before clicking merge, wanted to give a chance for > someone > > to speak up on why these stylistic changes should be reverted! > > > > I’d like to get this merged this week. > > > > Eric > > > > _______________________ > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com < > > http://www.opensourceconnections.com/> | My Free/Busy < > > http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > > > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw > > > > > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > >
