Also +1 ... "in the same repo and alongside" is how the last migration was done IIRC. The big plus of this is as it's developed to a point of partial utility you can put a link in the old UI to try out the new UI and get feedback and make testing much easier.
One thing that might be nice if we can do it, is to make the UI more pluggable, and allow those who have no desire to test it to start solr with it fully uninstalled. (i.e because they don't want to account for its security in production) Also it would be very good if we carefully understood how we want to achieve security (including information exposure, and role based access/display) before we put it in a release. On Tue, Jul 9, 2024 at 10:40 AM Houston Putman <hous...@apache.org> wrote: > I agree with Jason on everything. > > Thank you so much for putting this much work into something with so much > baggage in the community! > > I'm a huge +1 here, and love the things I saw in your screenshots on Slack. > > - Houston > > On Mon, Jul 8, 2024 at 2:23 PM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > > > Hey Christos, > > > > Sorry for the delay responding here - lots of context to read up on! > > > > Firstly, thanks for the huge effort you've put into writing this all > > up! Quite the thorough job, and it's really helpful to enable us > > non-UI folks to follow along haha. > > > > If I understand things correctly, there's a few distinct aspects to > > your proposal: > > > > 1. New UI would live alongside the existing one (for a time) > > 2. The code for the new UI would live in the main repository. > > 3. Development would be piece-meal (i.e. not one big code-dump) > > > > Overall, this sounds like a reasonable approach to me. > > > > I think a big concern with putting code in the main repo is that it's > > pretty far from the (current) PMC's/community's wheelhouse to > > maintain. I definitely share that concern. But IMO we're already > > sortof at a "worst case" in that regard with our existing Admin UI > > code. Doing the "refresh" in the main repo gives us a forcing > > function (i.e. the review process itself) to ensure that at least a > > few community members will understand the code to at least some > > extent. That'll be a huge improvement over where we are today. > > > > Anyway, I'm a cautious '+1' based on these details at least. To quote > > a message from Jan in Slack: "I'd rather see some imperfect movement > > than a perfect plan never realized." > > > > (Here's hoping my reply will bump this to the top of folks' Inboxes, > > and get you some more feedback.) > > > > Best, > > > > Jason > > > > On Mon, Jul 1, 2024 at 12:25 PM Christos Malliaridis > > <c.malliari...@gmail.com> wrote: > > > > > > Hello everyone, > > > > > > In regards to SIP-7 > > > < > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI > > > > > > and SIP-10 > > > < > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience > > > > > > I would like to add my perspective and address the current concerns > about > > > implementing a new UI, so that we can take some actions and improve the > > > overall quality and experience of Solr Admin UI. > > > > > > There are many discussions and opinions about the UI and how to resolve > > the > > > current issues, but they all led to the topic becoming stale. In my > > > opinion, developing and introducing a new UI into the main repository > > piece > > > by piece without replacing the current UI until feature-complete could > > > > > > - address all the issues currently reported (and not), > > > - add new features, > > > - replace the EOL framework and > > > - improve the overall user experience. > > > > > > And the maintenance, which is one of the most important parts, could be > > > addressed with the right choice of framework. > > > > > > I created a detailed writeup > > > < > > > https://docs.google.com/document/d/14F1QARdkIrmKXQ4zuWUuOXduH4v_XwZ_Zrd0d2jE468/edit?usp=sharing > > > > > > for those who are interested, where I also write about the alternative > > > approaches proposed in the past and listing the pros and cons of each > one > > > individually. > > > > > > I also started to improve this part by simply designing a new UI > > > < > > > https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept > > > > > > and addressing multiple issues at once. I have already received some > > community > > > feedback > > > <https://apachesolr.slack.com/archives/C01GVPZSSK0/p1718289047297999>, > > but > > > it is far from production-ready and needs more input. I think this > could > > be > > > further refined and moved to development if there is consensus on that > as > > > the initial approach. > > > > > > What's your opinion about this approach and do you have any concerns > that > > > have not been addressed? > > > > > > Best regards, > > > Christos > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
