In my view this brings us up against a bit of an existential question. How
do we ensure quality of packages that are key to Solr? I'm sure that there
are folks who don't find the UI very useful, but it's important to others.
The rationale that "elastic keeps their's separate" has to be tempered by
the actual real differences between Elastic and Solr. Elastic has a
corporate sponsor, a coordinated road map, and explicitly ensures that all
the bits that are maintained separately work together (so that they don't
have excessive support costs or bad first experiences that impact their
bottom line etc.).
Solr is in a different place however, and we need to carefully examine the
question of whether something that works for Elastic works for us.
Lucidworks and several other large companies do spend a lot of money on
developers that contribute to Solr, but there is no organization around
multiple components that MUST work together. Another example of this is
Solr and Lucene, and our defense against a lack of coordination of
components in that case has been to unify them into a single release
So IMHO we need to answer 2 questions:
1.) Do we consider the UI important. If I'm alone or in a minority in
feeling it's important, then so be it and it doesn't really matter what we
do. (maybe a vote?)
2.) If we make it "a package" how do we ensure that important packages such
as the UI are never broken by a new release.
IMHO I don't thing we should tolerate a situation where things we consider
important are broken frequently.
For my part obviously my answer to 1 is "yes" :). As for 2, one thing that
comes to mind is what the Ant project did (may still do?) with (and my
memory from 15 years ago is foggy here, so forgive me if something I say is
not quite perfect) the GUMP build server that ran ant builds for a bunch of
different projects that depended on ant to ensure early detections of
changes that would break existing projects. If we have a good UI test suite
and commit to that being part of the release build package that might be a
solution. I honestly don't actually care where it lives, but I do think it
hurts us if it becomes broken and unusable, or hard to install.
My worry is that "Solr developers are not UI developers" is really
code-words for "I want to be able to break it and let others clean up the
mess, because I'm not a UI developer". I have this worry with respect to
all "packages", but I may be missing info from discussions about the
package system, which initiated during a very busy period for me so
background links that I should have read are welcome if I've got something
wrong here :) I went looking for a SIP but didn't see it... I have found a
google doc linked from SOLR-13661
Finally to a detail about one of the above suggestions the option to
automatically download and install the UI could be good, but that then
requires that packages be available from somewhere that never goes away
like maven central, or that Apache commits to hosting a repository server
indefinitely, but again that's surely been discussed WRT packages
already... Using Github in such a way is subject to being broken
arbitrarily when Github decides to restrict things for cost reasons (ask
Bower about that one WRT rate limiting...) or the "repository" has to be
something local and therefore must be included part of the distribution...
at which point it's still a thing we distribute and since we're
distributing it and we probably don't mean to distribute broken stuff we
still need UI developers...
Also, I thought the package loading stuff was supposed to be disabled by
default for security, that seems to conflict with or at least complicate
the notion of easily installing as a package.
So "package" is a good for modularizing code, or for 3rd party (possibly
paid) plugins (I have a client that might find that interesting in the
future) but we have to ensure that it doesn't lead to a lack of maintenance
for things that are critical.
Incidentally though I've said I favor Angular CLI, (significantly because
I've got some start on learning it) it also occurs to me that perhaps
anything "modern" is a difficulty because those things all have a learning
curve, and maximizing accessibility and ease of modifications for folks not
steeped in UI development might be our priority (different from the
priorities a commercial site would have). The flip side argument is that
with a popular framework, it would be easier for UI focused folks to
contribute... but will they? and does that leave us perennially rewriting
the UI in whatever is popular? (maybe that's ok?) I think in all our
decisions here we need to be very careful to distinguish how our needs may
differ in unusual ways from the needs of commercial web development.
On Thu, Apr 9, 2020 at 8:14 AM Erick Erickson <[EMAIL PROTECTED]>