Re: [VOTE] Release Solr 9.4.0 RC1

[Jason Gerlowski]

+1 (binding)

SUCCESS! [0:37:15.582660]

On Sun, Oct 8, 2023 at 1:57 PM Jan Høydahl  wrote:
>
> Note that a vote running over a weekend is normally extended with a day or 
> two. I plan to test the RC on Monday.
>
> Jan Høydahl
>
> > 5. okt. 2023 kl. 21:53 skrev Alex Deparvu :
> >
> > Please vote for release candidate 1 for Solr 9.4.0
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> >
> > You can build a release-candidate of the official docker images (full &
> > slim) using the following command:
> >
> > SOLR_DOWNLOAD_SERVER=
> > https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b/solr
> > && \
> >  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-full \
> >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> >-t solr-rc:9.4.0-1 && \
> >  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-slim \
> >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> >-t solr-rc:9.4.0-1-slim
> >
> > The vote will be open for at least 72 hours i.e. until 2023-10-08 20:00 UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1 (which I am not completely sure, but I think it is
> > non-binding)
> >
> > best,
> > alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>

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

Re: [VOTE] Release Solr 9.4.0 RC1

[Kevin Risden]

+1 (binding)

SUCCESS! [0:33:39.381293]

Kevin Risden


On Mon, Oct 9, 2023 at 6:26 AM Jason Gerlowski 
wrote:

> +1 (binding)
>
> SUCCESS! [0:37:15.582660]
>
> On Sun, Oct 8, 2023 at 1:57 PM Jan Høydahl  wrote:
> >
> > Note that a vote running over a weekend is normally extended with a day
> or two. I plan to test the RC on Monday.
> >
> > Jan Høydahl
> >
> > > 5. okt. 2023 kl. 21:53 skrev Alex Deparvu :
> > >
> > > Please vote for release candidate 1 for Solr 9.4.0
> > >
> > > The artifacts can be downloaded from:
> > >
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> > >
> > > You can run the smoke tester directly with this command:
> > >
> > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > >
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> > >
> > > You can build a release-candidate of the official docker images (full &
> > > slim) using the following command:
> > >
> > > SOLR_DOWNLOAD_SERVER=
> > >
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b/solr
> > > && \
> > >  docker build
> $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-full \
> > >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> > >-t solr-rc:9.4.0-1 && \
> > >  docker build
> $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-slim \
> > >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> > >-t solr-rc:9.4.0-1-slim
> > >
> > > The vote will be open for at least 72 hours i.e. until 2023-10-08
> 20:00 UTC.
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > > Here is my +1 (which I am not completely sure, but I think it is
> > > non-binding)
> > >
> > > best,
> > > alex
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

Re: Apache Solr Newsletter proposal September 2023

[Eric Pugh]

I’d love to see it on mastodon/twitterX/linkedin too….   I bet ASF PR would 
love to see this as well ;-)

> On Oct 8, 2023, at 5:36 PM, Alessandro Benedetti  wrote:
> 
> +1 I think it's a wonderful idea!
> 
> On Sun, 8 Oct 2023, 17:26 Arrieta, Alejandro, 
> wrote:
> 
>> 0. Intro
>> Welcome to the Apache Solr Newsletter proposal September 2023. As this is
>> the first newsletter proposal of 2023 we include Solr Community news
>> starting from January 2023:
>> 
>> Welcome Alex Deparvu as Solr committer:
>> https://lists.apache.org/thread/fx4o3y55ypqy1n06kdbq5k8h4pjxlowj
>> 
>> Welcome Marcus Eagan as Solr committer:
>> https://lists.apache.org/thread/2p2fjm18g39x2mknxqnbr3gfcx0q6rrx
>> 
>> Welcome David Smiley as Solr's new PMC chair:
>> https://lists.apache.org/thread/yrp2yll52r0fm2pbhw17b62oln63fp33
>> 
>> Welcome Andy Webb as Solr committer:
>> https://lists.apache.org/thread/k449v7jl4bwg6f7x707tvw5ch2dk8h3f
>> 
>> Welcome Justin Sweeney as Solr committer:
>> https://lists.apache.org/thread/g588106pohdwok7gpwwcsxpgvwxwwh41
>> 
>> Welcome Colvin Cowie as Solr committer:
>> https://lists.apache.org/thread/ngzjs0b3mb201d2shfvzdysdd5g6xqz1
>> 
>> 1. Current versions
>> Solr 9.3.0:
>> https://solr.apache.org/downloads.html#solr-930
>> 
>> Solr 8.11.2:
>> https://solr.apache.org/downloads.html#solr-8112
>> 
>> Solr Operator v0.7.1:
>> https://solr.apache.org/operator/artifacts.html#solr-v071
>> 
>> 2. Incoming versions
>> Solr 9.4.0
>> mailing list thread:
>> https://lists.apache.org/thread/j44golmqp4sjf2rk74pqktkrsc1do58r
>> 
>> Solr 8.11.3
>> mailing list thread:
>> https://lists.apache.org/thread/j44golmqp4sjf2rk74pqktkrsc1do58r
>> 
>> 3. Solr Improvement Proposals News
>> SIP-13: Cross Data Center Replication
>> mailing list thread:
>> https://lists.apache.org/thread/9y2qd7rs45049xbrt0gty40m4b5cv22y
>> wiki link:
>> 
>> https://cwiki.apache.org/confluence/display/SOLR/SIP-13%3A+Cross+Data+Center+Replication
>> 
>> SIP-14 Embedded Zookeeper
>> mailing list thread:
>> https://lists.apache.org/thread/mch6y4wsbqykcmfy4r76movmx1wz0375
>> wiki link:
>> https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper
>> 
>> SIP-15 Node roles
>> mailing list thread:
>> https://lists.apache.org/thread/kwq609jxckpdqk54fvghxs66jtk92kof
>> wiki link:
>> https://cwiki.apache.org/confluence/display/SOLR/SIP-15+Node+roles
>> 
>> SIP-19 Adopt JSR-330 dependency injection
>> mailing list thread:
>> https://lists.apache.org/thread/9y2qd7rs45049xbrt0gty40m4b5cv22y
>> wiki link:
>> 
>> https://cwiki.apache.org/confluence/display/SOLR/SIP-19+Adopt+JSR-330+dependency+injection
>> 
>> 4. Links to blogs, videos, others related to Solr:
>> Apache Solr Community Virtual Meetup, September 2023:
>> 
>> https://www.meetup.com/apache-solr-virtual-community-meetups/events/296344421/
>> 
>> DataImportHandler 9.3.0 released:
>> https://lists.apache.org/thread/8z65tf4jr2ppdm4xo5r1bygjzt8z8r3f
>> 
>> 5. Upcoming Events & meetings
>> ASF Community over Code in Halifax, October 7-10 2023:
>> https://communityovercode.org/
>> 
>> Apache Solr Community Virtual Meetup, October 2023:
>> https://www.meetup.com/apache-solr-virtual-community-meetups/events/
>> 
>> 6. Connect with the Apache Solr Community
>> Subscribe to Apache Solr Virtual Meetup for monthly meeting:
>> https://www.meetup.com/apache-solr-virtual-community-meetups/
>> 
>> Follow us on Twitter/X:
>> https://twitter.com/apachesolr
>> 
>> Visit our mailing list, jira, irc and slack:
>> https://solr.apache.org/community.html
>> 
>> How to contribute:
>> https://solr.apache.org/community.html#how-to-contribute
>> 
>> Apache Solr website:
>> https://solr.apache.org/
>> 
>> Apache Solr Operator website:
>> https://solr.apache.org/operator/
>> 
>> Note: This is a proposal and I will start working on the October 2023
>> newsletter proposal and create a Jira to accept contributions. Maybe we can
>> publish this on the Apache Solr web if accepted in the future.
>> 
>> Kind Regards,
>> Alejandro Arrieta
>> 

___
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: Back-compat for backup/restore

[Houston Putman]

I think this is an edge case that we can document in the upgrade notes.
Saying "If you plan on doing restores during a minor version upgrade,
please upgrade to this version before moving to a more recent version of
9.x". Restores are fairly infrequent, and it'd be sad to defer the benefit
all the way to 10.

Though we would need a minor version that didn't include the RestoreCmd
changes, so there would be an intermediary version for users to use.

In situations like this, it'd be nice if inter-node Solr communication
> passed version numbers back & forth.
>

That would be very very nice.

- Houston

On Mon, Oct 2, 2023 at 8:04 PM David Smiley 
wrote:

> https://issues.apache.org/jira/browse/SOLR-16924
>
> There is a small improvement planned for Collection restore (from backup)
> internal sequencing, and I have a question for the group on backwards
> compatibility.  The RestoreCmd will no longer need to send a
> REQUESTAPPLYUPDATES command to each core following RESTORECORE because
> RESTORECORE will now finish fully active.
>
> If we ship this as-is then there could be an issue during a live
> upgrade-in-place.  RestoreCmd might be running the latest release but
> another node (where a core is being restored) might be older and thus the
> state of the UpdateLog inside the restored core might not be active.  The
> restoration will complete seemingly successfully yet indexing won't work.
> The user should just try the restore again (after the upgrade).  Hopefully
> the user would be more alert to problems, having just did an in-place
> upgrade.
>
> I suppose to mitigate this risk, we could defer the ideal benefit to Solr
> 10 -- deferring the RestoreCmd change until then.  But now (9.x) enhance
> RESTORECORE to flip the UpdateLog state itself.  Does this sound fine?  Or
> over-careful?
>
> In situations like this, it'd be nice if inter-node Solr communication
> passed version numbers back & forth.
>
> ~ David
>

Re: Back-compat for backup/restore

[David Smiley]

Makes sense.  I added a generic note:

Certain commands, like a restore of a collection, might not complete
properly if performed *during* an upgrade.
They may need to be re-attempted after.


~ David


On Mon, Oct 9, 2023 at 5:57 PM Houston Putman  wrote:

> I think this is an edge case that we can document in the upgrade notes.
> Saying "If you plan on doing restores during a minor version upgrade,
> please upgrade to this version before moving to a more recent version of
> 9.x". Restores are fairly infrequent, and it'd be sad to defer the benefit
> all the way to 10.
>
> Though we would need a minor version that didn't include the RestoreCmd
> changes, so there would be an intermediary version for users to use.
>
> In situations like this, it'd be nice if inter-node Solr communication
> > passed version numbers back & forth.
> >
>
> That would be very very nice.
>
> - Houston
>
> On Mon, Oct 2, 2023 at 8:04 PM David Smiley 
> wrote:
>
> > https://issues.apache.org/jira/browse/SOLR-16924
> >
> > There is a small improvement planned for Collection restore (from backup)
> > internal sequencing, and I have a question for the group on backwards
> > compatibility.  The RestoreCmd will no longer need to send a
> > REQUESTAPPLYUPDATES command to each core following RESTORECORE because
> > RESTORECORE will now finish fully active.
> >
> > If we ship this as-is then there could be an issue during a live
> > upgrade-in-place.  RestoreCmd might be running the latest release but
> > another node (where a core is being restored) might be older and thus the
> > state of the UpdateLog inside the restored core might not be active.  The
> > restoration will complete seemingly successfully yet indexing won't work.
> > The user should just try the restore again (after the upgrade).
> Hopefully
> > the user would be more alert to problems, having just did an in-place
> > upgrade.
> >
> > I suppose to mitigate this risk, we could defer the ideal benefit to Solr
> > 10 -- deferring the RestoreCmd change until then.  But now (9.x) enhance
> > RESTORECORE to flip the UpdateLog state itself.  Does this sound fine?
> Or
> > over-careful?
> >
> > In situations like this, it'd be nice if inter-node Solr communication
> > passed version numbers back & forth.
> >
> > ~ David
> >
>

Re: Apache Projects and Discussion Forums

[David Smiley]

At the ASF Community-over-Code conference today, I brought up this topic
with ASF Directors and members at a session about project communication.
Yes, a project could host something if a project (PMC) wants to, provided
that the "dev list" remains where official project decisions are made.
Also, there was advice against over-use of Slack for many reasons.  I feel
if we had a modern forum in place, we would not have been so tempted to
setup Slack for users.

My main concern for *adding* a forum is fragmentation for users/everyone
with us...@solr.apache.org.  I would much prefer bidirectional integration
(i.e. a bridge or gateway) so that a user can choose the
UX/interaction-model they prefer.  I don't want to cut the user community
into silos that don't talk to each other.  I looked at Discourse
https://meta.discourse.org and tried to find if it's possible to
bridge/gateway to existing mailing lists.  I didn't see it but hopefully it
exists?  If not / in addition, the Solr user list can be imported into
Discourse, but that's a one-time thing intended to transition in full.
FWIW I support a complete transition to avoid fragmentation.

BTW fragmentation is already the case via stack-overflow today.  Granted I
don't think there's been much traction there for Solr (yes some, but not
much).  I heard some projects out there completely embrace stack-overflow
and perhaps don't have a user list or similar.  A bold move but I get
the appeal.  It's so radical to my norms that I'm hesitant to suggest it
for us but I can't think of a good reason I'd oppose it.  Maybe some of you
have opinions to share on that?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Thu, May 18, 2023 at 2:53 PM David Mackey  wrote:

> Hi Everyone,
>
> I apologize for the delay in responding, I wanted to give some time for
> others to share their thoughts and due to the mention of a dedicated
> solr.apache.org URL (I wanted to verify if this was something Discourse
> offered in their free plan for open source projects, unfortunately it is
> not).
>
> I appreciate Alessandro's generous offer of hosting the forums on the
> ir-relevant.net site however I'd lean towards having its forums fully
> owned
> by Apache/Solr. I am approaching this primarily from a visibility/marketing
> perspective and I think having dedicated, official forums would be more
> "impressive" to those considering Elastic ,
> OpenSearch , Solr, etc.
>
> I would love to see the forums hosted on the official Solr domain as Ishan
> suggested. The Apache TVM project's discussion URL is
> https://discuss.tvm.apache.org/, so Solr could potentially have one like:
> https://discuss.solr.apache.org/
>
> I'd recommend using Discourse  as the forum
> software (it is what both Elastic and OpenSearch appear to be using). A
> free
> instance  is available from Discourse for
> open source projects. By default this instance would be hosted at
> solr.discourse.group and unfortunately the free plan does not support
> custom domains (though we could do a redirect from
> https://discuss.solr.apache.org/ or similar the final url would still be
> solr.discourse.group).
>
> If Solr exceeds the 50k/views/mo. (sustained traffic, not occasional
> spikes) the free plan offers we'd need to upgrade to the Standard Plan
> which is available at a 50% discount for nonprofits (regular price:
> $100/mo.; discounted price: $50/mo.). Alternatively we could using a VPS
> host with a ~$20/mo. instance. In any case, I wouldn't anticipate us
> exceeding the free plans capabilities for quite some time.
>
> I'd suggest having two categories to start - End Users
> (businesses/individuals who utilize the application) and Development (for
> more code related topics). Two additional possible categories would be
> Beginners, and Third-Party Integrations / Plugins but I'd suggest adding
> these later after the forums gain some traction.
>
> I'd love to get something out there sooner than later and am happy to get
> the instance setup and configured with Discourse if folks are amenable and
> that would be helpful. I'd suggest using the free plan to start to expedite
> the spin-up process.
>
> Sincerely,
>
> Dave Mackey
>
> On Tue, May 16, 2023 at 11:04 AM Alessandro Benedetti <
> a.benede...@sease.io>
> wrote:
>
> > I agree Ishan,
> > just wanted to mention what I can donate from my company anyway.
> > Happy to allow a customized logo and colors for the Solr section and
> allow
> > a redirect from solr.apache.org/discussions it that's something useful.
> > Cheers
> > --
> > *Alessandro Benedetti*
> > Director @ Sease Ltd.
> > *Apache Lucene/Solr Committer*
> > *Apache Solr PMC Member*
> >
> > e-mail: a.benede...@sease.io
> >
> >
> > *Sease* - Information Retrieval Applied
> > Consulting | Training | Open Source
> >
> > Website: Sease.io