Re: [DISCUSS] Standardizing sysprop naming

[Jan Høydahl]

>> collection.configName
> Where is this used as a system property override?  I looked and don't see
> it.

Yea, this should not have been in the list. Removed

> "enabled" vs "disabled": can we standardize on "enabled"?

That would have been nice. I think typically .enabled is used when default is 
disabled and .disabled is used when default is enabled.

>> managed.schema.mutable
> 
> In this case (and likely others if I found one), there is no production
> code containing this string.  It is only a test config file containing
> ${managed.schema.mutable} and probably test code that sets it.  I don't
> think we should put these in the list; the list is long enough as it is.

Yep, I moved that line down to the "Test code" section of the table.
I should have filtered my regex scan on non-test code..

>> disable.configEdit. => solr.configset.edit.disabled
> We should then broaden its use to cover the configset broadly, thus block
> the schema edit API and maybe more.  Right now it only covers mutability of
> solrconfig.xml (via a JSON overlay).  I'm good with that, but it increases
> the scope.

Yes, self descriptive naming is a goal. Rather change the names in this effort 
than change the functionality.

Jan

[dev help wanted] SOLR-17074: incorrectly escaped quotes in bin/solr script

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hi Everyone,

Two issues of incorrect quoting in the bin/solr script have been identified - 
would you be interested in contributing to fix them?

Please see https://issues.apache.org/jira/browse/SOLR-17074 for details.

Thanks,
Christine

Re: [dev help wanted] SOLR-17074: incorrectly escaped quotes in bin/solr script

[David Smiley]

Nearby there's https://issues.apache.org/jira/browse/SOLR-17112 as well;
rather trivial

On Tue, Jan 16, 2024 at 6:57 AM Vincenzo D'Amore  wrote:

> Hi Christine, I can try it.
>
> On Tue, Jan 16, 2024 at 12:39 PM Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
> > Hi Everyone,
> >
> > Two issues of incorrect quoting in the bin/solr script have been
> > identified - would you be interested in contributing to fix them?
> >
> > Please see https://issues.apache.org/jira/browse/SOLR-17074 for details.
> >
> > Thanks,
> > Christine
>
>
>
> --
> Vincenzo D'Amore
>

Re: [VOTE] Release Solr 9.4.1 RC1

[Kevin Risden]

+1 (binding)

SUCCESS! [0:33:05.648738]

Kevin Risden


On Sat, Jan 13, 2024 at 3:34 PM Jan Høydahl  wrote:

> +1 (binding)
>
> SUCCESS! [0:42:51.792486]
>
> Also built docker container and spun up the server locally.
>
>
> PS: Need to remove extra newline between the two lines of command when
> copy/pasting:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
>
> Jan
>
> > 13. jan. 2024 kl. 17:14 skrev David Smiley :
> >
> > Please vote for release candidate 1 for Solr 9.4.1
> >
> > The artifacts can be downloaded from:
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
> >
> >
> > 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.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
> >
> >
> > 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.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476/solr
> > && \
> >
> >  docker build
> $SOLR_DOWNLOAD_SERVER/9.4.1/docker/Dockerfile.official-full \
> >
> >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> >
> >-t solr-rc:9.4.1-1 && \
> >
> >  docker build
> $SOLR_DOWNLOAD_SERVER/9.4.1/docker/Dockerfile.official-slim \
> >
> >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> >
> >-t solr-rc:9.4.1-1-slim
> >
> >
> > The vote will be open for at least 72 hours i.e. until 2024-01-16 17:00
> UTC.
> >
> >
> > [ ] +1  approve
> >
> > [ ] +0  no opinion
> >
> > [ ] -1  disapprove (and reason why)
> >
> >
> > Here is my +1
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

Re: [DISCUSS] Solr 9.5 Release

[Jason Gerlowski]

> but let 9.4.1 get out the door first..

I'm happy to wait if that's the consensus, but is there a reason one
release needs to block another?

I could be blanking, but I don't think there's any technical conflict in
terms of where artifacts are staged, etc. is there?

> getting through some one-time pains of key/GPG matters

Definitely the worst bit in my recent experience; good luck!

Best,

Jason

On Fri, Jan 12, 2024 at 11:08 PM David Smiley  wrote:

> Yeah I'm doing the 9.4.1 for real now... getting through some one-time
> pains of key/GPG matters.
>
> https://issues.apache.org/jira/browse/SOLR-17096 solr.xml support for
>  plugins is pretty close!
>
> On Fri, Jan 12, 2024 at 3:56 PM Jason Gerlowski 
> wrote:
>
> > Hey all,
> >
> > branch_9x has accumulated 3 new features, 19 improvements, 2
> optimizations,
> > 11 bug fixes, and 7 "other changes" - I'd love to get these in front of
> > users with a Solr 9.5.0 release.
> >
> > I'm happy to volunteer as RM, and propose that we target next Thursday
> > January 18th to cut the branch and prepare the first RC.
> >
> > Best,
> >
> > Jason
> >
>

Re: [dev help wanted] SOLR-17074: incorrectly escaped quotes in bin/solr script

[Vincenzo D'Amore]

Hi Christine, I can try it.

On Tue, Jan 16, 2024 at 12:39 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Hi Everyone,
>
> Two issues of incorrect quoting in the bin/solr script have been
> identified - would you be interested in contributing to fix them?
>
> Please see https://issues.apache.org/jira/browse/SOLR-17074 for details.
>
> Thanks,
> Christine



-- 
Vincenzo D'Amore

Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions

[Jason Gerlowski]

Still thinking through Jan's question; haven't made up my mind on a
preference (A, B, C, D, etc.) yet.  But had a few questions/reactions,
inline.

> My arguments for this approach: 1) Solr has 16993 JIRA issues!
> 2) There are 4030 OPEN issues, of which 3681 has not been
> touched for a year! Why would we want 3681 OPEN & stale GitHub
> issues? Instead I'd like to use StaleBot to tag stale issues+PRs and
> auto close+tag if still stale for N days. This is a much-used, proven
> approach.

To ask what might be a naive question: what's the problem with having many
"open but stale" issues, and what does auto-closing things get us?  I know
it's commonly done, but I've never quite understood why.  Folks looking to
filter by "active" issues can use the "updated" field that both JIRA and
Github provide, so presumably there must be some other benefit?

> But if I have a PR (or at least a draft) ready, to me
> creating the Github issue is a redundant (and annoying)
> copy and paste.  Also, I am then confused about where
> to discuss and comments (the issue or the PR?).

I think this was implicit in Alessandro's message, but to add my 2c more
explicitly: I think this can be true regardless of the system for recording
PRs or Issues.  The duplication is a bit more obvious when both are in
Github, but it's going to be there in any setup (including our current one)
where issue-reports and code-contributions are separate things.

Best,

Jason

On Wed, Jan 10, 2024 at 5:44 AM Alessandro Benedetti 
wrote:

> Another thing that always bugged me with the Lucene approach is the dualism
> issue/PR.
>
> If I don't have a solution for an issue, it makes complete sense to write
> the Github Issue and later on a Pull Request may or may not happen.
>
> But if I have a PR (or at least a draft) ready, to me creating the Github
> issue is a redundant (and annoying) copy and paste.
> Also, I am then confused about where to discuss and comments (the issue or
> the PR?).
> Effectively nowadays Github PRs have plenty of description, discussion and
> review capabilities so in case it's a bug-fix or a well-established code
> direction, does it make sense to have the associated issue?
>
> I understand that ideally, you would like to have an issue first, discuss
> it with other committers and then start the implementation, but being
> honest I realised over the years that this makes contributing a full-time
> job and most of us(who are not lucky enough to be paid to contribute) can't
> (and shouldn't) commit to that.
> So to me, it happens all the time I go deep with a bug fix or new feature,
> open the PR and then open the Jira issue.
>
> Could we possibly go with Solr in a direction where there's always at least
> one PR for an issue, but not necessarily an issue for a PR?
> Just food for thought based on my experience,
> 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 
> LinkedIn  | Twitter
>  | Youtube
>  | Github
> 
>
>
> On Wed, 10 Jan 2024 at 10:26, Alessandro Benedetti 
> wrote:
>
> > Hi all,
> > thanks for raising this!
> >
> > I am in favour of:
> > B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history
> >
> > But rather than just OPEN, I would probably migrate only the active ones?
> >
> > I agree it doesn't make sense to duplicate thousands of Jiras.
> >
> > I would also be ok with C, mine is just a preference not a veto at all.
> > 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 
> > LinkedIn  | Twitter
> >  | Youtube
> >  | Github
> > 
> >
> >
> > On Mon, 8 Jan 2024 at 23:57, Jan Høydahl  wrote:
> >
> >> Bringing attention to this thread again.
> >>
> >> Now that Lucene has some experience after the migration and with using
> >> Issues, labels etc, I'd like to discuss whether we'd want to copy the
> >> Lucene approach or do something different.
> >>
> >> I'm not frequenting the Lucene issue tracker much, and am not either
> >> aware of a formal evaluation of their issue migration. So appreciate
> >> feedback from committers who have more exposure from Lucene.
> >>
> >> In my mind, we, Solr, have four options
> >> A) Migrate everything, like Lucene did
> >> B) Migrate only OPEN JIRA i

Re: [DISCUSS] Solr 9.5 Release

[Ishan Chattopadhyaya]

Is there an urgent need for this release?
I saw that Houston took over the 8.11.3 release process from me without any
prior intimation. Is Apple asking both of you to hurry up?

On Tue, 16 Jan 2024 at 20:35, Jason Gerlowski  wrote:

> > but let 9.4.1 get out the door first..
>
> I'm happy to wait if that's the consensus, but is there a reason one
> release needs to block another?
>
> I could be blanking, but I don't think there's any technical conflict in
> terms of where artifacts are staged, etc. is there?
>
> > getting through some one-time pains of key/GPG matters
>
> Definitely the worst bit in my recent experience; good luck!
>
> Best,
>
> Jason
>
> On Fri, Jan 12, 2024 at 11:08 PM David Smiley  wrote:
>
> > Yeah I'm doing the 9.4.1 for real now... getting through some one-time
> > pains of key/GPG matters.
> >
> > https://issues.apache.org/jira/browse/SOLR-17096 solr.xml support for
> >  plugins is pretty close!
> >
> > On Fri, Jan 12, 2024 at 3:56 PM Jason Gerlowski 
> > wrote:
> >
> > > Hey all,
> > >
> > > branch_9x has accumulated 3 new features, 19 improvements, 2
> > optimizations,
> > > 11 bug fixes, and 7 "other changes" - I'd love to get these in front of
> > > users with a Solr 9.5.0 release.
> > >
> > > I'm happy to volunteer as RM, and propose that we target next Thursday
> > > January 18th to cut the branch and prepare the first RC.
> > >
> > > Best,
> > >
> > > Jason
> > >
> >
>

Re: [DISCUSS] Solr 9.5 Release

[Houston Putman]

Apple isn't urging anything, and you really can assume that's true across
the board for our decisions.

There are other concerns that are urging quick releases (See other mailing
lists for more information).

I'm happy to let you continue the 8.11.3 release, and if you want to wait
for 9.4.1 that is fine with me. But we do need to get it out quickly.

- Houston

On Tue, Jan 16, 2024 at 12:45 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Is there an urgent need for this release?
> I saw that Houston took over the 8.11.3 release process from me without any
> prior intimation. Is Apple asking both of you to hurry up?
>
> On Tue, 16 Jan 2024 at 20:35, Jason Gerlowski 
> wrote:
>
> > > but let 9.4.1 get out the door first..
> >
> > I'm happy to wait if that's the consensus, but is there a reason one
> > release needs to block another?
> >
> > I could be blanking, but I don't think there's any technical conflict in
> > terms of where artifacts are staged, etc. is there?
> >
> > > getting through some one-time pains of key/GPG matters
> >
> > Definitely the worst bit in my recent experience; good luck!
> >
> > Best,
> >
> > Jason
> >
> > On Fri, Jan 12, 2024 at 11:08 PM David Smiley 
> wrote:
> >
> > > Yeah I'm doing the 9.4.1 for real now... getting through some one-time
> > > pains of key/GPG matters.
> > >
> > > https://issues.apache.org/jira/browse/SOLR-17096 solr.xml support for
> > >  plugins is pretty close!
> > >
> > > On Fri, Jan 12, 2024 at 3:56 PM Jason Gerlowski  >
> > > wrote:
> > >
> > > > Hey all,
> > > >
> > > > branch_9x has accumulated 3 new features, 19 improvements, 2
> > > optimizations,
> > > > 11 bug fixes, and 7 "other changes" - I'd love to get these in front
> of
> > > > users with a Solr 9.5.0 release.
> > > >
> > > > I'm happy to volunteer as RM, and propose that we target next
> Thursday
> > > > January 18th to cut the branch and prepare the first RC.
> > > >
> > > > Best,
> > > >
> > > > Jason
> > > >
> > >
> >
>

Re: Bugfix release Lucene/Solr 8.11.3

[Houston Putman]

Since the 9.4.1 release candidate is out, I'm fine waiting for it to
finish. But let's try to get 8.11.3 out very soon afterwards.

Also, as I stated on the other thread, didn't mean to tread on your toes
here. If you want to continue with the release, please do!

- Houston

On Sat, Jan 13, 2024 at 8:59 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Shouldn't we wait for the 9.4.1 to go out first? That's what I was holding
> out on.
>
> On Sat, 13 Jan, 2024, 12:43 am Houston Putman,  wrote:
>
> > NOTICE:
> >
> > I am now preparing for a bugfix release from branch branch_8_11
> >
> > Please observe the normal rules for committing to this branch:
> >
> > * Before committing to the branch, reply to this thread and argue
> >   why the fix needs backporting and how long it will take.
> > * All issues accepted for backporting should be marked with 8.11.3
> >   in JIRA, and issues that should delay the release must be marked as
> > Blocker
> > * All patches that are intended for the branch should first be committed
> >   to the unstable branch, merged into the stable branch, and then into
> >   the current release branch.
> > * Only Jira issues with Fix version 8.11.3 and priority "Blocker" will
> > delay
> >   a release candidate build.
> >
>

Re: [DISCUSS] Solr 9.5 Release

[Jason Gerlowski]

> Is there an urgent need for this release?

Have I seemed "urgent"?  I suggested a mid-January 9.5 back on 12/6 (see
the "9.4.1 release" thread).  If anything I've been slow :-p

Like I said in my initial message here - my motivation around 9.5 is just
that I think there's some cool stuff lined up and I'd love to get that out
to folks.  Getting features out is a "Good Thing", so why wait on 9.5 if
there's not a particular reason to?  If there is a concrete reason to wait,
that's fine too; I'm just curious to learn more about it.

Best,

Jason



On Tue, Jan 16, 2024 at 1:50 PM Houston Putman  wrote:

> Apple isn't urging anything, and you really can assume that's true across
> the board for our decisions.
>
> There are other concerns that are urging quick releases (See other mailing
> lists for more information).
>
> I'm happy to let you continue the 8.11.3 release, and if you want to wait
> for 9.4.1 that is fine with me. But we do need to get it out quickly.
>
> - Houston
>
> On Tue, Jan 16, 2024 at 12:45 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
> > Is there an urgent need for this release?
> > I saw that Houston took over the 8.11.3 release process from me without
> any
> > prior intimation. Is Apple asking both of you to hurry up?
> >
> > On Tue, 16 Jan 2024 at 20:35, Jason Gerlowski 
> > wrote:
> >
> > > > but let 9.4.1 get out the door first..
> > >
> > > I'm happy to wait if that's the consensus, but is there a reason one
> > > release needs to block another?
> > >
> > > I could be blanking, but I don't think there's any technical conflict
> in
> > > terms of where artifacts are staged, etc. is there?
> > >
> > > > getting through some one-time pains of key/GPG matters
> > >
> > > Definitely the worst bit in my recent experience; good luck!
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Fri, Jan 12, 2024 at 11:08 PM David Smiley 
> > wrote:
> > >
> > > > Yeah I'm doing the 9.4.1 for real now... getting through some
> one-time
> > > > pains of key/GPG matters.
> > > >
> > > > https://issues.apache.org/jira/browse/SOLR-17096 solr.xml support
> for
> > > >  plugins is pretty close!
> > > >
> > > > On Fri, Jan 12, 2024 at 3:56 PM Jason Gerlowski <
> gerlowsk...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > branch_9x has accumulated 3 new features, 19 improvements, 2
> > > > optimizations,
> > > > > 11 bug fixes, and 7 "other changes" - I'd love to get these in
> front
> > of
> > > > > users with a Solr 9.5.0 release.
> > > > >
> > > > > I'm happy to volunteer as RM, and propose that we target next
> > Thursday
> > > > > January 18th to cut the branch and prepare the first RC.
> > > > >
> > > > > Best,
> > > > >
> > > > > Jason
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Solr 9.4.1 RC1

[Houston Putman]

+1 (binding)

SUCCESS! [0:51:47.471576]

I also successfully built both Docker images and ran the Solr Operator
integration tests with the full image:

Will run 23 of 23 specs
Running in parallel across 3 processes
•••

Ran 23 of 23 Specs in 433.438 seconds
SUCCESS! -- 23 Passed | 0 Failed | 0 Pending | 0 Skipped

- Houston

On Tue, Jan 16, 2024 at 8:28 AM Kevin Risden  wrote:

> +1 (binding)
>
> SUCCESS! [0:33:05.648738]
>
> Kevin Risden
>
>
> On Sat, Jan 13, 2024 at 3:34 PM Jan Høydahl  wrote:
>
> > +1 (binding)
> >
> > SUCCESS! [0:42:51.792486]
> >
> > Also built docker container and spun up the server locally.
> >
> >
> > PS: Need to remove extra newline between the two lines of command when
> > copy/pasting:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
> >
> > Jan
> >
> > > 13. jan. 2024 kl. 17:14 skrev David Smiley :
> > >
> > > Please vote for release candidate 1 for Solr 9.4.1
> > >
> > > The artifacts can be downloaded from:
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
> > >
> > >
> > > 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.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
> > >
> > >
> > > 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.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476/solr
> > > && \
> > >
> > >  docker build
> > $SOLR_DOWNLOAD_SERVER/9.4.1/docker/Dockerfile.official-full \
> > >
> > >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> > >
> > >-t solr-rc:9.4.1-1 && \
> > >
> > >  docker build
> > $SOLR_DOWNLOAD_SERVER/9.4.1/docker/Dockerfile.official-slim \
> > >
> > >--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> > >
> > >-t solr-rc:9.4.1-1-slim
> > >
> > >
> > > The vote will be open for at least 72 hours i.e. until 2024-01-16 17:00
> > UTC.
> > >
> > >
> > > [ ] +1  approve
> > >
> > > [ ] +0  no opinion
> > >
> > > [ ] -1  disapprove (and reason why)
> > >
> > >
> > > Here is my +1
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
> >
>