Hey folks,
Some of the committers attended the Activate 2019 conference, which took place
in Washington, DC on Sep 10-13.
The schedule was packed, so we managed to only have a ~1hr meeting during a
lunch break - nonetheless, I think it was still very productive!
Committers attending (at least some part of) the meeting, in no particular
order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun
Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.
Here are the notes I took - those attending, feel free to clear up any errors,
omissions or misunderstandings.
- Clean up tests that needlessly use AbstractDistribZk…
- because this class creates a control collection, which in many cases is
not needed.
- Consider reusing a single MiniSolrCloudCluster instance for multiple test
suites
- always use unique collection names per suite / test
- some suites won’t be able to use this due to a particular setup or
side-effects (sysprops, expected metrics, etc)
- those that can should execute much faster
- Deprecations in 8x - we still need to actually remove the stuff from master:
- old blob store
- old spatial
- other things?
- Replace NamedList with MapWriter?
- avoid creating objects during serialization
- big undertaking, but transition piece by piece
- example: ExportHandler / ExportWriter
- new API should use MapWriter instead of NamedList / Map
- public API changes have to go through deprecation in 8x and removal only
in 9
- We have three different and partially incomplete faceting impls
- do we want to do something about it to reduce confusion and code
footprint?
- V2 APIs are incomplete, there’s no workflow to maintain them in sync with v1.
Proposed strategy to improve this:
- move SolrJ to v2 - this could be done soon
- move Solr internally to use v2
- move tests to use v2 by default.
- RefGuide in 9.0 should show v2 examples by default
- deprecate v1
- come up with a better way of creating v2 api metadata (annotations?)
- Promote GitHub-centric approach to dev & collaboration
- PRs as the main method for submitting contributions
- How to Contribute should be the first section of the github page
- PR is opened - should automatically create a jira if it doesn’t exist yet
- discourage using patches when code review is expected.
- PR is more inviting for collaboration than a patch
- downside: PR is only for a single branch (no backport integration)
- travis integration?
- or use Github Actions for automated precommits, tests
- Javadocs, typos, small ref guide changes should not require a Jira issue with
its overheads
—--
Andrzej Białecki
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
