Arm
Marcus Eagan
On Wed, Aug 14, 2024 at 21:17 sanjay dutt
wrote:
> Hey everyone,
>
> How does *9:00 AM PST on August 21st* sound for our next community virtual
> meetup? Let me know if that works for all, or if we need to adjust the
> time.
>
> I'll be sharing
thon 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:
> > >>>
> >
s 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
> > > get BASIC and JWT auth across all our CLI tools and not having this one
> > > orphaned “bin/post” and random checked in “post.jar” hanging out would
> > help
> > > that.
> > >
> > > I don’t think we can remove the capability to post documen
n/solr post -url
> > > > > > http://localhost:8983/gettingstarted/update
> > https://solr.apache.org/
> > > > > > -recursive 1 -delay 1
> > > > > > * Standard input (stdin): echo '{commit: {}}' | bin/solr post
> -url
> > > > > > http://localhost:8983/my_collection/update -type
> application/json
> > > -out
> > > > > > yes -d
> > > > > > * Data as string: bin/solr post -url
> > > > > http://localhost:8983/signals/update
> > > > > > -type text/csv -out yes -d $'id,value\n1,0.47'
> > > > > >
> > > > > >
> > > > > > The last two, stdin and data as a string, feel rather obscure to
> > me,
> > > > and
> > > > > > I’d like to not port them over to being supported by the bin/solr
> > > post
> > > > > tool
> > > > > > equivalent.Thoughts?
> > > > > >
> > > > > > Eric
> > > > > > ___
> > > > > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
> > > 434.466.1467
> > > > |
> > > > > > http://www.opensourceconnections.com <
> > > > > > http://www.opensourceconnections.com/> | My Free/Busy <
> > > > > > http://tinyurl.com/eric-cal>
> > > > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw
> > > > > >
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
Marcus Eagan
bin/solr post -url
> >>> http://localhost:8983/signals/update
> >>> > > > LATEST-signals.csv
> >>> > > > * Directory of files: bin/solr post -url
> >>> > > > http://localhost:8983/myfiles/update ~/Documents
> >>> > > > * Web crawl: bin/solr post -url
> >>> > > > http://localhost:8983/gettingstarted/update
> >>> https://solr.apache.org/
> >>> > > > -recursive 1 -delay 1
> >>> > > > * Standard input (stdin): echo '{commit: {}}' | bin/solr post
> -url
> >>> > > > http://localhost:8983/my_collection/update -type
> application/json
> >>> -out
> >>> > > > yes -d
> >>> > > > * Data as string: bin/solr post -url
> >>> > > http://localhost:8983/signals/update
> >>> > > > -type text/csv -out yes -d $'id,value\n1,0.47'
> >>> > > >
> >>> > > >
> >>> > > > The last two, stdin and data as a string, feel rather obscure to
> >>> me,
> >>> > and
> >>> > > > I’d like to not port them over to being supported by the bin/solr
> >>> post
> >>> > > tool
> >>> > > > equivalent.Thoughts?
> >>> > > >
> >>> > > > Eric
> >>> > > > ___
> >>> > > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
> >>> 434.466.1467
> >>> > |
> >>> > > > http://www.opensourceconnections.com <
> >>> > > > http://www.opensourceconnections.com/> | My Free/Busy <
> >>> > > > http://tinyurl.com/eric-cal>
> >>> > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
> >>> > > >
> >>> > >
> >>> >
> >>>
> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw
> >>> > > >
> >>> > > >
> >>> > > > 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.
> >>> > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
>
--
Marcus Eagan
lr-enterprise-search-server-third-edition-raw>
>
> 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.
>
> --
Marcus Eagan
om NodeJS, but
that day is obviously not today
We can use build artifacts from NPM output to deploy the static,
browser-compatible files only in production but I don't recommend that for
development.
I hope that this sheds some light.
Best,
Marcus Eagan
apache Solr Committer / Open Source Hack
t; > resource).
> > > > > > > > This
> > > > > > > > > > > > person
> > > > > > > > > > > >should be willing to offer a systems security
> > > > perspective
> > > > > on
> > > > > > > our
> > > > > > > > > > goals
> > > > > > > > > > > > and
> > > > > > > > > > > >the security functionality we provide.
> > > > > > > > > > > >2. Develop a clear statement of the security use
> > cases
> > > > we
> > > > > > > would
> > > > > > > > like
> > > > > > > > > > > to
> > > > > > > > > > > >support, and exposition of some scenarios that are
> > > > clearly
> > > > > > out
> > > > > > > > of
> > > > > > > > > > > scope.
> > > > > > > > > > > >This results in a proposal to be discussed on the
> > dev
> > > > list
> > > > > > and
> > > > > > > > users
> > > > > > > > > > > > list
> > > > > > > > > > > >and eventually voted on.
> > > > > > > > > > > >3. Identification of use cases we would like to
> > > support
> > > > > that
> > > > > > > > are not
> > > > > > > > > > > yet
> > > > > > > > > > > >supported, and publicize them to encourage these
> > > > > > > contributions.
> > > > > > > > > > > >4. Review of documentation to ensure consistency
> > with
> > > > our
> > > > > > > > current
> > > > > > > > > > > state
> > > > > > > > > > > >(security only, perhaps annually?).
> > > > > > > > > > > >5. Creation of a "security report checklist" that
> > > > security
> > > > > > > > > > researchers
> > > > > > > > > > > >can self apply before they submit reports.
> > > > > > > > > > > >6. Form letters for consistent response to reports
> > > that
> > > > > > > haven't
> > > > > > > > > > passed
> > > > > > > > > > > >the checklist.
> > > > > > > > > > > >7. Provide consistent and prompt responses to
> > possible
> > > > > > > > > > > >vulnerabilities reported to secur...@apache.org.
> > > Those
> > > > > > > > subscribed
> > > > > > > > > > to
> > > > > > > > > > > >secur...@solr.apache.org who are not in the
> working
> > > > group
> > > > > > > > should
> > > > > > > > > > > allow
> > > > > > > > > > > >the working group time to respond before
> responding
> > > > > > > themselves.
> > > > > > > > > > > >8. When asked, offer opinions on proposed new
> > > security
> > > > > > > features
> > > > > > > > > > > >regarding consistency with the goals (working
> group
> > to
> > > > > > > discuss,
> > > > > > > > > > return
> > > > > > > > > > > > with
> > > > > > > > > > > >an opinion, always publically and just as a voice
> in
> > > the
> > > > > > > > > > conversation,
> > > > > > > > > > > > not
> > > > > > > > > > > >as any sort of veto/control, decisions are still
> up
> > to
> > > > the
> > > > > > > list
> > > > > > > > of
> > > > > > > > > > > > course).
> > > > > > > > > > > >
> > > > > > > > > > > > NON-GOAL: The group is not responsible for fixing
> > > security
> > > > > bugs
> > > > > > > or
> > > > > > > > > > adding
> > > > > > > > > > > > security features. (nothing stopping them of course,
> > just
> > > > not
> > > > > > the
> > > > > > > > point
> > > > > > > > > > > of
> > > > > > > > > > > > the group, which is a goal setting and consistency
> > > oriented
> > > > > > > group)
> > > > > > > > > > > >
> > > > > > > > > > > > *Volunteer*
> > > > > > > > > > > >
> > > > > > > > > > > > And to lower the barrier to things started, I
> volunteer
> > > to
> > > > > > > > participate
> > > > > > > > > > in
> > > > > > > > > > > > this WG for at least a year, and spend up to 2h/week
> on
> > > > it. I
> > > > > > > don't
> > > > > > > > > > think
> > > > > > > > > > > > any members should be expected to dedicate more than
> > that
> > > > to
> > > > > > it,
> > > > > > > > and
> > > > > > > > > > > > probably many weeks the time required should be less.
> > > > > > > > > > > >
> > > > > > > > > > > > *Feedback*
> > > > > > > > > > > >
> > > > > > > > > > > > Of course if you think this idea can be tweaked or
> > > > improved,
> > > > > > > speak
> > > > > > > > up!
> > > > > > > > > > > The
> > > > > > > > > > > > whole reason this is mailed to the dev list is to get
> > > broad
> > > > > > > > feedback so
> > > > > > > > > > > > that we can implement the best improvements possible.
> > > > > > > > > > > >
> > > > > > > > > > > > -Gus
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > http://www.needhamsoftware.com (work)
> > > > > > > > > > http://www.the111shift.com (play)
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > -
> > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > > > > > > > For additional commands, e-mail: dev-h...@solr.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > http://www.needhamsoftware.com (work)
> > > > > > > http://www.the111shift.com (play)
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://www.needhamsoftware.com (work)
> > > > > http://www.the111shift.com (play)
> > > > >
> > > >
> > >
> > >
> > > --
> > > http://www.needhamsoftware.com (work)
> > > http://www.the111shift.com (play)
> > >
> >
>
--
Marcus Eagan
mewhat
familiar with, Eric Pugh for lots of stuff, and Jan Hoydahl for auth and
security.
Please let me know what you think.
best,
--
Marcus Eagan
Apache Solr Committer / Open Source Hacker
gt; > > >
> >> > > > > > >
> >> > > > > > > On Thu, 30 Mar 2023 at 17:01, Ishan Chattopadhyaya <
> >> > > > > > > ichattopadhy...@gmail.com> wrote:
> >> > > > > > >
> >> > > > > > >> Let's meet on 11th April, 8pm GMT (4pm Eastern Time). Seems
> >> like
> >> > > > many
> >> > > > > > would
> >> > > > > > >> be back to office by then (10th being Easter Monday). I'll
> >> send
> >> > > out
> >> > > > a
> >> > > > > > >> meeting link shortly.
> >> > > > > >
> >> > > > > > Is there a link to the info for that meeting? I don't see
> >> anything
> >> > > in
> >> > > > > > the thread. If it hasn't been set up yet, I can wait.
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Shawn
> >> > > > > >
> >> > > > > >
> >> > -
> >> > > > > > 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
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > Sincerely yours
> >> > > Mikhail Khludnev
> >> > > https://t.me/MUST_SEARCH
> >> > > A caveat: Cyrillic!
> >> > >
> >> >
> >>
> >
>
--
Marcus Eagan
Committer
On Sat, Apr 1, 2023 at 1:23 PM Jan Høydahl wrote:
> Congrats and welcome, Marcus!
>
> Jan
>
> > 1. apr. 2023 kl. 09:19 skrev Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com>:
> >
> > Hi all,
> >
> > I'm pleased to anno
ir.
> >
> > Congrats David, and thanks in advance!
> >
> > - Houston
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
> --
Marcus Eagan
l thread): Standardizing ALL
> configs to the same format. We currently have a mix of xml, json, and
> properties.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>
--
Marcus Eagan
nd) i.e. until
>> 2022-05-10 08:00 UTC.
>> >
>> > [x] +1 approve
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove (and reason why)
>> >
>> > Here is my +1
>> >
>> > SUCCESS! [0:59:56.100439]
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>>
>> --
Marcus Eagan
ttention to:
>> - New structure, links etc
>> - Test tnat tutorials, examples, commands work
>> - All new 9.0 features documented
>> - Removed features removed from guide
>>
>> PS: The "Upgrade Notes" is still work in progress.
>>
>> Jan
>>
>
--
Marcus Eagan
1 disapprove (and reason why)
>>
>> Here is my +1
>>
>> SUCCESS! [0:59:56.100439]
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>>
>>
>
> --
> Anshum Gupta
>
--
Marcus Eagan
.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Dec 17, 2021 at 5:22 PM Marcus Eagan
> wrote:
>
>> Hi,
>>
>> As a part of the Log4j madness we all have dealt with, I learned of
>>
from more pernicious and pervasive threats in today's world and
the future. Enabling the Security Manager by default in SOLR was a good
future-proofing measure for today's reality.
Thank you all for your contributions,
--
Marcus Eagan
jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%22main%20(9.0)%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> >>>
> >>>
> >>>
> >>> Please review these. I think several can be closed as unrealistic, and
> probably new ones can be added. I have started looking at HTTP1 deprecation
> in SOLR-15223.
> >>>
> >>>
> >>> Jan
> >>
> >>
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>
--
Marcus Eagan
;> I am pleased to announce that Ilan Ginzburg has accepted the Solr PMC's
>> invitation to join.
>>
>> Congratulations and welcome, Ilan!
>>
>>
--
Marcus Eagan
voluntary contributions,
--
Marcus Eagan
hoose the standard name now so that there
>> is less to change later. Can someone dig up the statistics on Solr's name
>> choice to see if there is a clear winner (e.g. >60%)? I don't have a
>> strong opinion on whatever the standard should be so long as there is a
>>
23 matches
Mail list logo
