: I just read through 7.4's Other Changes. IMO they belong where they are : except maybe SOLR-12176 (just by reading the notes here; I didn't go into : any issue). What is the point of adding a new section pertaining to tests?
Some of those are clearly "there was a bug ... and i fixed it" type issues -- which means they *should* belong in "Bug Fixes" ... the only reazon i can think of why they aren't is because they are specifically "there was a bug IN A TEST ... and i fixed it" type issues, and i'm speculating that they wound up in "Other" because folks didn't think of them as "real bugs" ... that's my only reason for suggesting a "Test Improvements/Fixes" IE: I don't think we need a new section, but if people don't want to put "test bug fixes" into "bug fixes" then i'd rather have a new section then dump them in "other" Some of these though -- based purely on reading the CHANGES entry from an end users perspective -- read as straight up bug fixes or new features in solr itself... * SOLR-12086: Fix format problem in FastLRUCache description string shown on Cache Statistics page. ... why is that not listed as a bug fix? it was evidently a problem that's now fixed -- isn't that the definition of a bug fix? * SOLR-12095: AutoScalingHandler validates trigger configurations before updating Zookeeper. ... why is that not listed as a bug fix (or a at least a new feature) ? it certainly sounds like prior to this there would have been a very bad outcome if you tried to use an invalid trigger confix. * SOLR-12176: Improve FORCELEADER to handle the case when a replica win the election but does not present in clusterstate ... why is that not listed as a bug fix (or a at least a new feature) ? ... again: it sounds really scary that prior to this "something" (presumably bad) would hapen if a replica not in the cluster state won the election. Maybe the issue is that these are just poorly worded CHANGES entires that make things sound worse/better/more-significant then they really are? but if that's the case let's fix the text to more accurately reflect why they aren't significant enough to be considered "bugs" (or "new features" if people feel there is justification in saying "it wasn't really broken before, but it's better now"). As things stand now, from the perspective of a user, i'm left thinking "Whoa ... if autoscaling triggers weren't validated before this release, and that didn't even merit being categorized as a 'bug fix' and was just noted as an 'Other' change, then what other really scary stuff might not even merrit a mention at all? : On Thu, Apr 5, 2018 at 1:22 PM Chris Hostetter <[email protected]> : wrote: : : > : > The "Other Changes" list in the 7.4 section of solr/CHANGES.txt is : > currently the largest list (by number if jiras) for all of 7.4 -- and : > includes many things that AFAICT really seem like they should : > be listed in one of the more specific list: New Features, Bug Fixes, : > Optimizations. : > : > I would like to suggest that committers should really second guess any : > inclinaion to put something in "Other Changes" before doing so .. it : > should really be the choice of last resort. users should be able to : > understand at a glance what important changes tye may care about, and : > burying stuffin "Other" makes that hard. : > : > A good rule of thumb is that if your CHANGES entry uses words "Fix" or : > "Improve" then that really sounds like a Bug Fix. If folks are worried : > about "pollutting" the Bug Fixes section with fixes to *test* bugs, then : > let's break them out into a new "Test Improvements/Fixes" section. : > : > : > : > -Hoss : > http://www.lucidworks.com/ : > : > --------------------------------------------------------------------- : > To unsubscribe, e-mail: [email protected] : > For additional commands, e-mail: [email protected] : > : > -- : Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker : LinkedIn: http://linkedin.com/in/davidwsmiley | Book: : http://www.solrenterprisesearchserver.com : -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
