Page History

...

• Technical
  • Big picture:  "Solr Cloud 2" isn't a rewrite; it's fixing a 100 little things that are greater than the sum of their parts.  Exception to this is pervasive use of Curator and large work in the Overseer.
  • Surprising insight: Seek performance and you may achieve stability – a more important goal
    • Our instability is difficult to diagnose because hard to reproduce problems
    • Focusing on performance tightens the timings and exposes real/existing problems that used to occur rarely
    • Me: Implies we have benchmarks regularly running, similar to Lucene nightly benchmarks
    • Another outcome may be code clarity / reasoning?
  • More use of Apache Curator
    • Not using Curator is tech debt.  Less code for us to maintain; simpler code remains.  Curator is faster & safer than our feeble attempts, generally.
    • Lets get familiar with it
  • Overseer
    • TBD if Mark left notes on what becomes of it.
  • Logging
    • Need continuous attention to cleanup.  Sometimes we don't log enough, sometimes too much.
    • Separate log configs depending on what work you are focusing on.
    • Colored logs.
  • Tech-Debt
    • We don't finish efforts.  Finishing means completely removing the old stuff.
    • Hurts the community; fewer contributors due to our complexity
• Community
  • Code reviews.  Do we change policy?
  • Should we adopt a formal decision process for proposing major changes/APIs to Solr, aka "Solr Implementation Proposal (SIP)"?
    • See proposal from Jörn Franke in dev@ referring to KIP and FLIP
  • Documentation
    • Code level, e.g. Javadocs
    • High level. new Dev guide somewhere (different from the Solr Ref Guide!)
      • See [Experimental] Getting Started with Solr Development

...