All official Git branches are now protected

[Jan Høydahl]

Hi devs,

For your information, we just protected branches main, branch_9x and branch_9_N 
to disallow deletion or force-push.
Also, all releases/* tags are now protected.

A nice feature also added is that referenciing SOLR-NNN in PR comments will now 
add a clickable link to JIRA.

All this was enabled by an update to .asf.yaml, see commit 
https://github.com/apache/solr/commit/0b1d6649e09220f81806fd3e4b254f629df960e7

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

Re: [DISCUSS] Standardizing sysprop naming

[Jan Høydahl]

I like the simplicity of lowercasing and changing underscore for dot, so if we 
can avoid camelCase that would be best.


I started a WIKI page for easier collaboration on this topic: 
https://cwiki.apache.org/confluence/display/SOLR/System+property+naming+structure

There I enumerated each source folder and tried to deduce some commonality and 
structure.

I also enumerated all current sysProps used in the codebase (by scanning src 
for various System.getProperty, Boolean.getBoolean, EnvUtils.getProp 
variations). That is the second table on the page. Looking at all those system 
property names we have today is depressing, they are all over the place and 157 
in number (although some are zk, hadoop or java owned and some relate to tests).

I did a small stab on mapping those old props to a new proposed name, but the 
list is looong, so good with some collaboration on this. I experience that the 
shape of the hiearchy molds as I encounter more real-life examples. And there 
are tons of decisions, e.g. wether we should force solr.security as a prefix 
for all things security or to keep the shorter solr.auth.*. Same with 
solr.search.*

It is also encouraging to see the list of existing solr.xxx keys in use that 
are already well structured (solr.jetty.keystore.password, 
solr.kerberos.keystore.password, solr.log.level etc).

Jan


> 11. jan. 2024 kl. 03:36 skrev David Smiley :
> 
> On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl  > wrote:
> 
>> Hi,
>> 
>>> Using this one as an example; what would you propose?:
>>> * solr.shardSplit.checkDiskSpace.enabled
>> 
>> The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better.
>> But say we standardized the first component layer to be one of "query",
>> "index", "collection", "schema", "cluster", "node" or whatever set of
>> top-level components make sense. Then I guess shard split would be
>> "solr.collection.shard.split.checkDiskSpace.enabled" or similar. However, I
>> find it hard to find good generic top-level categories for Solr that are
>> consise and no overlapping.
>> 
> 
> So the module can't be camel-case but checkDiskSpace can?  What about
> hyphens in a sys prop, mapped to an underscore in an env var?
> 
>> "solr.collection.shard.split.checkDiskSpace.enabled"
> 
> Not bad.
> I bet it's hard to find good generic top-level categories.Feel free to
> take a stab at this and share for review.  It doesn't need to be perfect,
> just not nausea inducing :-)
> 
> 
>>> Are you saying the camel case is a problem?
>> 
>> No necessarily. The concern was that there should be a well-defined way to
>> translate an SOLR_ENV_VAR into system property, so we don't need to touch
>> bin/solr[.cmd] every single time. And it would be hard for an algorithm to
>> know that it should translate SOLR_SHARD_SPLIT_CHECK_DISK_SPACE_ENABLED
>> env.var into the exact combination of dot separation and camelCase used
>> above. An alternative could be using a combination of underscore and dash,
>> such as "SOLR_SHARD-SPLIT_CHECK-DISK-SPACE_ENABLED", where we translate
>> underscore with dot and dash with Camelcase. We'd need to disallow dash in
>> property names then...
>> 
> 
> Alternatively simply normalize both sys props and env vars using the same
> scheme.  In theory it would allow crazy variation but if we only document
> each named toggle a certain way then it doesn't matter.

Re: All official Git branches are now protected

[Mikhail Khludnev]

Thanks Jan!

On Fri, Jan 12, 2024 at 2:30 PM Jan Høydahl  wrote:

> Hi devs,
>
> For your information, we just protected branches main, branch_9x and
> branch_9_N to disallow deletion or force-push.
> Also, all releases/* tags are now protected.
>
> A nice feature also added is that referenciing SOLR-NNN in PR comments
> will now add a clickable link to JIRA.
>
> All this was enabled by an update to .asf.yaml, see commit
> https://github.com/apache/solr/commit/0b1d6649e09220f81806fd3e4b254f629df960e7
>
> Jan
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

-- 
Sincerely yours
Mikhail Khludnev

Re: [DISCUSS] Community Virtual Meetup, January 2024

[Eric Pugh]

I’d be interested in a discussion around:

Standardizing System Property Names and Ramifications: 
https://lists.apache.org/thread/ckb3tqnjf0h66rd0mlpfblpvkrvp3wq6

Migration from JIRA to Github for issues: 
https://lists.apache.org/thread/7kg0m7528h4xox1hzf5wb26fzcl9758g

I’d love to also share some early plans for a 1 day Hackathon for various 
Search related projects at C / C North America coming up this year.



> On Jan 11, 2024, at 6:46 PM, raghavan m  wrote:
> 
> Hello everyone
> So far, 1/18 is the most voted date. I’ll announce in meetup and slack
> channels, also create a meeting notes page.
> Please reply to this thread with any agenda/ presentation that you want to
> discuss.
> 
> Thanks
> Raghavan
> 
> Sent from iPhone
> 
> 
> On Wed, Jan 10, 2024 at 10:42 PM Marcus Eagan  wrote:
> 
>> On the 18th, I'll be available to join.
>> 
>> On Wed, Jan 10, 2024 at 7:06 PM David Smiley  wrote:
>> 
>>> 18th
>>> or probably any
>>> 
>>> On Wed, Jan 10, 2024 at 12:15 AM raghavan m 
>>> wrote:
>>> 
 Hey everyone,
 Please vote for one of the following days
 
   - 1/15
   - 1/16
   - 1/17
   - 1/18
   - 1/19
   - 1/22
 
 Time: 9 am pacific time.
 Thanks
 Raghavan
 
 Sent from iPhone
 
 
 On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski 
 wrote:
 
> Awesome, thanks for volunteering Raghavan!
> 
> Anyone have thoughts on scheduling?  Absent other strong opinions,
>>> maybe
 we
> could aim for the week of Monday the 15th through Friday the 19th and
 pick
> a day/time in that range?
> 
> Best,
> 
> Jason
> 
> On Sun, Jan 7, 2024 at 1:27 AM raghavan m 
 wrote:
> 
>> Happy New Year everyone. I can volunteer for January.
>> 
>> Sent from iPhone
>> 
>> 
>> On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski <
>>> gerlowsk...@gmail.com>
>> wrote:
>> 
>>> Hey all,
>>> 
>>> After missing December, It's time once again to start thinking
>>> ahead
 to
>> our
>>> first Virtual Meetup in the New Year!  As always, there's two
>> main
>>> questions to answer in terms of planning:
>>> 
>>> 1. Any volunteers to organize?  Organizer duties are pretty light
>>> and
> are
>>> summarized here:
>>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
>>> Volunteers
>>> get some discretion in terms of picking a meeting time/day that
>>> works
> for
>>> them.  If there are no volunteers by the end of the week, I'm
>> more
 than
>>> happy to set things up for this month.
>>> 
>>> 2. When should we meet?  I've started the discussion early this
 month,
> so
>>> we've got plenty of days to choose from.  If you have any
>> opinions,
>> please
>>> discuss.
>>> 
>>> Best,
>>> 
>>> Jason
>>> 
>> 
> 
 
>>> 
>> 
>> 
>> --
>> Marcus Eagan
>> 

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

Bugfix release Lucene/Solr 8.11.3

[Houston Putman]

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.

[DISCUSS] Solr 9.5 Release

[Jason Gerlowski]

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

[Jan Høydahl]

+1 — but let 9.4.1 get out the door first..

Jan Høydahl

> 12. jan. 2024 kl. 21:56 skrev Jason Gerlowski :
> 
> 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

-
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

[David Smiley]

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
>