Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Shalin Shekhar Mangar]

Congratulations Anshum!

On Thu, Jan 16, 2020 at 2:45 AM Cassandra Targett 
wrote:

> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
> President position.
>
> This year we have nominated and elected Anshum Gupta as the Chair, a
> decision that the board approved in its January 2020 meeting.
>
> Congratulations, Anshum!
>
> Cassandra
>
>

-- 
Regards,
Shalin Shekhar Mangar.

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Kevin Risden]

Congrats Anshum!

Kevin Risden


On Thu, Jan 16, 2020 at 7:30 PM Joel Bernstein  wrote:

> Congrats Anshum!
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Thu, Jan 16, 2020 at 1:05 PM Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
>> Congrats Anshum!
>>
>> Christine
>>
>> From: dev@lucene.apache.org At: 01/15/20 21:15:28
>> To: dev@lucene.apache.org
>> Subject: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!
>>
>> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
>> President position.
>>
>> This year we have nominated and elected Anshum Gupta as the Chair, a
>> decision that the board approved in its January 2020 meeting.
>>
>> Congratulations, Anshum!
>>
>> Cassandra
>>
>>
>>

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Joel Bernstein]

Congrats Anshum!

Joel Bernstein
http://joelsolr.blogspot.com/


On Thu, Jan 16, 2020 at 1:05 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Congrats Anshum!
>
> Christine
>
> From: dev@lucene.apache.org At: 01/15/20 21:15:28
> To: dev@lucene.apache.org
> Subject: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!
>
> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
> President position.
>
> This year we have nominated and elected Anshum Gupta as the Chair, a
> decision that the board approved in its January 2020 meeting.
>
> Congratulations, Anshum!
>
> Cassandra
>
>
>

Re:Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Christine Poerschke (BLOOMBERG/ LONDON)]

Congrats Anshum!

Christine

From: dev@lucene.apache.org At: 01/15/20 21:15:28To:  dev@lucene.apache.org
Subject: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice 
President position.

This year we have nominated and elected Anshum Gupta as the Chair, a decision 
that the board approved in its January 2020 meeting.

Congratulations, Anshum!

Cassandra

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Houston Putman]

Congrats Anshum!!

On Thu, Jan 16, 2020, 8:51 AM Alan Woodward  wrote:

> Congratulations Anshum!
>
> On 15 Jan 2020, at 21:15, Cassandra Targett  wrote:
>
> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
> President position.
>
> This year we have nominated and elected Anshum Gupta as the Chair, a
> decision that the board approved in its January 2020 meeting.
>
> Congratulations, Anshum!
>
> Cassandra
>
>
>

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Alan Woodward]

Congratulations Anshum!

> On 15 Jan 2020, at 21:15, Cassandra Targett  > wrote:
> 
> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice 
> President position.
> 
> This year we have nominated and elected Anshum Gupta as the Chair, a decision 
> that the board approved in its January 2020 meeting.
> 
> Congratulations, Anshum!
> 
> Cassandra
> 

Re: gitattributes and line-endings

[Jason Gerlowski]

Thanks for the heads up Erick.

I poked around a little bit there and agree that this shouldn't affect
the gitattributes change.  I'm also curious why it was needed.  Maybe
Yonik or someone else involved with putting it in could clarify for
curiosity's sake.

Jason

On Tue, Jan 14, 2020 at 11:22 AM Erick Erickson  wrote:
>
> Jason:
>
> I’ve been poking around some of the regenerate code. I should say
> up-front that I have no idea whether this is relevant or not, but…
>
> Here’s a command to scare you:
>
> "find . -name build.xml | xargs grep -i fixcrlf”
>
> To be frank, I’m not totally sure what the intent for those is. From
> what I can tell they operate on java files that are the output from
> things like jflex and just modify line endings for the Java output,
> presumably the output may have windows-style line endings, but
> that’s a guess. Originally I had a vague fear that it operated on
> binary output, but this made me look more deeply and I don’t see that.
>
> So since they appear to be working on generated Java code, and
> I assume this is happening before the git operations you
> outlined, 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 Gerlowski  wrote:
> >
> > 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 bitten us a few
> > times recently.  solr.cmd often ends up missing the CRLF EOLs that it
> > needs, which breaks the code surrounding those edits. See SOLR-13977
> > for a recent example.
> >
> > To remedy this, I plan on adding a .gitattributes file to normalize
> > EOL's across Solr code.  File editing is unchanged.  But on certain
> > git commands (add, commit, checkout), git will rewrite the line
> > endings of changed files to match the desired EOL for that file.  For
> > most files, this is LF.  For Windows specific files, this is CRLF.
> > See 
> > https://github.com/apache/lucene-solr/pull/1163/files#diff-c781eab6689a2956b8e2d082fdecbe38
> > for the specific rules.
> >
> > This change should be entirely invisible to developers, with two caveats:
> >
> > 1. Of necessity, the gitattributes PR also corrects a few files that
> > have the wrong line endings currently.  Developers applying old
> > patches that touch one of these files will encounter merge conflicts
> > due to the EOL changes.
> >
> > 2. If developers have incorrect line endings in files unique to a
> > feature branch, and they merge master into that feature branch, they
> > may see unexpected changes in git-status as git normalizes the EOL's
> > in those files.
> >
> > Given how rare incorrect EOLs are (outside of solr.cmd), I expect this
> > change will be invisible to 99% of developers.  If anyone has any
> > questions or concerns, let me know or comment on the PR (#1163)
> > directly.  I plan on merging the change tomorrow or the day after.
> >
> > Best,
> >
> > Jason
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Adrien Grand]

Congratulations, Anshum!

On Wed, Jan 15, 2020 at 10:15 PM Cassandra Targett 
wrote:

> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
> President position.
>
> This year we have nominated and elected Anshum Gupta as the Chair, a
> decision that the board approved in its January 2020 meeting.
>
> Congratulations, Anshum!
>
> Cassandra
>
>

-- 
Adrien

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Mikhail Khludnev]

Congratulations, Anshum!

On Thu, Jan 16, 2020 at 2:23 AM Anshum Gupta  wrote:

> Thank you everyone! :)
>
> On Wed, Jan 15, 2020 at 2:54 PM Uwe Schindler  wrote:
>
>> Moin,
>>
>>
>>
>> Congratulations from one of the previous chairs! You’ll have a hard time
>> (just joking!).
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> https://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Tomás Fernández Löbbe 
>> *Sent:* Wednesday, January 15, 2020 11:28 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum
>> Gupta!
>>
>>
>>
>> Congrats Anshum!!
>>
>>
>>
>> On Wed, Jan 15, 2020 at 2:25 PM David Smiley 
>> wrote:
>>
>> Congrats Anshum!
>>
>>
>> ~ David Smiley
>>
>> Apache Lucene/Solr Search Developer
>>
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>>
>>
>>
>> On Wed, Jan 15, 2020 at 4:15 PM Cassandra Targett 
>> wrote:
>>
>> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
>> President position.
>>
>> This year we have nominated and elected Anshum Gupta as the Chair, a
>> decision that the board approved in its January 2020 meeting.
>>
>>
>>
>> Congratulations, Anshum!
>>
>>
>>
>> Cassandra
>>
>>
>>
>>
>
> --
> Anshum Gupta
>


-- 
Sincerely yours
Mikhail Khludnev

Re: Gradle build is on master

[Dawid Weiss]

Hi Uwe,

> Can we correct it on ant's side somehow (by ignoring jetty-start-*)?

I've just committed a quick workaround so that ant-regenerate doesn't wipe
this particular file (on master) so that builds can pass.

I don't know any better solution to this. If we're looking to
switching to gradle then
I'd rather consider the gradle build the primary source of truth and
fix ant to what's
required for it to pass. Let me know what you think though.

D.

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

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Dawid Weiss]

Congratulations!
D.

On Thu, Jan 16, 2020 at 3:55 AM Gus Heck  wrote:
>
> Congratulations :)
>
> On Wed, Jan 15, 2020, 8:21 PM Đạt Cao Mạnh  wrote:
>>
>> Congrats Anshum!!
>>
>> On Thu, 16 Jan 2020 at 08:43, Michael McCandless  
>> wrote:
>>>
>>> Congrats Anshum!  It's great fun!
>>>
>>> Mike
>>>
>>> On Wed, Jan 15, 2020 at 6:24 PM Steve Rowe  wrote:

 Congrats Anshum!

 --
 Steve


 On Jan 15, 2020, at 4:15 PM, Cassandra Targett  wrote:

 Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice 
 President position.

 This year we have nominated and elected Anshum Gupta as the Chair, a 
 decision that the board approved in its January 2020 meeting.

 Congratulations, Anshum!

 Cassandra


>>> --
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>
>> --
>> Best regards,
>> Cao Mạnh Đạt
>> E-mail: caomanhdat...@gmail.com

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

Re: Gradle build is on master

[Dawid Weiss]

> Thanks Dawid – great work!

Thank you all. I don't think it's particularly great, but definitely a
step forward from ant which has gotten very complex and where simple
things are difficult to achieve. Gradle is not without its own issues
(some known, some waiting to be discovered) but it is manageable I
think.

> there is a small problem with Jenkins (still running ANT build; I may add a 
> second one running the gradle build!):

Gradle on a CI will require some overrides -- I'd disable the daemon
and set the number of workers manually. Something like:

./gradlew --no-daemon --max-workers=5 ...

In the initial stage it'd be enough if you just ran precommit and
other checks, without tests:

./gradlew --no-daemon --max-workers=5 precommit check -x test

This would be helpful enough! Of course you can run tests as well but
they take approximately the same amount of time as with ant in my
experience.

> The Jenkins build does a license and JAR file check by first deleting all 
> checksum files and then regenerate all of them from the downloaded artifacts. 
> Afterwards it checks that the GIT checkout is clean. This is done to detect 
> obsolete or incorrect checksum files.

This only works for sha files, right? Because I removed quite a few
other dangling files when I implemented this for the gradle
counterpart (Gradle build does this kind of check as part of
precommit).

> With the gradle update you added the shaded jetty JAR file, but the old ANT 
> build seems to still use the old/different name. It means after checksum 
> regeneration the checkout is no longer clean:

Correct. The shaded jetty jar file is the only exception I made. It
just didn't fit the logical way those files are looked up (by their
real artifact name). In fact I ignore "start.jar" in gradle, otherwise
it'd be reported as a dangling file...

> /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:494: Source 
> checkout is dirty (unversioned/missing files) after running tests!!! 
> Offending files:
>
> * solr/licenses/jetty-start-9.4.24.v20191120-shaded.jar.sha1

Can we correct it on ant's side somehow (by ignoring jetty-start-*)?
This file points at a real dependency and you can tell what this
dependency is while "start.jar.sha1" doesn't really mean anything (and
it isn't easy to figure out which license applies to it, etc.). There
are more oddball checksums in there that don't really match true
redistributed project dependencies [1] but this one is the most
annoying one I think.

D.

[1] 
https://github.com/apache/lucene-solr/blob/master/gradle/validation/jar-checks.gradle#L340-L368

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

RE: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 ECC, 2x1 Terabyte NVME SSD as RAID

[Uwe Schindler]

Actually it’s printed in reproduce line. Sorry for the false alarm.

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

  https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Uwe Schindler  
Sent: Thursday, January 16, 2020 9:29 AM
To: dev@lucene.apache.org
Subject: RE: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 
ECC, 2x1 Terabyte NVME SSD as RAID

 

$ cat lucene.build.properties

tests.jvms=6

tests.multiplier=3

 

-

UWE SCHINDLER

Software Architecture, Apache Lucene, Elasticsearch

PANGAEA - Data Publisher for Earth & Environmental Science

MARUM (FVG Ost building) - University of Bremen

Room 0210, Leobener Str. 2, D-28359 Bremen

Tel.: +49 421 218 65595

Fax:  +49 421 218 65505

  https://www.pangaea.de/

E-mail: uschind...@pangaea.de  

 

From: Dawid Weiss mailto:dawid.we...@gmail.com> > 
Sent: Thursday, January 16, 2020 9:24 AM
To: Lucene Dev mailto:dev@lucene.apache.org> >
Subject: Re: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 
ECC, 2x1 Terabyte NVME SSD as RAID

 

 

With new CPU, builds seem up to 2 times faster. FYI, the Linux builds are 
running with tests.multiplicator=3 to better trigger JVM failures. You have to 
remind about that when you reproduce failures - it looks like this is not 
printed in reproduce lines.

 

It is printed with gradle builds (any non-defaults are). The option is 
"tests.multiplier" actually; check if you don't have a typo there?

 

But we can also drop Solaris builds, as they only work with 8.x - no Java 11 
support on Solaris anymore by Oracle. Any comments?

 

As somebody who tries to look at each failure sent to the mailing list (at 
least recently...) I still think the EA builds that are KNOWN to be buggy 
should be disabled until next upgrade. They pollute the mailing list with so 
many identical errors that this discourages one from looking through the logs.

 

Dawid 

RE: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 ECC, 2x1 Terabyte NVME SSD as RAID

[Uwe Schindler]

Actually the Solaris builds are sometimes hanging forever (more often with new 
hardware). So they don’t pollute mailinglist they just block executor. I have 
to manually kill them.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

  https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Dawid Weiss  
Sent: Thursday, January 16, 2020 9:24 AM
To: Lucene Dev 
Subject: Re: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 
ECC, 2x1 Terabyte NVME SSD as RAID

 

 

With new CPU, builds seem up to 2 times faster. FYI, the Linux builds are 
running with tests.multiplicator=3 to better trigger JVM failures. You have to 
remind about that when you reproduce failures - it looks like this is not 
printed in reproduce lines.

 

It is printed with gradle builds (any non-defaults are). The option is 
"tests.multiplier" actually; check if you don't have a typo there?

 

But we can also drop Solaris builds, as they only work with 8.x - no Java 11 
support on Solaris anymore by Oracle. Any comments?

 

As somebody who tries to look at each failure sent to the mailing list (at 
least recently...) I still think the EA builds that are KNOWN to be buggy 
should be disabled until next upgrade. They pollute the mailing list with so 
many identical errors that this discourages one from looking through the logs.

 

Dawid 

RE: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 ECC, 2x1 Terabyte NVME SSD as RAID

[Uwe Schindler]

$ cat lucene.build.properties

tests.jvms=6

tests.multiplier=3

 

-

UWE SCHINDLER

Software Architecture, Apache Lucene, Elasticsearch

PANGAEA - Data Publisher for Earth & Environmental Science

MARUM (FVG Ost building) - University of Bremen

Room 0210, Leobener Str. 2, D-28359 Bremen

Tel.: +49 421 218 65595

Fax:  +49 421 218 65505

  https://www.pangaea.de/

E-mail: uschind...@pangaea.de

 

From: Dawid Weiss  
Sent: Thursday, January 16, 2020 9:24 AM
To: Lucene Dev 
Subject: Re: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 
ECC, 2x1 Terabyte NVME SSD as RAID

 

 

With new CPU, builds seem up to 2 times faster. FYI, the Linux builds are 
running with tests.multiplicator=3 to better trigger JVM failures. You have to 
remind about that when you reproduce failures - it looks like this is not 
printed in reproduce lines.

 

It is printed with gradle builds (any non-defaults are). The option is 
"tests.multiplier" actually; check if you don't have a typo there?

 

But we can also drop Solaris builds, as they only work with 8.x - no Java 11 
support on Solaris anymore by Oracle. Any comments?

 

As somebody who tries to look at each failure sent to the mailing list (at 
least recently...) I still think the EA builds that are KNOWN to be buggy 
should be disabled until next upgrade. They pollute the mailing list with so 
many identical errors that this discourages one from looking through the logs.

 

Dawid 

Re: New Policeman Jenkins Hardware: AMD Ryzen 7 3700X Octa-Core, DDR4 ECC, 2x1 Terabyte NVME SSD as RAID

[Dawid Weiss]

> With new CPU, builds seem up to 2 times faster. FYI, the Linux builds are
> running with tests.multiplicator=3 to better trigger JVM failures. You have
> to remind about that when you reproduce failures - it looks like this is
> not printed in reproduce lines.
>

It is printed with gradle builds (any non-defaults are). The option is
"tests.multiplier" actually; check if you don't have a typo there?


> But we can also drop Solaris builds, as they only work with 8.x - no Java
> 11 support on Solaris anymore by Oracle. Any comments?


As somebody who tries to look at each failure sent to the mailing list (at
least recently...) I still think the EA builds that are KNOWN to be buggy
should be disabled until next upgrade. They pollute the mailing list with
so many identical errors that this discourages one from looking through the
logs.

Dawid