Welcome Tomoko and congratulations!
On Tue, Apr 9, 2019 at 6:34 AM jim ferenczi wrote:
>
> Welcome Tomoko!
>
> Le mar. 9 avr. 2019 à 12:19, Ishan Chattopadhyaya
> a écrit :
>>
>> Yokoso, Tomoko-san! Congratulations..
>>
>> On Tue, Apr 9, 2019 at 2:28 PM Christine Poerschke (BLOOMBERG/ LONDON)
>
Hey Adrien,
A pretty bad bug in Solr backups came in last week or so: SOLR-15706.
If it's not too late I'd like to try to get it into 8.11. Would that
be ok?
I'm just digging into things now so I don't have a complete
understanding yet, but I'm optimistic it won't long delay your
timeline for cu
+1 (PMC)
I understand concerns about handing governance over to a 3rd party, but
letting that drive our decision-making here feels like optimizing for a
rare case that might never occur. I'd m,uch rather optimize for making
things easiest for contributors, and then accommodate any "Github ToS ban
+1
SUCCESS! [1:03:16.496710]
Also did some manual testing - mostly of backup/restore (GCS and S3)
On Thu, Jun 16, 2022 at 12:58 PM Houston Putman wrote:
>
> +1 (binding)
>
> SUCCESS! [1:10:19.762602]
>
> - Houston
>
> On Wed, Jun 15, 2022 at 10:04 PM Anshum Gupta wrote:
>>
>> Thanks for report
Here's my +1 (binding)
SUCCESS! [0:56:16.591754]
On Mon, Feb 5, 2024 at 5:23 PM Houston Putman wrote:
> Please vote for release candidate 1 for Lucene/Solr 8.11.3
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-revbaa7c80af4278c
Hey all,
Sending this email to discuss the ASF Jenkins' 'lucene-solr-1' worker
node, which both Lucene and Solr use to run builds.
While investigating a recent issue with some Solr builds, I asked
INFRA to restart 'lucene-solr-1'. They were happy to oblige (and I'm
now unblocked), but in the proc
MC.
>
> P.S.: I sometimes also run "apt update && apt dist-upgrade" to keep it
> uptodate (but not recently).
>
> Uwe
>
> Am 25.06.2024 um 20:20 schrieb Jason Gerlowski:
> > Hey all,
> >
> > Sending this email to discuss the ASF Jenkins'
Am 26.06.2024 um 22:39 schrieb Uwe Schindler:
> > Hi,
> >
> > looks like killing the stuck slave process ("sudo pkill -9 -u
> > jenkins") helped lucene-solr-2 to recover.
> >
> > Uwe
> >
> > Am 26.06.2024 um 16:30 schrieb Jason Gerlowski:
> >
Hi Mikhail,
I'm having trouble understanding the exact syntax you're proposing.
Is there a jira where the syntax is described in a little more detail?
If not, would you care to put together a writeup on a jira somewhere?
It's hard (for me at least) to weigh in as things are currently.
Best,
Ja
I missed the part of the meeting/lunch when our use of Github came up.
Can anyone that was present summarize the discussion in a little more
detail?
re: issues on github. There are challenges like avoiding
fragmentation and keeping multiple issue sources up to date, but those
are problems that pr
Hey all,
I've hit a small snag reviewing a few PRs on github recently. Wanted
to see if anyone has any suggestions for my workflow:
I’ve found myself in the position a few times where I want to add a
few small changes to a contributor’s PR…either to help them with a
piece they haven’t gotten to
ntion this as an optional checklist item in the PR template
that was recently added.
Still curious about other approaches though if anyone has suggestions.
[1]
https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork
On Tue, Sep 17, 2019 at 10:12 AM
Congratulations and welcome Atri!
On Wed, Sep 18, 2019 at 6:24 AM Shalin Shekhar Mangar
wrote:
>
> Congratulations and welcome Atri!
>
> On Wed, Sep 18, 2019 at 3:12 AM Adrien Grand wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>>
>> If you are fol
he idea of squash-merging from PR branch since (I believe) the
>> commit will then have the credit of the contributor which then shows up in
>> his/her stats on GH which is nice.
>>
>> Jan Høydahl
>>
>> > 17. sep. 2019 kl. 16:17 skrev Jason Gerlowski :
>> >
+1. That all sounds good to me. Excited to see some streamlining here.
On Fri, Sep 20, 2019 at 3:46 PM Cassandra Targett wrote:
>
> Thanks everyone, by the way, for the encouragement and feedback here.
>
> For next steps, how do folks feel about making the change to stop voting on
> the PDF *n
Hi Raphael,
Welcome and thanks for taking an interest in helping out! Shawn's
pointers above are all good for getting started. If there's any other
information you need, let us know.
You know best what you want to get involved with. But if you're
interested in QA and are interested in the Solr
Congratulations!
On Thu, Nov 14, 2019 at 11:58 AM Gus Heck wrote:
>
> Congratulations and welcome :)
>
> On Thu, Nov 14, 2019 at 11:52 AM Namgyu Kim wrote:
>>
>> Congratulations and welcome, Houston! :D
>>
>> On Fri, Nov 15, 2019 at 1:18 AM Ken LaPorte wrote:
>>>
>>> Congratulations Houston! We
Welcome Bruno!
On Sat, Nov 23, 2019 at 9:19 PM Tomoko Uchida
wrote:
>
> Congratulations and welcome!
>
> Tomoko
>
> 2019年11月24日(日) 10:22 Otis Gospodnetić :
> >
> > Hi,
> >
> > Welcome and great work!
> >
> > Otis
> > --
> > Monitoring - Log Management - Alerting - Anomaly Detection
> > Solr & Ela
+1
On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
wrote:
>
> +1
>
> On Mon, Nov 25, 2019 at 11:20 AM Noble Paul wrote:
>>
>> +1
>>
>> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
>> wrote:
>> >
>> > Hi,
>> > Recently, Colvin has reported
>> > https://issues.apache.org/jira/browse
> and now its turned around as if its consensus everywhere
David didn't say anything about consensus everywhere. He mentioned
pretty clearly that the agreement was only "in attendance", and that
this thread was a precursor for putting together a proposal to test
the waters further. That all seem
Hi all,
Wanted to sent out a notice about a change I plan on making this week
regarding how line endings are maintained in some of our OS-specific
files (bin/solr, zkcli, etc.).
Previously it's been on committers/contributors individually to put
the correct line endings in their files. This has
, I expect it to be totally invisible.
>
> This is mostly FYI, I happened to see the “fixcrlf” in the build files
> and thought I’d pass it along. I don’t think this should hold up the
> commit at all.
>
> Best,
> Erick
>
> > On Jan 14, 2020, at 10:18 AM, Jason G
> Perhaps a weekly email with a list of PRs from first timers?
+1. Would be a helpful nudge for committers to pay attention to other
contributors.
On Thu, Jan 23, 2020 at 4:46 AM Jan Høydahl wrote:
>
> I added some review comments on the PR:
> https://github.com/apache/lucene-solr/pull/908 as
> It's because of the recent change to solr/.gitattributes
> (SOLR-10713) [sic - SOLR-14186] End of lines differ for adoc files. Jason --
> please
> change this one from auto to "don't touch line endings on any of other
> files", whatever the magic is.
Since the issue ended up being a bad regex i
> It created an issue for me in that I spent two hours looking for a bug in the
> wrong place...
I regret that it made it harder for you to find the issue. But at the
end of the day the issue wasn't with gitattributes, it was a slip-up
in custom precommit code.
I agree with Jan - "auto" prevent
> I also think its confusing to have gitattributes at the root and then also
> under solr/
Oh, that's new. There wasn't a root gitattributes when I wrote the
solr/ one. Must have been added around the same time through the
gradle work?
Anyway, there's no technical reason afaik to keep the file
+1 on Option A.
[-0] on Option B. Even though it might not be everyday, I don't think
we should put roadblocks in front of users who want to clean up after
themselves. We do occasionally see users create jira issues and then
close them themselves when they realize user error or something else
wa
emory usage. (Bruno Roustant,
>>>>> Robert Muir)
>>>>> * LUCENE-9237: Faster UniformSplit intersect TermsEnum. (Bruno Roustant)
>>>>>
>>>>> These "Improvements" I think are better categorized as "Other":
>>>>>
Congrats and welcome Alessandro. Well deserved.
On Wed, Mar 18, 2020 at 2:34 PM Tomás Fernández Löbbe
wrote:
>
> Congrats and welcome Alessandro!
>
> On Wed, Mar 18, 2020 at 9:34 AM Erick Erickson
> wrote:
>>
>> Welcome Alessandro!
>>
>> On Wed, Mar 18, 2020, 10:32 Houston Putman wrote:
>>>
>
Hi Martin,
If you're looking for an overview of how the code is laid out and
structured, there's not a ton there that I'm aware of. In terms of
particular features, the best resource that comes to mind would be
some of the videos of conference talks from the last several years.
I've gotten some mi
-1 (binding)
On Tue, May 12, 2020 at 7:31 AM Alan Woodward wrote:
>
> +1 (binding)
>
> Alan Woodward
>
> > On 12 May 2020, at 12:06, Jan Høydahl wrote:
> >
> > +1 (binding)
> >
> > Jan Høydahl
> >
> >> 12. mai 2020 kl. 09:36 skrev Dawid Weiss :
> >>
> >> Dear Lucene and Solr developers!
> >>
> >
Wanted to add my two cents to the mix, though I'm a little late as the
vote has already progressed pretty far.
I'm against a split. From the points raised, I agree that Lucene has
much to gain. But Solr has a lot to lose.
Lucene devs would be freed from keeping Solr usage up to date. That's
a
g behind Lucene" is counterbalanced to me with "Should Solr be on
> cutting-edge Lucene?"
>
> I'd be OK with a stable, robust Solr that got 1-2 major versions behind
> Lucene, but was rock-solid with a lower barrier to entry...
>
> On Wed, May 13, 2020 at 10:07
> Would this not be eased to some extent if the initial committer base of both
> the projects was the same?
"Who has commit karma to a project" is a separate question from "Who
will make commits in practice". Having Lucene committers retain their
status as Solr committers only helps if they're w
> Hoss’s rollups are here:
> http://fucit.org/solr-jenkins-reports/failure-report.html which show the
> rates, but not where they came from.
If I click on a particular test entry on "failure-report.html", I'm
presented with dialog with links for each failure. Clicking that link
takes me to a fi
Congrats and welcome Gus!
On Thu, Nov 1, 2018 at 10:13 AM Gus Heck wrote:
>
> Hi all,
>
> Thanks for inviting me to be a committer!
>
> Bio:
> I've enjoyed programming computers for over 30 years now, starting on an
> Timex Sinclair 2k (with 16k expansion pack!). Until 2002 programming was a
> h
Welcome Mayya!
On Wed, Jun 10, 2020 at 4:44 AM Tommaso Teofili
wrote:
>
> congrats and welcome onboard Mayya!
>
> Regards,
> Tommaso
>
> On Tue, 9 Jun 2020 at 19:27, Trey Grainger wrote:
>>
>> Woohoo - awesome news! Congrats, Mayya!
>>
>> Trey Grainger
>> Founder, Searchkernel
>>
>> On Mon, Jun
Option "A"
On Tue, Jun 16, 2020 at 8:37 PM Man with No Name
wrote:
>
> A, clean and modern.
>
> On Mon, Jun 15, 2020 at 6:08 PM Ryan Ernst wrote:
>>
>> Dear Lucene and Solr developers!
>>
>> In February a contest was started to design a new logo for Lucene [1]. That
>> contest concluded, and I
Hi Pramod,
I'm pretty sure Erick answered some of your questions on the
SOLR-13205 jira already, but I wanted to restate those answers here
for other beginners that may be reading this thread or stumble on it
later.
The way our project is set up, only "committers" can assign tickets in
JIRA. In
> Is anyone on this list using schemaless mode in production or have you tried
> to?
Schemaless mode is one of a group of Solr features present for
convenience but not intended for production usage. It's in the same
boat as "bin/post", and SolrCell, and others. These features do cause
headaches
+1
On Fri, Aug 7, 2020 at 8:37 PM Marcus Eagan wrote:
>
> Any -1's? I just learned more about them from David Smiley earlier today and
> I recognize they are for the rare case, but I want to ensure consensus before
> I spend time on this tomorrow evening. I hadn't remembered seeing them in
> r
Hey Noble,
Can you explain what you mean when you say it's not secured? Just for
those of us who haven't been following the discussion so far? On the
surface of things users taking advantage of our RuleBasedAuth plugin
can secure this API like they can any other HTTP API. Or are you
talking abo
I agree with the approach Jan voiced - that at least some of these
features should appear in 9.0 as deprecated to give users more time.
That said, maybe discussing what to do around these features should be
its own thread or should be taken back to some of the specific jiras
where there's already
+1 to having some sort of vote before a big change like moving a
contrib. Also +1 to getting feedback on the user list as well; people
there might be able to give details on some of the functionality gaps
that Houston alluded to.
Personally I haven't done anything with the Analytics Component bey
A1, A2, D (binding)
On Wed, Sep 2, 2020 at 10:47 AM Michael McCandless
wrote:
>
> A2, A1, C5, D (binding)
>
> Thank you to everyone for working so hard to make such cool looking possible
> future Lucene logos! And to Ryan for the challenging job of calling this
> VOTE :)
>
> Mike McCandless
>
I created a few JIRAs to spike "bin/solr" tests several years back
(SOLR-11749). I didn't have quite enough time to get it across the finish
line previously but I think it's a great idea to have tests of this sort.
At the time I was writing tests in bash - but realized that wasn't a
particularly s
> If it’s inadvertently added, we either fix it within an hour or so or revert
> the offending commit
> I don't want to set specific time frames,
To play Devil's Advocate here: why wait even an hour to revert a 100%
test failure? Reverts are usually trivial to do, unblock others
immediately, an
Sep 18, 2020 at 9:06 PM Tomás Fernández Löbbe
>>
>> wrote:
>>
>> >
>>
>> > Sometimes Jenkins may take hours to take your commit, may fail in the
>> > middle of your night, may not fail consistently, etc. That's why I don
Hi all,
I ran into a query-parsing bug recently in SOLR-14859 that caused
problems for some of my usecases. I wanted to volunteer as RM for an
8.6.3 to get a bugfix release out for users that aren't ready for some
of the bigger changes in 8.7
I was thinking of cutting the branch in a week's time
3, 2020 at 11:11 AM Atri Sharma wrote:
>
> I was planning on a branch cut on 30th September for 8.7 — do we want to
> delay that?
>
> On Wed, 23 Sep 2020 at 19:37, Jason Gerlowski wrote:
>>
>> Hi all,
>>
>>
>>
>> I ran into a query-parsing bu
e regression.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Sep 23, 2020 at 10:07 AM Jason Gerlowski
>> wrote:
>>>
>>> Hi all,
>>>
>>> I ran int
I couldn't reproduce your error on running techproducts. Though
whatever is causing it locally for you sounds a bit related to
SOLR-13690 maybe?
Jason
On Wed, Sep 23, 2020 at 11:28 AM Munendra S N wrote:
>
> The wiki has steps to build solr with gradle
> https://cwiki.apache.org/confluence/disp
I don't know much about the new package/file-store, but it does sound
like a good replacement for 'userfiles' (which Eric is right- is
pretty awkward to work with).
My only concerns with using the filestore would be around its
availability. Is it enabled by default (or will it be in an upcoming
r
ttopadhyaya
> wrote:
>>
>> Standalone isn't supported.
>>
>> We need to transition away from the standalone mode and get rid of it
>> completely.
>>
>> On Fri, 25 Sep, 2020, 7:50 pm Jason Gerlowski, wrote:
>>>
>>> I don't
files is part of default list, so whatever replacement is there
> will need to be explicitly-named as well.
>
> Regards,
> Alex.
>
> On Fri, 25 Sep 2020 at 11:43, Jason Gerlowski wrote:
>
>
> You're left with the /filestore/ dir to put there what you want in
> standalo
smiley
>>
>>
>> On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma wrote:
>>>
>>> I will push the 8.7 release by a week to give Jason enough headroom to
>>>
>>>
>>> do the 8.6.3 release.
>>>
>>>
>>>
>>>
&
make more sense
> to do the upgrades for 8.7 and get that out the door rather than backport?
>
> FWIW,
> Erick
>
> > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski wrote:
> >
> > Hey all,
> >
> > I wanted to add 2 more blocker tickets to the
/versions/12348713), and it
> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
> Jetty upgrade less compelling to try.
>
> Are there any other issues not currently marked for 8.6.3 we’re waiting for
> before starting the RC?
> On Sep 29, 2020, 12:04 PM -
apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
[2] https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski wrote:
>
> The only one that was previously mentioned as a blocker was
> SOLR-14835, but from the comments on
Please vote for release candidate 1 for Lucene/Solr 8.6.3
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
You can run the smoke tester directly with this command:
python3 -u dev-tools/script
> wrote:
> >>
> >> +1 (binding)
> >>
> >> SUCCESS! [1:00:37.423566]
> >>
> >> Tried basic indexing and search and ran the smoke tester.
> >>
> >> On Sat, Oct 3, 2020 at 6:53 PM Jason Gerlowski
> wrote:
> >>>
The Lucene PMC is pleased to announce the release of Apache Lucene 8.6.3.
Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.
This
The Lucene PMC is pleased to announce the release of Apache Solr 8.6.3.
Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search, dynamic
clustering, database integrat
x even though the build process has been moved to the main project
>> : > for 9.0? Meaning, to release the 8.6.3 image there’s no change from
>> before,
>> : > right?
>> : >
>> : > I’m asking specifically about these instructions:
>> : >
>> : &
, 2020 at 12:05 PM Jason Gerlowski wrote:
>
> The traditional (non-docker) part of the release should now be wrapped
> up. Thanks everyone for the help and answering my questions here and
> in Slack. One final question:
>
> The final releaseWizard.py step instructs:
>
> &quo
trailing whitespace and Jan doesn’t
> want that for some reason and I haven’t had time to go back to it. See
> https://issues.apache.org/jira/browse/LUCENE-9434.
> On Oct 9, 2020, 11:09 AM -0500, Jason Gerlowski ,
> wrote:
>
> Small correction: I see now some pages for 8.4 and 8
at Atri has follow-ed
> > suit (following your lead, no doubt) for 8.6. Why? Looking at the page
> > navigation, it's clearly an oddity -- a change. And it's still DRAFT
> > despite it being released.
> >
> > ~ David Smiley
> > Apache Lucene/Solr S
n Thu, Oct 22, 2020 at 9:50 AM Jason Gerlowski wrote:
>
> I added that "DRAFT-" prefix mostly for the reason Atri mentioned: to
> indicate that the page was a WIP. I thought it might also have the
> side benefit of catching the eye of any committers who had Confluence
>
> then I'll start putting together individual proposals for a few repos to
> exercise the process and get more contributions going
solr-operator is a great example of PMC-maintained code that makes
sense to have in a separate repository. It's written primarily in a
different language, it's an in
Hey all,
This morning I published SIP-12, which proposes an overhaul of Solr's
backup and restore functionality. While the "headline" improvement in
this SIP is a change to do backups incrementally, it bundles in a
number of other improvements as well, including the addition of
corruption checks,
ld it be an idea to leave the old backup/resotre APIs as-is,
> and implement the new imporved version as a V2-api only, and then deprecate
> the v1 API? Then we don't need to worry about back-compat, and we get a
> head-start on converting the COLLECTION API to v2 style.
>
I missing something?
Best,
Jason
On Tue, Dec 22, 2020 at 2:49 AM Noble Paul wrote:
>
> >, and implement the new imporved version as a V2-api only, and then
> >deprecate the v1 API?
>
>
> V2 only please
>
> On Tue, Dec 22, 2020 at 1:34 AM Jason Gerlowski wrote:
>
t think we do have a v2 Backup/Restore API. We have a path
> alias to the old API which takes GET ...&action=backup... but we don’t have a
> true v2 API spec for it, do we? Where is that documented?
>
> Jan Høydahl
>
> > 22. des. 2020 kl. 18:04 skrev Jason Gerlowski :
Hey Erick,
I'm sorry for our users and for the project overall to hear you'll be
"hanging up the spurs", but excited that you've found new, fun things
to expand into in your retirement! I hope they're awesome!
Best of luck man, it's been great working with you!
Best,
Jason
On Mon, Jan 4, 2021
I was looking for, it’s not documented in the backup
> chapter of ref-guide :(
>
> Jan Høydahl
>
> > 23. des. 2020 kl. 17:10 skrev Jason Gerlowski :
> >
> >
> >>
> >> We have a path alias to the old API ... but we don’t have a true v2 API
> >
Hi all,
I recently spent some time on SOLR-15070 - a SolrJ ClassCastException
that cropped up for a customer hitting /suggest with wt=xml.
SOLR-15070 itself was a relatively straightforward fix, but the more I
think about the underlying cause the more I wonder whether we don't
have a larger, funda
, but they looked fine at a high
> level overview. Will probably look again after questions regarding v1/v2 are
> figured out.
>
> On Tue, Jan 5, 2021 at 10:11 AM Mike Drob wrote:
>>
>> Can you explicitly call out in the SIP how it relates to the work done in
&g
e of how the file structure of a backup looks like in the backup? and
> how the manifest file looks like. As you said, a file with the same name may
> refer to different segments created by different cores or the same one (even
> if the leader changed, it may be a file from a previous repli
t; wt=xml, you found a bug. Undoubtedly, we need better testing here and
> consequently hardening to make javabin & XML more consistent. We can only do
> so much for JSON.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
ions in one go, or backup a TRA alias with hundreds of
> concrete "sub" collections. But as I write these words I imagine it probably
> is way outside the scope for this SIP which is large enough. Anyone even
> tried to backup a TRA with today's API?
>
> Jan
>
ear future. If people feel strongly or would veto the
vote otherwise, then I'll try my best. But otherwise I think we're
best served waiting until other stuff settles out to revisit larger v2
backup API changes.
Best,
Jason
On Mon, Jan 11, 2021 at 10:41 AM Jason Gerlowski wrote
an one collection in the future, so that's
> perhaps something to consider. But if it gets too complicated we should
> just delay it and redesign the storage structure once again when we cross
> that bridge. I'll not veto the current suggestion.
>
> Jan
>
> >
ans that individual PRs can't be -1'd on design grounds?
Either way I'm happy to do whatever the process requires here. I'll
plan on starting the next step on Monday, whatever that needs to be.
Best,
Jason
On Thu, Jan 14, 2021 at 1:10 PM Jason Gerlowski wrote:
>
> Yea
business days.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Jan 15, 2021 at 9:32 AM Jason Gerlowski wrote:
>>
>> Jan - I've modified the file-structure page to include support for
>> storing
Personally I'd love to see us stop maintaining the duplicated code of
the underlying implementations. I wouldn't mind losing the legacy
syntax as well - I'll take a clear, verbose API over a less-clear,
concise one any day. But I'm probably a minority there.
Either way I agree with Michael when
Tentative +1 to Hoss' questions. I agree with his summary of the
potential risks here, and I share his ignorance of the perceived
benefits.
(I thought for a time that this was driven by interest in having
release cadences independent from Solr-core releases. I'm all for
that goal, but if that's
I agree with Noble that we shouldn't let those flakies hold up the
release. It really sucks, but Solr wouldn't've gotten out a release in
years if that was our bar.
FWIW though I disagree with his finer point that we shouldn't worry
about autoscaling in particular because it's slated for removal i
gt;>
>>> I haven't been able to follow up on creation of the extras repo, but more
>>> importantly I wanted to respond to Hoss. I'm out on an emergency for a week
>>> or so, shall resume then. If there's a decision on this until then, I shall
>>
> Shoving such a component into lucene-solr repo makes no sense, given its
> branching strategy is based on master / branch_8x
I get how this could cause issues - I def hadn't thought much about
multi-version support and branching. But I don't think moving plugins
to a separate repo solves that
Congrats!
On Fri, Feb 19, 2021 at 10:06 AM Divye wrote:
>
> Congratulations Jan!
>
> Regards,
> Divye
>
> On Fri, 19 Feb, 2021, 00:26 Anshum Gupta, wrote:
>
> > Hi everyone,
> >
> > I’d like to inform everyone that the newly formed Apache Solr PMC nominated
> > and elected Jan Høydahl for the po
I'm fine with standardization, whichever convention we choose. I have
a slight preference for FooTest, for the same reason Gus mentioned,
but any standard is better than none here IMO.
> prefer that we not make a sweeping change like this until after Mark's "ref
> branch" is reconciled
Personal
this thing can rise to meet the living. I’ve seen it
>> see dead people.
>>
>> End of the day, if the ref branch can’t survive even a large and lengthy
>> divergence, if that is the freeze in its tracks, it’s not at all what I’ve
>> said ive been working on and so doe
The Solr website looks great, thanks for doing this Jan. +1 from me.
Jason
On Wed, Mar 3, 2021 at 7:23 AM Jan Høydahl wrote:
>
> Privacy policy on the web sites (I copied Lucene's to the new Solr site)
>
> https://lucene.apache.org/privacy.html
> https://lucene-solrtlp.staged.apache.org/privacy.
Hey all,
This is my fault. Will look at fixing it this morning. Sorry for the
disruption!
If this is blocking anyone, let me know and I'll revert the offending
commit while I investigate the cause. Otherwise I'll just leave it
as-is and push to have a fix as soon as I can.
Jason
On Sat, May
se let me know.
Jason
On Tue, Jun 1, 2021 at 7:55 AM Jason Gerlowski wrote:
>
> Hey all,
>
> This is my fault. Will look at fixing it this morning. Sorry for the
> disruption!
>
> If this is blocking anyone, let me know and I'll revert the offending
> commit while
ranch_8_9 as well. Would
> it be possible for you to do this?
>
> I will look into how to fix another error about "Future release 8.9.0 is
> greater than 8.10.0".
>
> On Thu, Jun 3, 2021 at 7:54 AM Jason Gerlowski wrote:
>>
>> I pushed a commit to branc
> Do you happen to have the command that reproduced this for you?
To clarify, I know how to run the smoke-tester generally, but every
time I've run it in the past I've had a link to a specific RC, and I'm
not sure what to do without that.
Jason
On Mon, Jun 7, 2021 at 2:59
ed [1] in
>> favor of "jakarta annotations" [2] which uses a new
>> non-colliding/jar-helling "jakarta.annotation" package/module:
>>
>> 1. https://github.com/javaee/javax.annotation/
>> 2. https://github.com/eclipse-ee4j/common-annotations-api
>>
&g
Looks like the latest changes did the trick - the smoke-release job
passed overnight:
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-SmokeRelease-8.9/7/
Sorry to block you for a bit Mayya; good luck with the rest of the release!
Jason
On Wed, Jun 9, 2021 at 10:07 AM Jason Gerlowski
Welcome Nhat!
On Tue, Jun 19, 2018 at 10:10 AM, Varun Thacker wrote:
> Congratulations and welcome Nhat!
>
> On Tue, Jun 19, 2018 at 10:16 AM, Alan Woodward
> wrote:
>
>> Welcome Nhat!
>>
>>
>> On 18 Jun 2018, at 21:41, Adrien Grand wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Nhat N
1 - 100 of 1025 matches
Mail list logo
