This issues you listed are gray areas; I won't debate each with you. I respect your opinion. I just don't see the value of a section for *test* bug fixes. A user wants to know about the improvements, features, and bug fixes (to a running Solr instance). Everything else is just not as interesting to a user so goes in other, even though technically it's a bug fix (to a test).
On Thu, Apr 5, 2018 at 2:12 PM Chris Hostetter <[email protected]> wrote: > > : 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] > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
