lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <david.w.smi...@gmail.com>
Subject Re: CHANGES.txt and issue categorization
Date Wed, 04 Mar 2020 03:26:43 GMT
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 <david.w.smiley@gmail.com>
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
>

Mime
View raw message