Tentative +1 to Hoss' questions.  I agree with his summary of the
potential risks here, and I share his ignorance of the perceived
benefits.

(I thought for a time that this was driven by interest in having
release cadences independent from Solr-core releases.  I'm all for
that goal, but if that's the motivation I'm not sure what the obstacle
is to doing that with a single repo - all build systems these days
support versioning and releasing modules independent of one another.
But maybe that was never a driving factor here.)

I know there have been a lot of discussions about this, and I know the
repo has already been created.  So maybe it's too late to object even
if I wanted to, which I'm not sure I do.  But can someone that
understands the motivation please summarize what multiple-repos gets
us over a single repo that outweighs the "cons" that Hoss mentioned?

Jason

On Thu, Jan 14, 2021 at 12:34 PM Chris Hostetter
<hossman_luc...@fucit.org> wrote:
>
>
> : As we discussed over the last few months, there seems a need to move
> : non-core pieces away from the Solr core module. The contribs are presently
> : a good place, but it makes sense to have a separate git repository hosting
> : such modules. Some candidates that come to mind are the present day contrib
>
> can you explain why it makes sense to have a separate git repo for these
> things?
>
> I can think of lots of reasons why it makes sense to have a single
> repo for all things solr (unified CI that quickly identifies if core
> changes break "first order" plugins, shared feature branches & monotomic
> commits of code that affects APIs and impls of those APIs, etc...) but
> I've yet to see any concrete specifics of why multiple git repos are
> "better" then just having distinct sub-projects (with distinct artifacts)
> in the same repo other then "it makes sense"
>
> why does it make sense?
>
> why can't the ideas of "solr-sandbox" and "solr-extras" just be
> directories in the "solr repo" ? ... what value is gained by making them
> new repos?
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to