Re: Solr Admin UI Refresh 2020

[Marcus Eagan]

I think package management frameworks are for loading non-essential
features or features not enabled by default. On essentialness,  experts
should not decide what is essential based on how they use a system. They
should consider the community of users. Regarding UI, it is and should be
enabled by default. Only a few use cases prefer it to be disabled and some
of those are because of its current state. They would like to use it in an
updated form.

What is the technical rationale that outweighs the needs and behaviors of
our users to strip the user interface out of Solr?

Thank you Noble and everyone else,
Marcus


On Thu, Apr 9, 2020 at 19:06 Noble Paul  wrote:

> My 2 cents (again)
>
> if packages are disabled by default , how will UI work?
>
> We can make an exception for this one and enable only this by default
>
> Do we test the UI and certify it?
>
> The UI package can be shipped along with Solr distro ,like the million
> other jars that we ship with Solr today and every version of Solr can
> be certified for a certain version of the UI package. We should have
> sanity tests to ensure that the given version of UI works well with
> Solr. "My commit has broken the UI and it's not my problem" should not
> be a valid excuse. The UI sanity tests should pass as a part of the
> tests.
>
> Is the UI important?
>
> Yes, the admin UI is the face of Solr for may users. People always
> assumed it existed & they depend on it.
>
> The current admin UI has fallen behind. If the new UI effort delivers
> on the promise, this is a great opportunity to get rid of that old
> baggage & make Solr codebase even slimmer
>
> On Fri, Apr 10, 2020 at 6:06 AM Jan Høydahl  wrote:
> >
> > Solr has always had an admin UI and if anyone wants to propose it should
> not, please start another thread or vote about that, and do not divert this
> thread which is about how to improve and future proof the Admin UI.
> >
> > I believe the Admin UI should be strengthened and enhanced, not removed.
> It can perfectly well be an official and even default on part of every
> release, perfectly in sync. Whether it is in core as today or a package or
> a stand-alone process or a new webapp, are then really what we discuss here.
> >
> > Perhaps after people have voiced their opinions in this thread, a SIP
> can be crafted with a concrete plan. We can then have a vote on the SIP.
> >
> > Jan Høydahl
> >
> > > 9. apr. 2020 kl. 20:06 skrev Cassandra Targett  >:
> > >
> > > 
> > > Thanks for your message, Gus. You touched on things I was thinking
> this morning as I caught up to the thread, and had started to draft a
> message about.
> > >
> > > I feel like there is an assumption underlying some of our discussion
> about packages that says a feature or whatever has to either part of our
> core codebase or 100% maintained by someone “outside” the community (by
> which I mean someone who is not a committer and/or operates completely
> independently from the rest of the project activities).
> > >
> > > But it’s important to remember there’s nothing inherent in the package
> concept that says a package can't be wholly
> maintained/distributed/supported by the Lucene PMC and our community of
> committers and contributors. It’s not uncommon for software to have a base
> package of the core software and also plugins that most users would
> consider “essential”, maintained by the same people making the core, but
> which are added after the base install. There would be details to work out
> in terms of how we manage that, but none of those are technically
> impossible. I don’t think we only have a binary choice (3rd party package
> or part of Solr core).
> > >
> > > In fact, I’d go so far as to say I suspect the only way packages are
> going to see any real traction is if we take the lead in creating and
> maintaining a few to show the way forward for everyone else who may be
> interested in doing the same. The package concept introduces an idea of a
> Solr ecosystem that has not really existed to date and like all new
> ecosystems (communities), it needs some degree of nurturing to grow or it
> will not take off.
> > >
> > > To bring it back around to the UI, though, I agree we need to decide:
> is a UI important? I would argue that it is. I regularly talk to users
> whose Solr knowledge and experience are quite advanced yet who still rely
> entirely on the UI to carry out basic tasks. It’s just easier - less to
> remember, don’t need to look up a command, etc. Persistent problems with
> performance of the UI in large clusters and gaping holes in functionality
> are deeply frustrating to those users.
> > >
> > > Because it is important to our users, even if any new UI ends up
> living outside our community, it will need our explicit approval in some
> form or we’re going to hear complaints until the end of time that Solr
> doesn’t have a UI (or worse, we “took away” the UI). Without our ongoing
> endorsement and blessing it will just be another toy maintained 

Re: Solr Admin UI Refresh 2020

[Noble Paul]

My 2 cents (again)

if packages are disabled by default , how will UI work?

We can make an exception for this one and enable only this by default

Do we test the UI and certify it?

The UI package can be shipped along with Solr distro ,like the million
other jars that we ship with Solr today and every version of Solr can
be certified for a certain version of the UI package. We should have
sanity tests to ensure that the given version of UI works well with
Solr. "My commit has broken the UI and it's not my problem" should not
be a valid excuse. The UI sanity tests should pass as a part of the
tests.

Is the UI important?

Yes, the admin UI is the face of Solr for may users. People always
assumed it existed & they depend on it.

The current admin UI has fallen behind. If the new UI effort delivers
on the promise, this is a great opportunity to get rid of that old
baggage & make Solr codebase even slimmer

On Fri, Apr 10, 2020 at 6:06 AM Jan Høydahl  wrote:
>
> Solr has always had an admin UI and if anyone wants to propose it should not, 
> please start another thread or vote about that, and do not divert this thread 
> which is about how to improve and future proof the Admin UI.
>
> I believe the Admin UI should be strengthened and enhanced, not removed. It 
> can perfectly well be an official and even default on part of every release, 
> perfectly in sync. Whether it is in core as today or a package or a 
> stand-alone process or a new webapp, are then really what we discuss here.
>
> Perhaps after people have voiced their opinions in this thread, a SIP can be 
> crafted with a concrete plan. We can then have a vote on the SIP.
>
> Jan Høydahl
>
> > 9. apr. 2020 kl. 20:06 skrev Cassandra Targett :
> >
> > 
> > Thanks for your message, Gus. You touched on things I was thinking this 
> > morning as I caught up to the thread, and had started to draft a message 
> > about.
> >
> > I feel like there is an assumption underlying some of our discussion about 
> > packages that says a feature or whatever has to either part of our core 
> > codebase or 100% maintained by someone “outside” the community (by which I 
> > mean someone who is not a committer and/or operates completely 
> > independently from the rest of the project activities).
> >
> > But it’s important to remember there’s nothing inherent in the package 
> > concept that says a package can't be wholly 
> > maintained/distributed/supported by the Lucene PMC and our community of 
> > committers and contributors. It’s not uncommon for software to have a base 
> > package of the core software and also plugins that most users would 
> > consider “essential”, maintained by the same people making the core, but 
> > which are added after the base install. There would be details to work out 
> > in terms of how we manage that, but none of those are technically 
> > impossible. I don’t think we only have a binary choice (3rd party package 
> > or part of Solr core).
> >
> > In fact, I’d go so far as to say I suspect the only way packages are going 
> > to see any real traction is if we take the lead in creating and maintaining 
> > a few to show the way forward for everyone else who may be interested in 
> > doing the same. The package concept introduces an idea of a Solr ecosystem 
> > that has not really existed to date and like all new ecosystems 
> > (communities), it needs some degree of nurturing to grow or it will not 
> > take off.
> >
> > To bring it back around to the UI, though, I agree we need to decide: is a 
> > UI important? I would argue that it is. I regularly talk to users whose 
> > Solr knowledge and experience are quite advanced yet who still rely 
> > entirely on the UI to carry out basic tasks. It’s just easier - less to 
> > remember, don’t need to look up a command, etc. Persistent problems with 
> > performance of the UI in large clusters and gaping holes in functionality 
> > are deeply frustrating to those users.
> >
> > Because it is important to our users, even if any new UI ends up living 
> > outside our community, it will need our explicit approval in some form or 
> > we’re going to hear complaints until the end of time that Solr doesn’t have 
> > a UI (or worse, we “took away” the UI). Without our ongoing endorsement and 
> > blessing it will just be another toy maintained by “somebody” (no offense, 
> > Marcus) until he is forced to abandon it due to lack of user interest 
> > and/or lack of personal time to do all the heavy lifting by himself.
> >
> > Cassandra
> >> On Apr 9, 2020, 11:32 AM -0500, Erick Erickson , 
> >> wrote:
> >> Gus:
> >>
> >> Very thoughtful post. I think you raise an _extremely_ important point 
> >> about “how critical is the UI?” And by extension other packages. If 
> >> they’re critical to Solr, the question of how to keep them in sync becomes 
> >> paramount.
> >>
> >> I agree that the admin UI is important, if we have a mechanism to insure 
> >> it’s kept in sync with the release that would be 

Re: Solr Admin UI Refresh 2020

[Jan Høydahl]

Solr has always had an admin UI and if anyone wants to propose it should not, 
please start another thread or vote about that, and do not divert this thread 
which is about how to improve and future proof the Admin UI.

I believe the Admin UI should be strengthened and enhanced, not removed. It can 
perfectly well be an official and even default on part of every release, 
perfectly in sync. Whether it is in core as today or a package or a stand-alone 
process or a new webapp, are then really what we discuss here.

Perhaps after people have voiced their opinions in this thread, a SIP can be 
crafted with a concrete plan. We can then have a vote on the SIP.

Jan Høydahl

> 9. apr. 2020 kl. 20:06 skrev Cassandra Targett :
> 
> 
> Thanks for your message, Gus. You touched on things I was thinking this 
> morning as I caught up to the thread, and had started to draft a message 
> about.
> 
> I feel like there is an assumption underlying some of our discussion about 
> packages that says a feature or whatever has to either part of our core 
> codebase or 100% maintained by someone “outside” the community (by which I 
> mean someone who is not a committer and/or operates completely independently 
> from the rest of the project activities).
> 
> But it’s important to remember there’s nothing inherent in the package 
> concept that says a package can't be wholly maintained/distributed/supported 
> by the Lucene PMC and our community of committers and contributors. It’s not 
> uncommon for software to have a base package of the core software and also 
> plugins that most users would consider “essential”, maintained by the same 
> people making the core, but which are added after the base install. There 
> would be details to work out in terms of how we manage that, but none of 
> those are technically impossible. I don’t think we only have a binary choice 
> (3rd party package or part of Solr core).
> 
> In fact, I’d go so far as to say I suspect the only way packages are going to 
> see any real traction is if we take the lead in creating and maintaining a 
> few to show the way forward for everyone else who may be interested in doing 
> the same. The package concept introduces an idea of a Solr ecosystem that has 
> not really existed to date and like all new ecosystems (communities), it 
> needs some degree of nurturing to grow or it will not take off.
> 
> To bring it back around to the UI, though, I agree we need to decide: is a UI 
> important? I would argue that it is. I regularly talk to users whose Solr 
> knowledge and experience are quite advanced yet who still rely entirely on 
> the UI to carry out basic tasks. It’s just easier - less to remember, don’t 
> need to look up a command, etc. Persistent problems with performance of the 
> UI in large clusters and gaping holes in functionality are deeply frustrating 
> to those users.
> 
> Because it is important to our users, even if any new UI ends up living 
> outside our community, it will need our explicit approval in some form or 
> we’re going to hear complaints until the end of time that Solr doesn’t have a 
> UI (or worse, we “took away” the UI). Without our ongoing endorsement and 
> blessing it will just be another toy maintained by “somebody” (no offense, 
> Marcus) until he is forced to abandon it due to lack of user interest and/or 
> lack of personal time to do all the heavy lifting by himself.
> 
> Cassandra
>> On Apr 9, 2020, 11:32 AM -0500, Erick Erickson , 
>> wrote:
>> Gus:
>> 
>> Very thoughtful post. I think you raise an _extremely_ important point about 
>> “how critical is the UI?” And by extension other packages. If they’re 
>> critical to Solr, the question of how to keep them in sync becomes paramount.
>> 
>> I agree that the admin UI is important, if we have a mechanism to insure 
>> it’s kept in sync with the release that would be near the to of my list.
>> 
>> Best,
>> Erick
>> 
>>> On Apr 9, 2020, at 12:06 PM, Gus Heck  wrote:
>>> 
>>> 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. 

Re: Welcome Eric Pugh as a Lucene/Solr committer

[Michael Sokolov]

Welcome Eric Pugh!

On Thu, Apr 9, 2020 at 11:57 AM Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
>
> Welcome Eric!
>
> Christine
>
> From: dev@lucene.apache.org At: 04/07/20 14:57:43
> To: dev@lucene.apache.org
> Subject: Re: Welcome Eric Pugh as a Lucene/Solr committer
>
> Thank you everyone!  I’ll keep it short, otherwise this will be a very long 
> email… ;-).
>
> I was first introduced to Solr and Lucene by Erik Hatcher, and today I wonder 
> what my life would be like if he hadn’t taken the time to show me some cool 
> code he was working on and explained to me the way to change the world was 
> through open source contributions!
>
> I co-founded OpenSource Connections (http://o19s.com) along with Scott Stults 
> and Jason Hull in 2005.  We found our niche in Solr consulting after I went 
> to the first LuceneRevolution and got inspired (complete with Jerry Maguire 
> style manifesto shared with the company). Through consulting, I get to help 
> onboard organizations into the Solr community - a thriving, healthy ASF is 
> very near & dear to my heart.
>
> I’ve been around this community for a long time, with my first JIRA being 
> three digits: SOLR-284.  Today, I’m still contributing to Apache Tika. I’ve 
> gotten to meet and spend some significant time with Tim Allison from that 
> project and learned a LOT about text!
>
> I was in the right place at the right time and was able to join David Smiley 
> as co-author on the first Solr book, we went on and did a total of three 
> editions of that book.  Phew!
>
> Once I got to sit on stage as a judge for Stump the Chump, it was Erick, 
> Erik, and Eric ;-)
>
> After doing Solr for a good while, I got lucky and met Doug Turnbull on the 
> sidewalk one day because he had on a t-shirt that said “My code doesn’t have 
> bugs, it has unexpected features”.   Couple of years later he and fellow 
> colleague John Berryman published Relevant Search and today I’m working in 
> the fascinating intersection of people, Search, and Data Science helping 
> build smarter search experiences as a Relevance Strategist. I'm excited about 
> bringing relevance use cases 'down to earth'. I also steward OSC's 
> contributions to the open source tool Quepid to help fulfill that goal.
>
> Oh, and I’ve got a stack of LuceneRevolution and related conference t-shirts 
> that my mother turned into a fantastic quilt ;-).
>
> Eric
>
>
>
> On Apr 6, 2020, at 9:39 PM, Shalin Shekhar Mangar  
> wrote:
>
> Congratulations and welcome Eric!
>
> On Mon, Apr 6, 2020 at 5:51 PM Jan Høydahl  wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Eric Pugh as the latest Lucene/Solr committer!
>>
>> Eric has been part of the Solr community for over a decade, as a code 
>> contributor, book author, company founder, blogger and mailing list 
>> contributor! We look forward to his future contributions!
>>
>> Congratulations and welcome! It is a tradition to introduce yourself with a 
>> brief bio, Eric.
>>
>> Jan Høydahl
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com | My Free/Busy
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
>
>

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

Re: Solr Admin UI Refresh 2020

[Cassandra Targett]

Thanks for your message, Gus. You touched on things I was thinking this morning 
as I caught up to the thread, and had started to draft a message about.

I feel like there is an assumption underlying some of our discussion about 
packages that says a feature or whatever has to either part of our core 
codebase or 100% maintained by someone “outside” the community (by which I mean 
someone who is not a committer and/or operates completely independently from 
the rest of the project activities).

But it’s important to remember there’s nothing inherent in the package concept 
that says a package can't be wholly maintained/distributed/supported by the 
Lucene PMC and our community of committers and contributors. It’s not uncommon 
for software to have a base package of the core software and also plugins that 
most users would consider “essential”, maintained by the same people making the 
core, but which are added after the base install. There would be details to 
work out in terms of how we manage that, but none of those are technically 
impossible. I don’t think we only have a binary choice (3rd party package or 
part of Solr core).

In fact, I’d go so far as to say I suspect the only way packages are going to 
see any real traction is if we take the lead in creating and maintaining a few 
to show the way forward for everyone else who may be interested in doing the 
same. The package concept introduces an idea of a Solr ecosystem that has not 
really existed to date and like all new ecosystems (communities), it needs some 
degree of nurturing to grow or it will not take off.

To bring it back around to the UI, though, I agree we need to decide: is a UI 
important? I would argue that it is. I regularly talk to users whose Solr 
knowledge and experience are quite advanced yet who still rely entirely on the 
UI to carry out basic tasks. It’s just easier - less to remember, don’t need to 
look up a command, etc. Persistent problems with performance of the UI in large 
clusters and gaping holes in functionality are deeply frustrating to those 
users.

Because it is important to our users, even if any new UI ends up living outside 
our community, it will need our explicit approval in some form or we’re going 
to hear complaints until the end of time that Solr doesn’t have a UI (or worse, 
we “took away” the UI). Without our ongoing endorsement and blessing it will 
just be another toy maintained by “somebody” (no offense, Marcus) until he is 
forced to abandon it due to lack of user interest and/or lack of personal time 
to do all the heavy lifting by himself.

Cassandra
On Apr 9, 2020, 11:32 AM -0500, Erick Erickson , wrote:
> Gus:
>
> Very thoughtful post. I think you raise an _extremely_ important point about 
> “how critical is the UI?” And by extension other packages. If they’re 
> critical to Solr, the question of how to keep them in sync becomes paramount.
>
> I agree that the admin UI is important, if we have a mechanism to insure it’s 
> kept in sync with the release that would be near the to of my list.
>
> Best,
> Erick
>
> > On Apr 9, 2020, at 12:06 PM, Gus Heck  wrote:
> >
> > 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 
> > package.
> >
> > 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 

Re: Solr Admin UI Refresh 2020

[Erick Erickson]

Gus:

Very thoughtful post. I think you raise an _extremely_ important point about 
“how critical is the UI?” And by extension other packages. If they’re critical 
to Solr, the question of how to keep them in sync becomes paramount.

I agree that the admin UI is important, if we have a mechanism to insure it’s 
kept in sync with the release that would be near the to of my list.

Best,
Erick 

> On Apr 9, 2020, at 12:06 PM, Gus Heck  wrote:
> 
> 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 package. 
> 
> 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 

Re: Solr Admin UI Refresh 2020

[Gus Heck]

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
package.

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.

-Gus

On Thu, Apr 9, 2020 at 8:14 AM Erick Erickson 
wrote:

> Marcus:
>
> re-reading the thread, it looks to me like the consensus from Noble and
> Ishan and Jan 

Re: Welcome Eric Pugh as a Lucene/Solr committer

[Christine Poerschke (BLOOMBERG/ LONDON)]

Welcome Eric!

Christine

From: dev@lucene.apache.org At: 04/07/20 14:57:43To:  dev@lucene.apache.org
Subject: Re: Welcome Eric Pugh as a Lucene/Solr committer

Thank you everyone!  I’ll keep it short, otherwise this will be a very long 
email… ;-). 
I was first introduced to Solr and Lucene by Erik Hatcher, and today I wonder 
what my life would be like if he hadn’t taken the time to show me some cool 
code he was working on and explained to me the way to change the world was 
through open source contributions!
I co-founded OpenSource Connections (http://o19s.com) along with Scott Stults 
and Jason Hull in 2005.  We found our niche in Solr consulting after I went to 
the first LuceneRevolution and got inspired (complete with Jerry Maguire style 
manifesto shared with the company). Through consulting, I get to help onboard 
organizations into the Solr community - a thriving, healthy ASF is very near & 
dear to my heart. 
I’ve been around this community for a long time, with my first JIRA being three 
digits: SOLR-284.  Today, I’m still contributing to Apache Tika.  I’ve gotten 
to meet and spend some significant time with Tim Allison from that project and 
learned a LOT about text!
I was in the right place at the right time and was able to join David Smiley as 
co-author on the first Solr book, we went on and did a total of three editions 
of that book.  Phew!
Once I got to sit on stage as a judge for Stump the Chump, it was Erick, Erik, 
and Eric ;-)
After doing Solr for a good while, I got lucky and met Doug Turnbull on the 
sidewalk one day because he had on a t-shirt that said “My code doesn’t have 
bugs, it has unexpected features”.   Couple of years later he and fellow 
colleague John Berryman published Relevant Search and today I’m working in the 
fascinating intersection of people, Search, and Data Science helping build 
smarter search experiences as a Relevance Strategist. I'm excited about 
bringing relevance use cases 'down to earth'. I also steward OSC's 
contributions to the open source tool Quepid to help fulfill that goal.
Oh, and I’ve got a stack of LuceneRevolution and related conference t-shirts 
that my mother turned into a fantastic quilt ;-).  
Eric


On Apr 6, 2020, at 9:39 PM, Shalin Shekhar Mangar  
wrote:
Congratulations and welcome Eric!

On Mon, Apr 6, 2020 at 5:51 PM Jan Høydahl  wrote:

Hi all,

Please join me in welcoming Eric Pugh as the latest Lucene/Solr committer!

Eric has been part of the Solr community for over a decade, as a code 
contributor, book author, company founder, blogger and mailing list 
contributor! We look forward to his future contributions!

Congratulations and welcome! It is a tradition to introduce yourself with a 
brief bio, Eric.

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


-- 
Regards,
Shalin Shekhar Mangar.

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com | My Free/Busy  
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such. 

Re: Solr Admin UI Refresh 2020

[Erick Erickson]

Marcus:

re-reading the thread, it looks to me like the consensus from Noble and Ishan 
and Jan is that as long as the new, nifty UI is a separate package, go ahead 
and knock yourself out ;). The objection is to making it part of the Solr code 
base… We’ll all be thrilled with if we can rip the current admin UI out ;)

That said, I suspect it’ll be one of the tighter packages. It’d be super-cool 
if we could run the UI tests on Jenkins say once a day just to keep it up to 
date.

The admin UI has always been somewhat awkwardly bolted on the side of Solr, 
it’d be great to have it have a more elegant architecture.

The other exciting thing would be that clients could then use the package code 
as something they can incorporate/fork/whatever. Practically every client I’ve 
worked with at large installations has rolled their own dashboard. If they 
could use a package as a starting point, it’d be welcome.

Best,
Erick

> On Apr 9, 2020, at 3:07 AM, Marcus Eagan  wrote:
> 
> Hey Noble, 
> 
> -1 is a definitive, so I want to clarify that you are saying you do not wish 
> to remove the EOL front end and replace it with another one in the longer 
> term?
> 
> I hear you! As a product manager in  my day job, my primary goal is to find 
> features to cut! I spend a lot of time thinking about non-essential vs used 
> heavily vs causes more problems than it's worth. I can tell you from watching 
> the many people in the field at Lucidworks, there are a lot of people who 
> know quite a bit about Solr, but rely on the Admin UI heavily because they 
> feel comfortable there. Those people in effect help us stay employed despite 
> never contributing or being capable of contributing to Solr. So hear me out. 
> I've got a proposal:
> 
> To start, I can work on this app as an optional package for your awesome new 
> package manager. It will be the second one I've worked on in my evenings and 
> weekends btw. The first was a package validator that I hope to eventually 
> open source, but its complexity and lack of popularity because it is security 
> ;( will likely make it the second one I open source/finish. I'm also 
> collaborating with a couple members of the Lucidworks security team on that 
> one, but I have built the basics already for them to build upon.
> 
> Back to the new UI discussion and my update that I promised. 
> 
> My update was going to be that after evaluating the projects Jan posted, the 
> most recent project that Jan listed created a pretty good base to build on. 
> After lots of auditing of the packages and a bit of refactoring because the 
> UI world moves fast, I was able to get it to transpile and run again (as I'm 
> sure it previously did) and from (2290 vulns):
> 
> no npm fix doesn't magically fix, I wish it did
> 
> to (2 low sev, non-productions vulns):
> 
> 
> These two issues will not affect production and really only the unit tests. 
> Besides, I plan to remove them before we get to a stage even that matters. 
> I've also started investigating the level of effort for me to get it to 
> feature parity with the current app. The preliminary answer is not very much 
> compared to other work I've done in shorter time — working with a jerk for a 
> boss (years ago, don't worry Hatcher). I'm building a couple of the missing 
> features as we speak. From the beginning, it will have infinitely more test 
> coverage and will be a lot more approachable to contemporary UI developers. 
> It will also make the Solr experience for new developers simpler. The major 
> design changes that I have been thinking about would be to the cloud view and 
> the query view. Both of those are important, the first to more experienced 
> users, and the second to less advanced users though occasionally an advanced 
> debugger or demo presenter in my experience.
> 
> In the end Noble, this is about making Solr more approachable to new users 
> not experts like you. The growth of Solr adoption only benefits you, so I 
> would ask you to revisit your -1 at some point in the near future when you 
> see the progress and breadth of improvement. We have had customers complain 
> about the Admin UI and the community has even complained about it. I think 
> this is the right thing to do. If you still consider effectively upgrading 
> the current Admin UI as feature creep, I can revisit the package manager 
> compromise or move the efforts elsewhere. I respect your position. A search 
> service is nothing without a strong and diverse set of skills and 
> capabilities behind it and making it accessible to everyone who needs it. 
> 
> For those who care, here's my 4 Node cluster of tech products running 
> locally. 
> 
> 
> 
> The shoulders of the homie that put that scaffold together are broad! Props 
> to him. I will volunteer to put together extensive docs for JS devs who want 
> to contribute and make it better once we get it to a place where it replaces 
> and improves upon the current option. I'll even sponsor some prizes 

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 4532 - Unstable

[Dawid Weiss]

Oh, ok. Adrien fixed it. 3363e1aa4897a5eca9f390a9f22cab5686305ef7

On Thu, Apr 9, 2020 at 1:41 PM Dawid Weiss  wrote:
>
> Can't reproduce this one.
>
> On Tue, Apr 7, 2020 at 3:28 PM Apache Jenkins Server
>  wrote:
> >
> > Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/4532/
> >
> > 1 tests failed.
> > FAILED:  
> > org.apache.lucene.codecs.uniformsplit.TestUniformSplitPostingFormat.testRandom
> >
> > Error Message:
> > Captured an uncaught exception in thread: Thread[id=328, name=Thread-295, 
> > state=RUNNABLE, group=TGRP-TestUniformSplitPostingFormat]
> >
> > Stack Trace:
> > com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> > uncaught exception in thread: Thread[id=328, name=Thread-295, 
> > state=RUNNABLE, group=TGRP-TestUniformSplitPostingFormat]
> > Caused by: java.lang.RuntimeException: java.lang.AssertionError: 
> > buffer=java.nio.HeapByteBuffer[pos=0 lim=0 cap=0] bufferSize=1024 
> > buffer.length=0
> > at __randomizedtesting.SeedInfo.seed([6687BF0E1CDB57A2]:0)
> > at 
> > org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1229)
> > Caused by: java.lang.AssertionError: buffer=java.nio.HeapByteBuffer[pos=0 
> > lim=0 cap=0] bufferSize=1024 buffer.length=0
> > at 
> > org.apache.lucene.store.BufferedIndexInput.setBufferSize(BufferedIndexInput.java:78)
> > at 
> > org.apache.lucene.codecs.MultiLevelSkipListReader.loadSkipLevels(MultiLevelSkipListReader.java:241)
> > at 
> > org.apache.lucene.codecs.MultiLevelSkipListReader.init(MultiLevelSkipListReader.java:208)
> > at 
> > org.apache.lucene.codecs.lucene84.Lucene84SkipReader.init(Lucene84SkipReader.java:103)
> > at 
> > org.apache.lucene.codecs.lucene84.Lucene84PostingsReader$BlockDocsEnum.advance(Lucene84PostingsReader.java:481)
> > at 
> > org.apache.lucene.index.RandomPostingsTester.verifyEnum(RandomPostingsTester.java:960)
> > at 
> > org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1351)
> > at 
> > org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1227)

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

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 4532 - Unstable

[Dawid Weiss]

Can't reproduce this one.

On Tue, Apr 7, 2020 at 3:28 PM Apache Jenkins Server
 wrote:
>
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/4532/
>
> 1 tests failed.
> FAILED:  
> org.apache.lucene.codecs.uniformsplit.TestUniformSplitPostingFormat.testRandom
>
> Error Message:
> Captured an uncaught exception in thread: Thread[id=328, name=Thread-295, 
> state=RUNNABLE, group=TGRP-TestUniformSplitPostingFormat]
>
> Stack Trace:
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=328, name=Thread-295, state=RUNNABLE, 
> group=TGRP-TestUniformSplitPostingFormat]
> Caused by: java.lang.RuntimeException: java.lang.AssertionError: 
> buffer=java.nio.HeapByteBuffer[pos=0 lim=0 cap=0] bufferSize=1024 
> buffer.length=0
> at __randomizedtesting.SeedInfo.seed([6687BF0E1CDB57A2]:0)
> at 
> org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1229)
> Caused by: java.lang.AssertionError: buffer=java.nio.HeapByteBuffer[pos=0 
> lim=0 cap=0] bufferSize=1024 buffer.length=0
> at 
> org.apache.lucene.store.BufferedIndexInput.setBufferSize(BufferedIndexInput.java:78)
> at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.loadSkipLevels(MultiLevelSkipListReader.java:241)
> at 
> org.apache.lucene.codecs.MultiLevelSkipListReader.init(MultiLevelSkipListReader.java:208)
> at 
> org.apache.lucene.codecs.lucene84.Lucene84SkipReader.init(Lucene84SkipReader.java:103)
> at 
> org.apache.lucene.codecs.lucene84.Lucene84PostingsReader$BlockDocsEnum.advance(Lucene84PostingsReader.java:481)
> at 
> org.apache.lucene.index.RandomPostingsTester.verifyEnum(RandomPostingsTester.java:960)
> at 
> org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1351)
> at 
> org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1227)

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

Re: [VOTE] Release Lucene/Solr 8.5.1 RC1

[jim ferenczi]

+1

SUCCESS! [2:10:08.094546]

Le jeu. 9 avr. 2020 à 10:19, Alan Woodward  a écrit :

> +1
>
> SUCCESS! [1:18:54.574272]
>
> On 8 Apr 2020, at 21:21, Nhat Nguyen 
> wrote:
>
> +1
>
> SUCCESS! [0:52:20.920081]
>
>
> On Wed, Apr 8, 2020 at 6:31 AM Ignacio Vera  wrote:
>
>>
>> Please vote for release candidate 1 for Lucene/Solr 8.5.1
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
>>
>> The vote will be open for at least 72 hours i.e. until 2020-04-15 11:00
>> UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>>
>> SUCCESS! [1:02:16.691004]
>>
>>
>

Re: Solr Admin UI Refresh 2020

[Geza Nagy]

Hi,
However I'm not a "UI expert" but I worked on various webapps (Webshops,
Banking clients etc.) And I worked with several js libs (jquery, early
angular, extjs, React, Vue, etc).
>From my experience:
- From technical perspective there will be no "better" choice, all
frameworks has pros and cons and all of them can do the job.
- I think today if you want to choose between UI techs the aspect which
weight the most is "Which technology is that our team has the most
experience" Or if we have novice UI members which tech has the most fitting
learning curve.
(*Personal* opinion: I think Vue would be the better choice. )

I'm not a committer here, but I'd be glad to part of UI rewriting.

And I'm also supporting to have the ui code separate from the backend code.
At least outside of core.

Best regards,
Geza


Noble Paul  ezt írta (időpont: 2020. ápr. 9., Cs,
10:56):

> The advantage of hosting this outside are
>
> * You can have ui experts as committers instead of back end devs like us
> * You can iterate fast
> * Users can update to the new version of UI without reinstalling Solr or
> even restarting their nodes
> * People can even downgrade to an older version if their current version
> is buggy
> * You can even add advanced features to it w/o going through
> the bureaucracy of Solr
>
>
>
> On Thu, Apr 9, 2020, 6:40 PM Noble Paul  wrote:
>
>> @Marcus Eagan
>>
>> Is the current UI bad? totally yes.
>> Is a better UI welcome ? 100%
>> Is your proposal better ? 100%
>>
>> My only concern is adding a huge amount of code into our already
>> bloated codebase
>>
>> We have multiple options that can work
>>
>> a) We already add so many jars in our distro. Can this be added as a
>> dependency? totally?
>> b) Make it a package where , I can use a command to install it.
>>
>> To make this work, you can start it as a github project and add us as
>> collaborators (if needed). You may also add UI experts to that project
>> to get it built faster.
>> you can iterate faster too.
>>
>> think of us doing a simple command such as
>>
>> bin/solr package deploy awesome-solr-gui:0.1.1
>>
>> I think there are some missing pieces in the package system to make
>> this work. But we can plug those holes once we identify them
>>
>>
>>
>> I'm OK with any of these solution it it helps us get rid of the bad UI
>> that we have today. I can pitch in and help you in any which way you
>> want
>>
>>
>>
>> On Thu, Apr 9, 2020 at 5:30 PM Ishan Chattopadhyaya
>>  wrote:
>> >
>> > I think a UI should be a package, and I'm willing to help make it
>> possible such that package manager is capable of doing so. Also, I see no
>> reason why this UI needs to be in Solr codebase.
>> >
>> > I totally agree that Solr users need a better UI. But, I'm -1 to adding
>> that in Solr core codebase.
>> >
>> > I'm willing to consider having this UI as a first party package,
>> separate from Solr distribution.
>> >
>> > By the way, the UI looks great! I fully appreciate your efforts. I
>> think this UI will be much better placed in your GitHub account under your
>> stewardship and Solr documents/guides could add a hint on how to let Solr
>> start with your UI.
>> >
>> >
>> > On Thu, 9 Apr, 2020, 12:38 pm Marcus Eagan, 
>> wrote:
>> >>
>> >> Hey Noble,
>> >>
>> >> -1 is a definitive, so I want to clarify that you are saying you do
>> not wish to remove the EOL front end and replace it with another one in the
>> longer term?
>> >>
>> >> I hear you! As a product manager in  my day job, my primary goal is to
>> find features to cut! I spend a lot of time thinking about non-essential vs
>> used heavily vs causes more problems than it's worth. I can tell you from
>> watching the many people in the field at Lucidworks, there are a lot of
>> people who know quite a bit about Solr, but rely on the Admin UI heavily
>> because they feel comfortable there. Those people in effect help us stay
>> employed despite never contributing or being capable of contributing to
>> Solr. So hear me out. I've got a proposal:
>> >>
>> >> To start, I can work on this app as an optional package for your
>> awesome new package manager. It will be the second one I've worked on in my
>> evenings and weekends btw. The first was a package validator that I hope to
>> eventually open source, but its complexity and lack of popularity because
>> it is security ;( will likely make it the second one I open source/finish.
>> I'm also collaborating with a couple members of the Lucidworks security
>> team on that one, but I have built the basics already for them to build
>> upon.
>> >>
>> >> Back to the new UI discussion and my update that I promised.
>> >>
>> >> My update was going to be that after evaluating the projects Jan
>> posted, the most recent project that Jan listed created a pretty good base
>> to build on. After lots of auditing of the packages and a bit of
>> refactoring because the UI world moves fast, I was able to get it to
>> transpile and run again (as I'm sure it previously did) and from 

Re: Solr Admin UI Refresh 2020

[Noble Paul]

The advantage of hosting this outside are

* You can have ui experts as committers instead of back end devs like us
* You can iterate fast
* Users can update to the new version of UI without reinstalling Solr or
even restarting their nodes
* People can even downgrade to an older version if their current version is
buggy
* You can even add advanced features to it w/o going through
the bureaucracy of Solr



On Thu, Apr 9, 2020, 6:40 PM Noble Paul  wrote:

> @Marcus Eagan
>
> Is the current UI bad? totally yes.
> Is a better UI welcome ? 100%
> Is your proposal better ? 100%
>
> My only concern is adding a huge amount of code into our already
> bloated codebase
>
> We have multiple options that can work
>
> a) We already add so many jars in our distro. Can this be added as a
> dependency? totally?
> b) Make it a package where , I can use a command to install it.
>
> To make this work, you can start it as a github project and add us as
> collaborators (if needed). You may also add UI experts to that project
> to get it built faster.
> you can iterate faster too.
>
> think of us doing a simple command such as
>
> bin/solr package deploy awesome-solr-gui:0.1.1
>
> I think there are some missing pieces in the package system to make
> this work. But we can plug those holes once we identify them
>
>
>
> I'm OK with any of these solution it it helps us get rid of the bad UI
> that we have today. I can pitch in and help you in any which way you
> want
>
>
>
> On Thu, Apr 9, 2020 at 5:30 PM Ishan Chattopadhyaya
>  wrote:
> >
> > I think a UI should be a package, and I'm willing to help make it
> possible such that package manager is capable of doing so. Also, I see no
> reason why this UI needs to be in Solr codebase.
> >
> > I totally agree that Solr users need a better UI. But, I'm -1 to adding
> that in Solr core codebase.
> >
> > I'm willing to consider having this UI as a first party package,
> separate from Solr distribution.
> >
> > By the way, the UI looks great! I fully appreciate your efforts. I think
> this UI will be much better placed in your GitHub account under your
> stewardship and Solr documents/guides could add a hint on how to let Solr
> start with your UI.
> >
> >
> > On Thu, 9 Apr, 2020, 12:38 pm Marcus Eagan, 
> wrote:
> >>
> >> Hey Noble,
> >>
> >> -1 is a definitive, so I want to clarify that you are saying you do not
> wish to remove the EOL front end and replace it with another one in the
> longer term?
> >>
> >> I hear you! As a product manager in  my day job, my primary goal is to
> find features to cut! I spend a lot of time thinking about non-essential vs
> used heavily vs causes more problems than it's worth. I can tell you from
> watching the many people in the field at Lucidworks, there are a lot of
> people who know quite a bit about Solr, but rely on the Admin UI heavily
> because they feel comfortable there. Those people in effect help us stay
> employed despite never contributing or being capable of contributing to
> Solr. So hear me out. I've got a proposal:
> >>
> >> To start, I can work on this app as an optional package for your
> awesome new package manager. It will be the second one I've worked on in my
> evenings and weekends btw. The first was a package validator that I hope to
> eventually open source, but its complexity and lack of popularity because
> it is security ;( will likely make it the second one I open source/finish.
> I'm also collaborating with a couple members of the Lucidworks security
> team on that one, but I have built the basics already for them to build
> upon.
> >>
> >> Back to the new UI discussion and my update that I promised.
> >>
> >> My update was going to be that after evaluating the projects Jan
> posted, the most recent project that Jan listed created a pretty good base
> to build on. After lots of auditing of the packages and a bit of
> refactoring because the UI world moves fast, I was able to get it to
> transpile and run again (as I'm sure it previously did) and from (2290
> vulns):
> >>
> >> no npm fix doesn't magically fix, I wish it did
> >>
> >> to (2 low sev, non-productions vulns):
> >>
> >>
> >> These two issues will not affect production and really only the unit
> tests. Besides, I plan to remove them before we get to a stage even that
> matters. I've also started investigating the level of effort for me to get
> it to feature parity with the current app. The preliminary answer is not
> very much compared to other work I've done in shorter time — working with a
> jerk for a boss (years ago, don't worry Hatcher). I'm building a couple of
> the missing features as we speak. From the beginning, it will have
> infinitely more test coverage and will be a lot more approachable to
> contemporary UI developers. It will also make the Solr experience for new
> developers simpler. The major design changes that I have been thinking
> about would be to the cloud view and the query view. Both of those are
> important, the first to more 

Re: Solr Admin UI Refresh 2020

[Noble Paul]

@Marcus Eagan

Is the current UI bad? totally yes.
Is a better UI welcome ? 100%
Is your proposal better ? 100%

My only concern is adding a huge amount of code into our already
bloated codebase

We have multiple options that can work

a) We already add so many jars in our distro. Can this be added as a
dependency? totally?
b) Make it a package where , I can use a command to install it.

To make this work, you can start it as a github project and add us as
collaborators (if needed). You may also add UI experts to that project
to get it built faster.
you can iterate faster too.

think of us doing a simple command such as

bin/solr package deploy awesome-solr-gui:0.1.1

I think there are some missing pieces in the package system to make
this work. But we can plug those holes once we identify them



I'm OK with any of these solution it it helps us get rid of the bad UI
that we have today. I can pitch in and help you in any which way you
want



On Thu, Apr 9, 2020 at 5:30 PM Ishan Chattopadhyaya
 wrote:
>
> I think a UI should be a package, and I'm willing to help make it possible 
> such that package manager is capable of doing so. Also, I see no reason why 
> this UI needs to be in Solr codebase.
>
> I totally agree that Solr users need a better UI. But, I'm -1 to adding that 
> in Solr core codebase.
>
> I'm willing to consider having this UI as a first party package, separate 
> from Solr distribution.
>
> By the way, the UI looks great! I fully appreciate your efforts. I think this 
> UI will be much better placed in your GitHub account under your stewardship 
> and Solr documents/guides could add a hint on how to let Solr start with your 
> UI.
>
>
> On Thu, 9 Apr, 2020, 12:38 pm Marcus Eagan,  wrote:
>>
>> Hey Noble,
>>
>> -1 is a definitive, so I want to clarify that you are saying you do not wish 
>> to remove the EOL front end and replace it with another one in the longer 
>> term?
>>
>> I hear you! As a product manager in  my day job, my primary goal is to find 
>> features to cut! I spend a lot of time thinking about non-essential vs used 
>> heavily vs causes more problems than it's worth. I can tell you from 
>> watching the many people in the field at Lucidworks, there are a lot of 
>> people who know quite a bit about Solr, but rely on the Admin UI heavily 
>> because they feel comfortable there. Those people in effect help us stay 
>> employed despite never contributing or being capable of contributing to 
>> Solr. So hear me out. I've got a proposal:
>>
>> To start, I can work on this app as an optional package for your awesome new 
>> package manager. It will be the second one I've worked on in my evenings and 
>> weekends btw. The first was a package validator that I hope to eventually 
>> open source, but its complexity and lack of popularity because it is 
>> security ;( will likely make it the second one I open source/finish. I'm 
>> also collaborating with a couple members of the Lucidworks security team on 
>> that one, but I have built the basics already for them to build upon.
>>
>> Back to the new UI discussion and my update that I promised.
>>
>> My update was going to be that after evaluating the projects Jan posted, the 
>> most recent project that Jan listed created a pretty good base to build on. 
>> After lots of auditing of the packages and a bit of refactoring because the 
>> UI world moves fast, I was able to get it to transpile and run again (as I'm 
>> sure it previously did) and from (2290 vulns):
>>
>> no npm fix doesn't magically fix, I wish it did
>>
>> to (2 low sev, non-productions vulns):
>>
>>
>> These two issues will not affect production and really only the unit tests. 
>> Besides, I plan to remove them before we get to a stage even that matters. 
>> I've also started investigating the level of effort for me to get it to 
>> feature parity with the current app. The preliminary answer is not very much 
>> compared to other work I've done in shorter time — working with a jerk for a 
>> boss (years ago, don't worry Hatcher). I'm building a couple of the missing 
>> features as we speak. From the beginning, it will have infinitely more test 
>> coverage and will be a lot more approachable to contemporary UI developers. 
>> It will also make the Solr experience for new developers simpler. The major 
>> design changes that I have been thinking about would be to the cloud view 
>> and the query view. Both of those are important, the first to more 
>> experienced users, and the second to less advanced users though occasionally 
>> an advanced debugger or demo presenter in my experience.
>>
>> In the end Noble, this is about making Solr more approachable to new users 
>> not experts like you. The growth of Solr adoption only benefits you, so I 
>> would ask you to revisit your -1 at some point in the near future when you 
>> see the progress and breadth of improvement. We have had customers complain 
>> about the Admin UI and the community has even complained about 

Re: [VOTE] Release Lucene/Solr 8.5.1 RC1

[Alan Woodward]

+1

SUCCESS! [1:18:54.574272]

> On 8 Apr 2020, at 21:21, Nhat Nguyen  > wrote:
> 
> +1
> 
> SUCCESS! [0:52:20.920081]
> 
> 
> On Wed, Apr 8, 2020 at 6:31 AM Ignacio Vera  > wrote:
> 
> Please vote for release candidate 1 for Lucene/Solr 8.5.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
>  
> 
> 
> The vote will be open for at least 72 hours i.e. until 2020-04-15 11:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> SUCCESS! [1:02:16.691004]
> 

Re: Solr Admin UI Refresh 2020

[Noble Paul]

Solr developers are not UI experts. We are a search service and such a
service should have nice clean APIs + documentation. Is a UI useful ? yes.
The last thing we want today is another complex component in Solr codebase
that nobody understands or cannot maintain.

So, Solr UI can be hosted outside our codebase and we can have an option to
install UI from that remote repo

something like "bin/solr install-gui"

I'm -1 on anymore feature creep.

--Noble


On Thu, Apr 9, 2020 at 12:22 PM Marcus Eagan  wrote:

> Thanks again Gus.
>
> Lots of people indeed misuse REST so we could go on and on about whether
> requests are stateless or not in another thread. Let's spare the group.
>
> I think most everyone on this channel would be in agreement with you on
> separate app. I'll be opening a new ticket and a PR that will document a
> few things to make it easy for UI devs who know little to no Java how to
> get started.
>
> Ishan, there's some significant UI expertise in the team. Erickson finds
> his way to open every cookie jar. Erik Hatcher wrote the first version of
> Blacklight. I've seen Pugh do lots of work on Quepid's UI. Jan and Kevin
> have done a lot of work, and so have many others. The list goes on, and
> *likes to work on UI* is a different discussion.
>
> Beyond committers because I'm not a committer, I have UI expertise that I
> can polish off and improve for the sake of my interest and commitment to
> the community and I like to do it. I've also led UI teams. I can help to
> steward the effort overall and keep things up to date up to the point where
> I need to ask one of the committers to help me get changes merged. I'll
> probably even hire a developer to work on it once we are to that point. ;-)
>
> Expertise is not something that should block us but motivate us to expand
> this community and/or our own skillsets long term.
>
>  Thank you both and everyone else,
>
> Marcus
>
> On Wed, Apr 8, 2020, 10:21 AM Gus Heck  wrote:
>
>> While running it in an external node does ensure separability, I don't
>> think it does a good job of addressing my other point of not needing to
>> manage a 3rd server. It's still a server if it's started by java, and one
>> still has to ensure it exists, and it will be extra hard to figure out how
>> to configure it if started by Solr.
>>
>> I'm strongly in favor of us having a UI from my perspective as a
>> consultant it makes discovery of things like their startup parameters and
>> directories and such very easy (just go to front page of the admin screen),
>> and it's so much easier to get a customer with security concerns and strict
>> controls on who can access what (think banks, military, etc) to share a web
>> session where they drive the UI than to get direct access to machines.
>> It'll be a lot slower and much lower service to be making people wait while
>> I craft curl statements to paste into the web session (and then fix
>> the inevitable typos, or detect when they missed the last char of what I
>> pasted, etc...).
>>
>> I definitely against Solr spawning some other server (node or otherwise)
>> on it's own and thereby requiring additional system dependencies, or
>> creating a second process that needs to be configured and properly secured.
>> To me that's even worse than requiring the UI to run outside of Solr. We
>> have a perfectly good web container already, and furthermore there's a much
>> greater likelihood that maintainers will be facile with java/j2ee than
>> anything else (IMHO). It's great if the framework we choose uses little or
>> no JSP/Servlet and is modernized with a 100% javascript, templated etc.
>> front end, but the back end should be java/jetty because we've got lots of
>> java folks.
>>
>> If the back end matters deeply then you're not really programming to
>> MVC/REST style...
>>
>> So there's another $0.02 :) and if you're not careful I'll give you an
>> entire nickle's worth of ways people misuse/misunderstand the term REST :)
>>
>> -Gus
>>
>> On Tue, Apr 7, 2020 at 9:06 PM Marcus Eagan 
>> wrote:
>>
>>> Gus,
>>>
>>> Your $.02 are worth a lot more than $.02 USD, so thank you.
>>>
>>> By separate app, I think I mean to endorse managed by a Node.js process
>>> started by NPM. I don’t think that conflicts with what you have proposed.
>>> The NPM command should be issued by Java || or Bash but I don’t think it
>>> would add significant overhead. Also, seems like on CI and or precommit
>>> hooks front end could be sizzled in parallel without adding much overhead.
>>>
>>> As for the front end framework, the most important things to consider in
>>> my view are simplicity and maintainability. We need to do a thorough
>>> analysis on the ecosystem and issues like the size of a React project vs
>>> Angular project vs Vue project, but React and Vue certainly have the
>>> velocity and the hearts if the front end community more than Angular. React
>>> is MIT license now and for the foreseeable
>>> future thanks to the power and reach of its