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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org