+1 to move these entries. On Wed, Mar 4, 2020 at 4:27 AM David Smiley <[email protected]> wrote:
> I'll simply move these items around tomorrow this time, unless I hear > feedback to the contrary. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Mon, Mar 2, 2020 at 1:07 PM David Smiley <[email protected]> > wrote: > >> I'd like us to reflect on how we categorize issues in CHANGES.txt. We >> have these categories: >> (Lucene) 'API Changes', 'New Features', 'Improvements', 'Optimizations', >> 'Bug Fixes', 'Other' >> (Solr) 'New Features', 'Improvements', 'Optimizations', 'Bug Fixes', >> 'Other Changes' >> (I lifted these from dev-tools/scripts/addVersion.py line 215) >> >> In particular, I'm often surprised at how some of us categorize New >> Features or Improvements that should better be categorized as something >> else. I think the root cause of these problems may be that we don't have >> JIRA categories that directly align. Furthermore, our dev practices will >> typically result in a CHANGES.txt being added out of band from the >> code-review process, and thus no peer-review on ideal placement. >> Furthermore the message itself is often not code reviewed but should be. >> Perhaps we can simply get in the habit of adding a JIRA comment (or GH code >> review) what we propose the category & issue summary should be. >> >> Here is my attempt at a definition for _some_ of these categories. I >> don't pretend to think we all agree 100% but it's up for discussion: >> ======== >> * New Features: A user-visible new capability. Usually opt-in. >> >> * Improvements: A user-visible improvement to an existing capability >> that somehow expands its ability or that which improves the behavior. Not >> a refactoring, not an optimization. >> >> * Optimizations: Something is now more efficient. Usually automatic (not >> opt-in). >> >> * Other: Anything else: Refactorings, tests, build, docs, etc. And >> adding log statements. >> ======== >> >> I recommend the following changes to Lucene 8.5: >> >> These are "Improvements" that I think are better categorized as >> "Optimizations" >> * LUCENE-9211: Add compression for Binary doc value fields. (Mark Harwood) >> * LUCENE-4702: Better compression of terms dictionaries. (Adrien Grand) >> * LUCENE-9228: Sort dvUpdates in the term order before applying if they >> all update a >> single field to the same value. This optimization can reduce the flush >> time by around >> 20% for the docValues update user cases. (Nhat Nguyen, Adrien Grand, >> Simon Willnauer) >> * LUCENE-9245: Reduce AutomatonTermsEnum memory usage. (Bruno Roustant, >> Robert Muir) >> * LUCENE-9237: Faster UniformSplit intersect TermsEnum. (Bruno Roustant) >> >> These "Improvements" I think are better categorized as "Other": >> * LUCENE-9109: Backport some changes from master (except StackWalker) to >> improve >> TestSecurityManager (Uwe Schindler) >> * LUCENE-9110: Backport refactored stack analysis in tests to use >> generalized >> LuceneTestCase methods (Uwe Schindler) >> * LUCENE-9141: Simplify LatLonShapeXQuery API by adding a new abstract >> class called LatLonGeometry. Queries are >> executed with input objects that extend such interface. (Ignacio Vera) >> * LUCENE-9194: Simplify XYShapeXQuery API by adding a new abstract class >> called XYGeometry. Queries are >> executed with input objects that extend such interface. (Ignacio Vera) >> >> Maybe this "Other" item should be "Optimization"? (not sure): >> * LUCENE-9068: FuzzyQuery builds its Automaton up-front (Alan Woodward, >> Mike Drob) >> >> Solr: >> >> "New Features" that maybe should be "Improvements": >> * SOLR-13892: New "top-level" docValues join implementation (Jason >> Gerlowski, Joel Bernstein) >> * SOLR-14242: HdfsDirectory now supports indexing geo-points, ranges or >> shapes. (Adrien Grand) >> >> "Improvements" that maybe should be "Optimizations": >> * SOLR-13808: filter in BoolQParser and {"bool":{"filter":..}} in Query >> DSL are cached by default (Mikhail Khludnev) >> >> "Improvements" that maybe should be "Other": >> * SOLR-14114: Add WARN to Solr log that embedded ZK is not supported in >> production (janhoy) >> >> Thoughts? >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> > -- Adrien
