[jira] [Commented] (SOLR-14688) First party package implementation design

["Jason Gerlowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315482#comment-17315482 ] 

Jason Gerlowski commented on SOLR-14688:
----------------------------------------

Reading this thread again, there's a few big questions involved:

* Where do ASF-managed, "first-party", plugins live: in the {{solr}} repo? in some secondary "extras" repo? does it depend on the plugin?
* Should "first-party" plugins be shipped with Solr or downloaded separately after install?  Do we want a "fat" and "thin" distribution of Solr?
* How can we support offline loading of these "first-party" plugins (or any plugins)?
* What should the release-cycle for "first-party" plugins look like?  Only release with Solr?  Release as desired independent of Solr's release cadence or other plugins?
* If the latter option is chosen above, how should plugin-Solr cross compatibility be handled?  What testing infrastructure can we use to enable this?
* Should some or all of our contribs be repackaged as first-party plugins?  Is that unnecessary?

These questions are important, there's a lot of them, and they are interrelated in ways that make deciding any one question in isolation difficult.  I wonder whether it might be worth revisiting David's earlier suggestion to create a SIP for this work.  We've already had a ton of discussion around these questions, but it's been spread out in a number of threads (references below).  Many of these have started out looking to discuss a single piece of the puzzle, but fizzle out as the other dependencies/questions crop up.  Taking a step back and doing a more comprehensive SIP might push forward where other discussions have run aground, and produce a better overall design for the effort.

The previous SIP suggestion was skipped out of a desire to keep things moving quickly, which is totally fair. But since SOLR-14688 has sat for the better part of a year since then, the overhead of a SIP seems worth it IMO if it has a chance to get the discussion past some of the blockers.

If a SIP sounds good, I'd volunteer to get involved in the writeup and eventual implementation there.  Alternatively if anyone is sitting on code to solve some of these big questions or had existing plans to tackle this work soon, they might be in a better place to write things up.  Either way.  Curious what people think.


Past discussions: 
Slack 1: https://the-asf.slack.com/archives/CNMTSU970/p1582794103004800
Slack 2: https://the-asf.slack.com/archives/CNMTSU970/p1607019429038000
JIRA 1: https://issues.apache.org/jira/browse/SOLR-15089
Mail 1: http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E

> First party package implementation design
> -----------------------------------------
>
>                 Key: SOLR-14688
>                 URL: https://issues.apache.org/jira/browse/SOLR-14688
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Noble Paul
>            Priority: Major
>              Labels: package, packagemanager
>
> Here's the design document for first party packages:
> https://docs.google.com/document/d/1n7gB2JAdZhlJKFrCd4Txcw4HDkdk7hlULyAZBS-wXrE/edit?usp=sharing
> Put differently, this is about package-ifying our "contribs".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org