date:20190918

> However Anshum does make a good point that users wouldn't know when the pages 
> have changed. I think it would be great to have a link on each ref-guide page 
> that shows the last modified date and links to the history of that page in 
> github

We now have an "Errata" page, which is never used and won't make sense for a 
live HTML guide.
Perhaps we could instead provide a single HTML page or HTML table as part of or 
alongside each guide, showing all commits touching the guide on that branch 
after the release. Could probably be baked in as part of the release script. 
Using the release date or git hash for the release, it should be possible with 
some git woodo to bring up a list of commits that changed the guide after 
release. That table would normally be very few lines, and would link directly 
to the commit that caused the change.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 18. sep. 2019 kl. 23:26 skrev Houston Putman :
> 
> I've had issues with asiidoc features available for the HTML version that 
> didn't work in PDF, and it was pretty frustrating to work around it. I think 
> just having the site would be an improvement for the development side, but 
> I've never used the PDF version myself.
> 
> Easy back-porting of documentation would make the solr user experience better 
> too, especially if the ref-guide is published on each merge. There are lots 
> of features that have been around for a while that could use better 
> documentation, and we shouldn't restrict better documentation to the later 
> releases when the features haven't changed since an earlier release. I always 
> go to the ref guide version that corresponds to the Solr version I'm looking 
> into, and I would assume most people do as well. If this is the default use 
> case of the ref guide, then I think backporting as many documentation fixes 
> as possible would be great for user experience (as long as the documentation 
> doesn't rely on new features).
> 
> However Anshum does make a good point that users wouldn't know when the pages 
> have changed. I think it would be great to have a link on each ref-guide page 
> that shows the last modified date and links to the history of that page in 
> github. That at least gives visibility to the changes, and it could show the 
> date of the most recent update. I'm not sure how hard that would be to 
> implement, but I would be happy to get something started if anyone else 
> thinks it's a worthwhile feature.
> 
> - Houston Putman
> 
> On Wed, Sep 18, 2019 at 5:01 PM Jan Høydahl  > wrote:
> +1 to skip pdf and auto publish ref guides to html on every merge to a branch.
> 
> We could also start publishing a draft 9.x guide there, clearly labeled as 
> work in progress.
> 
> Jan Høydahl
> 
> > 18. sep. 2019 kl. 19:38 skrev Chris Hostetter  > >:
> > 
> > 
> > First and foremost I should mention: I'm currently in favor of just about 
> > everything Cassandra has suggested here...
> > 
> > : So, I propose making some radical changes. My ideas here require a shift
> > : from thinking of the Guide as a release artifact like the binaries to
> > : thinking of it similar to how we treat javadocs. These ideas also allow us
> > 
> > I would actually go farther then that, and suggest that moving forward the 
> > "official ref-guide" for "Solr X.Y" (hosted on lucene.apache.org 
> > ) 
> > automatically be updated anytime anyone pushes edits to brach_X_Y -- as 
> > opposed to our javadocs for X.Y.0 which *might* be rebuilt for formatting 
> > purposes (something we've done in the past) but no *code* (ie: "content") 
> > changes on branch_X_Y would be reflected ... those would be part of the 
> > "bug fix" release X.Y.1, which would have it's own javadocs.  But 
> > meanwhile, the ref-guide for X.Y could/would be updated with doc 
> > improvements even if there were no bug-fix releases from branch_X_Y.
> > 
> > 
> > : -- By ASF policy, release artifacts must be produced on a machine
> > : controlled by the committer. However, the point here is that the Ref Guide
> > : would no longer be a release artifact, so I think that gets us around that
> > : rule? If anyone sees this differently that would change things here a
> > : little bit.
> > 
> > FWIW: My understand from years ago was that the policy was unambiguious:
> > 1) a release vote is neccessary for anything that goes on dist.apache.org 
> > 
> > 2) any "downloads" should come from dist.apache.org 
> > 
> > ...so "browseable html" docs on lucene.apache.org 
> >  wouldn't require a 
> > VOTE, but if we want to keep providing a provide a big PDF or zip file of 
> > all the HTML that would require a vote -- *BUT* it seems like the rules 
> > are more ambiguious now, particularly regarding "documentation" downloads 
> > ... ex: i know openoffice

Re: Rethinking how we publish the Solr Ref Guide

2019-09-18 Thread Houston Putman

I've had issues with asiidoc features available for the HTML version that
didn't work in PDF, and it was pretty frustrating to work around it. I
think just having the site would be an improvement for the development
side, but I've never used the PDF version myself.

Easy back-porting of documentation would make the solr user experience
better too, especially if the ref-guide is published on each merge. There
are lots of features that have been around for a while that could use
better documentation, and we shouldn't restrict better documentation to the
later releases when the features haven't changed since an earlier release.
I always go to the ref guide version that corresponds to the Solr version
I'm looking into, and I would assume most people do as well. If this is the
default use case of the ref guide, then I think backporting as many
documentation fixes as possible would be great for user experience (as long
as the documentation doesn't rely on new features).

However Anshum does make a good point that users wouldn't know when the
pages have changed. I think it would be great to have a link on each
ref-guide page that shows the last modified date and links to the history
of that page in github. That at least gives visibility to the changes, and
it could show the date of the most recent update. I'm not sure how hard
that would be to implement, but I would be happy to get something started
if anyone else thinks it's a worthwhile feature.

- Houston Putman

On Wed, Sep 18, 2019 at 5:01 PM Jan Høydahl  wrote:

> +1 to skip pdf and auto publish ref guides to html on every merge to a
> branch.
>
> We could also start publishing a draft 9.x guide there, clearly labeled as
> work in progress.
>
> Jan Høydahl
>
> > 18. sep. 2019 kl. 19:38 skrev Chris Hostetter  >:
> >
> >
> > First and foremost I should mention: I'm currently in favor of just
> about
> > everything Cassandra has suggested here...
> >
> > : So, I propose making some radical changes. My ideas here require a
> shift
> > : from thinking of the Guide as a release artifact like the binaries to
> > : thinking of it similar to how we treat javadocs. These ideas also
> allow us
> >
> > I would actually go farther then that, and suggest that moving forward
> the
> > "official ref-guide" for "Solr X.Y" (hosted on lucene.apache.org)
> > automatically be updated anytime anyone pushes edits to brach_X_Y -- as
> > opposed to our javadocs for X.Y.0 which *might* be rebuilt for
> formatting
> > purposes (something we've done in the past) but no *code* (ie:
> "content")
> > changes on branch_X_Y would be reflected ... those would be part of the
> > "bug fix" release X.Y.1, which would have it's own javadocs.  But
> > meanwhile, the ref-guide for X.Y could/would be updated with doc
> > improvements even if there were no bug-fix releases from branch_X_Y.
> >
> >
> > : -- By ASF policy, release artifacts must be produced on a machine
> > : controlled by the committer. However, the point here is that the Ref
> Guide
> > : would no longer be a release artifact, so I think that gets us around
> that
> > : rule? If anyone sees this differently that would change things here a
> > : little bit.
> >
> > FWIW: My understand from years ago was that the policy was unambiguious:
> > 1) a release vote is neccessary for anything that goes on
> dist.apache.org
> > 2) any "downloads" should come from dist.apache.org
> > ...so "browseable html" docs on lucene.apache.org wouldn't require a
> > VOTE, but if we want to keep providing a provide a big PDF or zip file
> of
> > all the HTML that would require a vote -- *BUT* it seems like the rules
> > are more ambiguious now, particularly regarding "documentation"
> downloads
> > ... ex: i know openoffice provides downloadable PDFs of their user guide
> > from their wiki, pretty sure they don't vote on that.
> >
> >
> >
> > : PS, As for the PDF, I believe there are mixed opinions about it. Some
> rely
> >
> > As someone who has been a long time advocate of the PDF, and of treating
> > it as an "official (VOTEed) release artifact" i wanted to toss out some
> > historical context, and notes on how/why my own feelings have evolved.
> >
> > Once upon a time, Solr had shit-all user documentation.  We had nothing
> > but our (moin moin) wiki, which was a hodge-podge mess, an amalgmaation
> > mix of docs written by developers as features were created, and "tips"
> > pages written by users with thoughts on how to do things, and none of it
> > was well organized and all of it was sprinkled with "this feature
> > was added in version X.Y but changed defaults to FOO in version X.Z..."
> >
> > When the lucidworks created the first few versions of the ref-guide
> using
> > Confluence as a CMS, and donated it to the ASF, i (and others) really
> felt
> > it was important that end users could see this new material as official,
> > authoritative, and "specific" (to each version of Solr) ... we did *NOT*
> > want people to start thinking of it as "just

Re: Rethinking how we publish the Solr Ref Guide

+1 to skip pdf and auto publish ref guides to html on every merge to a branch.

We could also start publishing a draft 9.x guide there, clearly labeled as work 
in progress.

Jan Høydahl

> 18. sep. 2019 kl. 19:38 skrev Chris Hostetter :
> 
> 
> First and foremost I should mention: I'm currently in favor of just about 
> everything Cassandra has suggested here...
> 
> : So, I propose making some radical changes. My ideas here require a shift
> : from thinking of the Guide as a release artifact like the binaries to
> : thinking of it similar to how we treat javadocs. These ideas also allow us
> 
> I would actually go farther then that, and suggest that moving forward the 
> "official ref-guide" for "Solr X.Y" (hosted on lucene.apache.org) 
> automatically be updated anytime anyone pushes edits to brach_X_Y -- as 
> opposed to our javadocs for X.Y.0 which *might* be rebuilt for formatting 
> purposes (something we've done in the past) but no *code* (ie: "content") 
> changes on branch_X_Y would be reflected ... those would be part of the 
> "bug fix" release X.Y.1, which would have it's own javadocs.  But 
> meanwhile, the ref-guide for X.Y could/would be updated with doc 
> improvements even if there were no bug-fix releases from branch_X_Y.
> 
> 
> : -- By ASF policy, release artifacts must be produced on a machine
> : controlled by the committer. However, the point here is that the Ref Guide
> : would no longer be a release artifact, so I think that gets us around that
> : rule? If anyone sees this differently that would change things here a
> : little bit.
> 
> FWIW: My understand from years ago was that the policy was unambiguious:
> 1) a release vote is neccessary for anything that goes on dist.apache.org
> 2) any "downloads" should come from dist.apache.org
> ...so "browseable html" docs on lucene.apache.org wouldn't require a 
> VOTE, but if we want to keep providing a provide a big PDF or zip file of 
> all the HTML that would require a vote -- *BUT* it seems like the rules 
> are more ambiguious now, particularly regarding "documentation" downloads 
> ... ex: i know openoffice provides downloadable PDFs of their user guide 
> from their wiki, pretty sure they don't vote on that.
> 
> 
> 
> : PS, As for the PDF, I believe there are mixed opinions about it. Some rely
> 
> As someone who has been a long time advocate of the PDF, and of treating 
> it as an "official (VOTEed) release artifact" i wanted to toss out some 
> historical context, and notes on how/why my own feelings have evolved.
> 
> Once upon a time, Solr had shit-all user documentation.  We had nothing 
> but our (moin moin) wiki, which was a hodge-podge mess, an amalgmaation 
> mix of docs written by developers as features were created, and "tips" 
> pages written by users with thoughts on how to do things, and none of it 
> was well organized and all of it was sprinkled with "this feature 
> was added in version X.Y but changed defaults to FOO in version X.Z..."
> 
> When the lucidworks created the first few versions of the ref-guide using 
> Confluence as a CMS, and donated it to the ASF, i (and others) really felt 
> it was important that end users could see this new material as official, 
> authoritative, and "specific" (to each version of Solr) ... we did *NOT* 
> want people to start thinking of it as "just another wiki".  Since 
> confluence didn't have an easy way to "branch" the entire space for 
> each version (not w/o a lot of infra assistance) and *did* provide an easy 
> way to publish the entire guide as a PDF, doing that and voting on the 
> resulting PDF as a true "documentation release artifact" seemed like a 
> good way to ensure we not only had version specific "snapshots" of the 
> content, but gave these PDFs more "legtimacy" as being "official".
> 
> When we migrated to using asciidoctor, i (and others?) really felt like it 
> was important to keep the continuity of having an "official PDF release 
> artifact" since that was what our users were use to to ensure they were 
> looking a the "correct" ref-guide version.  (With the old confluence CMS, 
> the only "browseable" html view of the content corrisponded to the latest 
> branch_YYY_x, with a handful of pages for trunk only features).  But of 
> course: being able to branch the ref-guide source alongwith the code, and 
> being able to build & host browseable HTML pages for all the content was a 
> really nice value add.
> 
> The project, our documentation, and the communities views/experience with 
> our documetation aren't the same as they were 6+ years ago.  As already 
> mentioned by a few people: it seems like most users browse/read the 
> (version specific) ref-guide hosted on lucene.apache.org.  The handful of 
> users who really care about "offline" access to the content on their 
> laptops can probably build the HTML site locally from source just as 
> easily as they can downloda the PDF.
> 
> So while My 2013 self, and my 2015 self, and even my 2017

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

My vote:
[v ] Leave it as is 

I guess one could achieve the same goal without sending to dev@ if Jira allowed 
users to configure notifications for certain projects individually. We could 
then document somewhere that option for those who don’t want to subscribe to 
issues@. Now the notification setting can only be changed by admins (or rather 
INFRA).

Infra will upgrade to latest jira with LDAP support soon, perhaps the new 
version has something?

Jan Høydahl

> 18. sep. 2019 kl. 20:11 skrev Namgyu Kim :
> 
> [x] A mail to dev@ for every new JIRA
> [x] One daily digest mail per day with a list of new JIRAs
> 
> One of the two looks fine.
> I think these methods seem possible to prevent missing new issues from the 
> issues@ folder.
> 
>> On Thu, Sep 19, 2019 at 12:46 AM Atri Sharma  wrote:
>> [v] leave it as it is — I like it quiet
>> 
>>> On Wed, 18 Sep 2019 at 19:42, Cassandra Targett  
>>> wrote:
>>> [v ] Leave it as is - I like quiet
>>> 
>>> I like the clear separation between the lists. It already feels less 
>>> hectic/overwhelming to me. I will read both as often as I can anyway, so I 
>>> don’t feel I’ll miss anything if the lists stay the way they are now.
>>> 
>>> There is a Jira plugin to support email digest notifications. I know 
>>> nothing about it, just found it in a quick Google search for Jira 
>>> notifications. A custom bot might be a better solution, but thought I’d 
>>> point it out in case Infra would be willing to install it: 
>>> https://marketplace.atlassian.com/apps/1217383/email-notifications-digest?hosting=server=overview
>>> 
>>> Thanks for working on these types of improvements!
>>> 
>>> Cassandra
 On Sep 18, 2019, 8:54 AM -0500, Jan Høydahl , wrote:
 Going for a daily digest bot we could clarify this in the email text:
 
 Here is a list of new Lucene/Solr issues created on -MM-DD
 
 LUCENE-NNN  Nice new feature
 SOLR-NNNUnfortunate bug
 
 To get updates for these issues in the future, watch them in JIRA.
 To get updates for all issues, subscribe to the issues@ mailing list.
 
 
> 18. sep. 2019 kl. 15:34 skrev Adrien Grand :
> 
> [x] Leave it as is - I like quiet
> 
> It's not that much that I like quiet, but rather that I can easily
> imagine it become confusing over time as new contributors join the
> list and think they get notified about all interactions on JIRA, only
> to notice several days later that it only includes notifications about
> new issues. This behavior can be configured easily enough in email
> clients.
> 
> --
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
 
>> -- 
>> Regards,
>> 
>> Atri
>> Apache Concerted

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Tomás Fernández Löbbe

Welcome, Atri!

On Wed, Sep 18, 2019 at 10:05 AM Steve Rowe  wrote:

> Congrats and welcome, Atri!
>
> --
> Steve
>
> > On Sep 18, 2019, at 3:11 AM, Adrien Grand  wrote:
> >
> > Hi all,
> >
> > Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
> >
> > If you are following activity on Lucene, this name will likely sound
> > familiar to you: Atri has been very busy trying to improve Lucene over
> > the past months. In particular, Atri recently started improving our
> > top-hits optimizations like early termination on sorted indexes and
> > WAND, when indexes are searched using multiple threads.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio.
> >
> > --
> > Adrien
> >
> > -
> > 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: [POLL] Should notifications of NEW Jira issues go to dev@?

2019-09-18 Thread Namgyu Kim

[x] A mail to dev@ for every new JIRA
[x] One daily digest mail per day with a list of new JIRAs

One of the two looks fine.
I think these methods seem possible to prevent missing new issues from the
issues@ folder.

On Thu, Sep 19, 2019 at 12:46 AM Atri Sharma  wrote:

> [v] leave it as it is — I like it quiet
>
> On Wed, 18 Sep 2019 at 19:42, Cassandra Targett 
> wrote:
>
>> [v ] Leave it as is - I like quiet
>>
>> I like the clear separation between the lists. It already feels less
>> hectic/overwhelming to me. I will read both as often as I can anyway, so I
>> don’t feel I’ll miss anything if the lists stay the way they are now.
>>
>> There is a Jira plugin to support email digest notifications. I know
>> nothing about it, just found it in a quick Google search for Jira
>> notifications. A custom bot might be a better solution, but thought I’d
>> point it out in case Infra would be willing to install it:
>> https://marketplace.atlassian.com/apps/1217383/email-notifications-digest?hosting=server=overview
>>
>> Thanks for working on these types of improvements!
>>
>> Cassandra
>> On Sep 18, 2019, 8:54 AM -0500, Jan Høydahl ,
>> wrote:
>>
>> Going for a daily digest bot we could clarify this in the email text:
>>
>> Here is a list of new Lucene/Solr issues created on -MM-DD
>>
>> LUCENE-NNN  Nice new feature
>> SOLR-NNNUnfortunate bug
>>
>> To get updates for these issues in the future, watch them in JIRA.
>> To get updates for all issues, subscribe to the issues@ mailing list.
>>
>>
>> 18. sep. 2019 kl. 15:34 skrev Adrien Grand :
>>
>> [x] Leave it as is - I like quiet
>>
>> It's not that much that I like quiet, but rather that I can easily
>> imagine it become confusing over time as new contributors join the
>> list and think they get notified about all interactions on JIRA, only
>> to notice several days later that it only includes notifications about
>> new issues. This behavior can be configured easily enough in email
>> clients.
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>>
>>
>> --
> Regards,
>
> Atri
> Apache Concerted
>

Re: Notes from the committers' meeting at Activate 2019

2019-09-18 Thread Chris Hostetter



: ASF has us legally covered, and from the foundation's side, GitHub 
: issues is equal to JIRA issues and GitHub PRs are equal to patches in 
: JIRA.

: > People that wish to continue using their Apache committer accounts to 
: commit code may continue doing so on gitbox.apache.org with their Apache 
: credentials. Nothing has changed in that respect.

: So the argument against TOS or personal M$ dislikes or principles won't hold 
here.
: 
: We can continue accepting JIRA issues, patches and commits to GitBox for 
: those who favor those tools for any reason. But we can equally well 
: embrace the entire GitHub tooling which was made available to us by ASF 

Ok -- everybody chill for a second.

I made a specific comment regarding github TOS/access in response to a 
*very* specific suggestion.

As a refresher, the specific suggestion i was responding to was this...

: > : Is there any reason at all that we need to hold on to JIRA? ASF allows 
: > : us to move all issue handling over to GH, I'd like us to consider such a 
: > : move.
: > 
: > In my opinion, migrating from JIRA to Github "issues" would be a terrible 
: > idea.

...that's it. *replacing* JIRA with github-issues is the specific idea i 
was saying was terrible.

Arguments that the code is still safe, and that committers who don't trust 
github can still push directly to gitbox w/o needing to accept 3rd party 
TOS; and that patches in github PRs are just as legally valid as patches 
in Jira are all fine -- but completely irrelevant to my comment.

Likewise: Arguments that people who don't agree to github TOS, or can't 
access github could still be contribute via JIRA make zero sense in the 
specific hypothetical scenerio i was replying to where JIRA no longer 
exists.


As i said before: if folks want to encourage and facilitate more direct 
integration and contributions & reviews via github -- using whatever weird 
ass github workflows or integrations or "hooks" or whatnot that github 
offers -- then cool, go for it, i'm all in favor of opening those doors 
(evne if i don't plan on using them much).

what i objected to was *closing* a door (again: specificly, migrating off 
of JIRA completely) that is currently open to anyone and saying it's not 
neccessary because we've open a new door that comes with a lot of 
restrictions and baggage.

: > I have no objections to the goal of "encouraging" and "facilitating" 
: > contributions via github from people already using github -- but making 
: > github the defacto (or *sole*) way to participate and contribute code 
: > means pressuring people into accepting the github TOS (not just 
: > now, but whatever those might be in the future) as well as making it 
: > virtually impossible for people to participate if they are in locations 
: > github has decided to block (ie: Iran, Syria, and Crimea ATM + whomever 
: > else the US decides to sanction down the road)
: > 
: > Opening up, or expanding, pathways for participation is one thing -- 
: > I'm all in favor of that (even if I personally can't stand those avenues).
: > 
: > But *closing* existing path ways that are currently entirely "open" and 
: > "free" to anyone that wants to participate w/o any limitations or TOS 
: > other then "Provide an ASF controled and owned website with an email 
: > address" ... that's just sad.


-Hoss
http://www.lucidworks.com/

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

Re: Rethinking how we publish the Solr Ref Guide

2019-09-18 Thread Chris Hostetter



First and foremost I should mention: I'm currently in favor of just about 
everything Cassandra has suggested here...

: So, I propose making some radical changes. My ideas here require a shift
: from thinking of the Guide as a release artifact like the binaries to
: thinking of it similar to how we treat javadocs. These ideas also allow us

I would actually go farther then that, and suggest that moving forward the 
"official ref-guide" for "Solr X.Y" (hosted on lucene.apache.org) 
automatically be updated anytime anyone pushes edits to brach_X_Y -- as 
opposed to our javadocs for X.Y.0 which *might* be rebuilt for formatting 
purposes (something we've done in the past) but no *code* (ie: "content") 
changes on branch_X_Y would be reflected ... those would be part of the 
"bug fix" release X.Y.1, which would have it's own javadocs.  But 
meanwhile, the ref-guide for X.Y could/would be updated with doc 
improvements even if there were no bug-fix releases from branch_X_Y.


: -- By ASF policy, release artifacts must be produced on a machine
: controlled by the committer. However, the point here is that the Ref Guide
: would no longer be a release artifact, so I think that gets us around that
: rule? If anyone sees this differently that would change things here a
: little bit.

FWIW: My understand from years ago was that the policy was unambiguious:
 1) a release vote is neccessary for anything that goes on dist.apache.org
 2) any "downloads" should come from dist.apache.org
...so "browseable html" docs on lucene.apache.org wouldn't require a 
VOTE, but if we want to keep providing a provide a big PDF or zip file of 
all the HTML that would require a vote -- *BUT* it seems like the rules 
are more ambiguious now, particularly regarding "documentation" downloads 
... ex: i know openoffice provides downloadable PDFs of their user guide 
from their wiki, pretty sure they don't vote on that.



: PS, As for the PDF, I believe there are mixed opinions about it. Some rely

As someone who has been a long time advocate of the PDF, and of treating 
it as an "official (VOTEed) release artifact" i wanted to toss out some 
historical context, and notes on how/why my own feelings have evolved.

Once upon a time, Solr had shit-all user documentation.  We had nothing 
but our (moin moin) wiki, which was a hodge-podge mess, an amalgmaation 
mix of docs written by developers as features were created, and "tips" 
pages written by users with thoughts on how to do things, and none of it 
was well organized and all of it was sprinkled with "this feature 
was added in version X.Y but changed defaults to FOO in version X.Z..."

When the lucidworks created the first few versions of the ref-guide using 
Confluence as a CMS, and donated it to the ASF, i (and others) really felt 
it was important that end users could see this new material as official, 
authoritative, and "specific" (to each version of Solr) ... we did *NOT* 
want people to start thinking of it as "just another wiki".  Since 
confluence didn't have an easy way to "branch" the entire space for 
each version (not w/o a lot of infra assistance) and *did* provide an easy 
way to publish the entire guide as a PDF, doing that and voting on the 
resulting PDF as a true "documentation release artifact" seemed like a 
good way to ensure we not only had version specific "snapshots" of the 
content, but gave these PDFs more "legtimacy" as being "official".

When we migrated to using asciidoctor, i (and others?) really felt like it 
was important to keep the continuity of having an "official PDF release 
artifact" since that was what our users were use to to ensure they were 
looking a the "correct" ref-guide version.  (With the old confluence CMS, 
the only "browseable" html view of the content corrisponded to the latest 
branch_YYY_x, with a handful of pages for trunk only features).  But of 
course: being able to branch the ref-guide source alongwith the code, and 
being able to build & host browseable HTML pages for all the content was a 
really nice value add.

The project, our documentation, and the communities views/experience with 
our documetation aren't the same as they were 6+ years ago.  As already 
mentioned by a few people: it seems like most users browse/read the 
(version specific) ref-guide hosted on lucene.apache.org.  The handful of 
users who really care about "offline" access to the content on their 
laptops can probably build the HTML site locally from source just as 
easily as they can downloda the PDF.

So while My 2013 self, and my 2015 self, and even my 2017 self would have 
been really adament about having an "official voted (PDF) release 
artifact" for the ref-guide ... my 2019 self realizes that the world has 
changed, and we're just making more work for ourselves -- at an 
opportunity cost of having an "official" (hosted) version of the ref-guide 
with more accurate "post release" doc fixes and more dynamic presentation 
features that just aren't

Re: Rethinking how we publish the Solr Ref Guide

2019-09-18 Thread Anshum Gupta

Thank you Cassandra for all of your effort so far.

I just love that idea. As I said in my previous email (based on my
discussion with Cassandra at Activate), having 2 processes, releases, one
of which almost the responsibility of one person doesn't sound reasonable.
It would also be great to get more people to vote for both, the code and
ref guide instead of just a few people voting for the ref guide.

About updating the ref guide post-release, I think that should be limited
to trivial typos, formatting changes only. Anything else would mean that
people wouldn't know when something in the documentation changed as it
would not come with an announce email.

I don't know much about the ref guide release process so I'm not sure how
much effort it would take for this change but I think the effort would
certainly be more than worth it in the long term.

On Wed, Sep 18, 2019 at 9:07 AM Cassandra Targett 
wrote:

> The delays getting the Ref Guides for 8.x releases out have caused me to
> think a bit about the Ref Guide publication process. It seems clear others
> aren't able to pick up the process when I can't and I’m sure there are a
> million individual reasons for that so I don't intend to shame or blame
> anyone, but a process that relies on a single person in a community our
> size isn’t a very good one. And, if I think about _why_ we have a process
> like we have today [1], I’m not sure it makes a ton of sense any longer.
>
> So, I propose making some radical changes. My ideas here require a shift
> from thinking of the Guide as a release artifact like the binaries to
> thinking of it similar to how we treat javadocs. These ideas also allow us
> to finally get to the goal of unifying these currently separate processes.
>
> 1. Make the HTML version the “official” version.
> -- What to do with the PDF is TBD after that decision, see below.
>
> 2. Stop voting for the Ref Guide release as a separate VOTE thread.
>
> 3. Jenkins jobs are already created when a release branch is cut. We can
> change these jobs so they always automatically push the HTML version to the
> website, although before the version binaries are released the pages would
> still have a DRAFT watermark across them [2].
> -- By ASF policy, release artifacts must be produced on a machine
> controlled by the committer. However, the point here is that the Ref Guide
> would no longer be a release artifact, so I think that gets us around that
> rule? If anyone sees this differently that would change things here a
> little bit.
> -- I know other projects have similar Jenkins->publish workflows, but I’m
> not sure exactly what’s involved in setting it up. Might need to discuss
> with the Infra team and other changes may be required depending.
> -- The goal, though, is to automate this as much as possible.
>
> 4. When a VOTE has passed, a simple step could be added to the release
> process to run a Jenkins job to regenerate the HTML pages without the
> current DRAFT watermark and automatically push them to the production
> website.
> -- Since we usually leave branch jobs configured-but-disabled for a little
> bit in case a patch release is necessary, typos or other things fixed
> “post-release" could be fixed and the Ref Guide Jenkins job would just push
> new commits to the branch to the live production site.
> -- These updates would be done without the DRAFT status, since the Ref
> Guide in that branch is now considered “live”.
> -- This part of the idea would allow us to more easily backport any docs
> changes and re-publish the Guide without having to do a new vote, which we
> would need today. This might be rare, but it is a question that comes up
> from time-to-time. I feel that if the publication process was easier, we
> might fix things retroactively more often.
>
> 5. Some tooling would be nice to automate parts of the copy edit process
> I do today, so it can be run by any committer at any point in the process.
> This can follow on later. I have a list.
>
> So, that's the idea in a nutshell - thoughts?
>
> [1] Current release process:
> https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
> [2] Example of DRAFT watermark (it's all CSS, it could look however we
> want it to):
> https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-8.x/javadoc/
>
> PS, As for the PDF, I believe there are mixed opinions about it. Some rely
> on it, others only use it when they need it (portability, easier to search,
> etc.), others don’t ever look at it. The fact is it’s over 1600 pages, and
> that’s just really too big. Joel is about to add a significant number of
> new images as part of a new "visual" guide (see SOLR-13105), which will
> make it even longer and bigger. Trying to split it to make it smaller
> would bring in a lot of complexity with how to deal with links between
> pages that end up in different PDF files (believe me, I've done it before).
> And finally, it holds us back a little - some

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Steve Rowe

Congrats and welcome, Atri!

--
Steve

> On Sep 18, 2019, at 3:11 AM, Adrien Grand  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
> 
> If you are following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
> 
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
> 
> -- 
> Adrien
> 
> -
> 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: Rethinking how we publish the Solr Ref Guide

+1 to automate... I never use the PDF I'd be happy to loose it. The page
count is the best part of the PDF :).

As far as indexing the ref guide... Cassandra gave a talk on that last
year...
https://www.youtube.com/watch?v=DixlnxAk08s=PLU6n9Voqu_1HW8-VavVMa9lP8-oF8Oh5t=14

On Wed, Sep 18, 2019 at 12:19 PM Alexandre Rafalovitch 
wrote:

> +1 on the suggested process. +1 on PDF just being too big, though it
> is fun to quote the page count.
>
> An additional idea piggy-backing on this is that in step 4, we could
> also automatically build a local example/index that links to the
> public version. So, people could search the guide locally and that
> would link to the known public URLs for the real HTML.
>
> Regards,
>Alex.
>
> On Wed, 18 Sep 2019 at 12:07, Cassandra Targett 
> wrote:
> >
> > The delays getting the Ref Guides for 8.x releases out have caused me to
> think a bit about the Ref Guide publication process. It seems clear others
> aren't able to pick up the process when I can't and I’m sure there are a
> million individual reasons for that so I don't intend to shame or blame
> anyone, but a process that relies on a single person in a community our
> size isn’t a very good one. And, if I think about _why_ we have a process
> like we have today [1], I’m not sure it makes a ton of sense any longer.
> >
> > So, I propose making some radical changes. My ideas here require a shift
> from thinking of the Guide as a release artifact like the binaries to
> thinking of it similar to how we treat javadocs. These ideas also allow us
> to finally get to the goal of unifying these currently separate processes.
> >
> > 1. Make the HTML version the “official” version.
> > -- What to do with the PDF is TBD after that decision, see below.
> >
> > 2. Stop voting for the Ref Guide release as a separate VOTE thread.
> >
> > 3. Jenkins jobs are already created when a release branch is cut. We can
> change these jobs so they always automatically push the HTML version to the
> website, although before the version binaries are released the pages would
> still have a DRAFT watermark across them [2].
> > -- By ASF policy, release artifacts must be produced on a machine
> controlled by the committer. However, the point here is that the Ref Guide
> would no longer be a release artifact, so I think that gets us around that
> rule? If anyone sees this differently that would change things here a
> little bit.
> > -- I know other projects have similar Jenkins->publish workflows, but
> I’m not sure exactly what’s involved in setting it up. Might need to
> discuss with the Infra team and other changes may be required depending.
> > -- The goal, though, is to automate this as much as possible.
> >
> > 4. When a VOTE has passed, a simple step could be added to the release
> process to run a Jenkins job to regenerate the HTML pages without the
> current DRAFT watermark and automatically push them to the production
> website.
> > -- Since we usually leave branch jobs configured-but-disabled for a
> little bit in case a patch release is necessary, typos or other things
> fixed “post-release" could be fixed and the Ref Guide Jenkins job would
> just push new commits to the branch to the live production site.
> > -- These updates would be done without the DRAFT status, since the Ref
> Guide in that branch is now considered “live”.
> > -- This part of the idea would allow us to more easily backport any docs
> changes and re-publish the Guide without having to do a new vote, which we
> would need today. This might be rare, but it is a question that comes up
> from time-to-time. I feel that if the publication process was easier, we
> might fix things retroactively more often.
> >
> > 5. Some tooling would be nice to automate parts of the copy edit process
> I do today, so it can be run by any committer at any point in the process.
> This can follow on later. I have a list.
> >
> > So, that's the idea in a nutshell - thoughts?
> >
> > [1] Current release process:
> https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
> > [2] Example of DRAFT watermark (it's all CSS, it could look however we
> want it to):
> https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-8.x/javadoc/
> >
> > PS, As for the PDF, I believe there are mixed opinions about it. Some
> rely on it, others only use it when they need it (portability, easier to
> search, etc.), others don’t ever look at it. The fact is it’s over 1600
> pages, and that’s just really too big. Joel is about to add a significant
> number of new images as part of a new "visual" guide (see SOLR-13105),
> which will make it even longer and bigger. Trying to split it to make it
> smaller would bring in a lot of complexity with how to deal with links
> between pages that end up in different PDF files (believe me, I've done it
> before). And finally, it holds us back a little - some things we could do
> with HTML/JS can't be done in PDF. I’d be fine

Re: Rethinking how we publish the Solr Ref Guide

2019-09-18 Thread Alexandre Rafalovitch

+1 on the suggested process. +1 on PDF just being too big, though it
is fun to quote the page count.

An additional idea piggy-backing on this is that in step 4, we could
also automatically build a local example/index that links to the
public version. So, people could search the guide locally and that
would link to the known public URLs for the real HTML.

Regards,
   Alex.

On Wed, 18 Sep 2019 at 12:07, Cassandra Targett  wrote:
>
> The delays getting the Ref Guides for 8.x releases out have caused me to 
> think a bit about the Ref Guide publication process. It seems clear others 
> aren't able to pick up the process when I can't and I’m sure there are a 
> million individual reasons for that so I don't intend to shame or blame 
> anyone, but a process that relies on a single person in a community our size 
> isn’t a very good one. And, if I think about _why_ we have a process like we 
> have today [1], I’m not sure it makes a ton of sense any longer.
>
> So, I propose making some radical changes. My ideas here require a shift from 
> thinking of the Guide as a release artifact like the binaries to thinking of 
> it similar to how we treat javadocs. These ideas also allow us to finally get 
> to the goal of unifying these currently separate processes.
>
> 1. Make the HTML version the “official” version.
> -- What to do with the PDF is TBD after that decision, see below.
>
> 2. Stop voting for the Ref Guide release as a separate VOTE thread.
>
> 3. Jenkins jobs are already created when a release branch is cut. We can 
> change these jobs so they always automatically push the HTML version to the 
> website, although before the version binaries are released the pages would 
> still have a DRAFT watermark across them [2].
> -- By ASF policy, release artifacts must be produced on a machine controlled 
> by the committer. However, the point here is that the Ref Guide would no 
> longer be a release artifact, so I think that gets us around that rule? If 
> anyone sees this differently that would change things here a little bit.
> -- I know other projects have similar Jenkins->publish workflows, but I’m not 
> sure exactly what’s involved in setting it up. Might need to discuss with the 
> Infra team and other changes may be required depending.
> -- The goal, though, is to automate this as much as possible.
>
> 4. When a VOTE has passed, a simple step could be added to the release 
> process to run a Jenkins job to regenerate the HTML pages without the current 
> DRAFT watermark and automatically push them to the production website.
> -- Since we usually leave branch jobs configured-but-disabled for a little 
> bit in case a patch release is necessary, typos or other things fixed 
> “post-release" could be fixed and the Ref Guide Jenkins job would just push 
> new commits to the branch to the live production site.
> -- These updates would be done without the DRAFT status, since the Ref Guide 
> in that branch is now considered “live”.
> -- This part of the idea would allow us to more easily backport any docs 
> changes and re-publish the Guide without having to do a new vote, which we 
> would need today. This might be rare, but it is a question that comes up from 
> time-to-time. I feel that if the publication process was easier, we might fix 
> things retroactively more often.
>
> 5. Some tooling would be nice to automate parts of the copy edit process I do 
> today, so it can be run by any committer at any point in the process. This 
> can follow on later. I have a list.
>
> So, that's the idea in a nutshell - thoughts?
>
> [1] Current release process: 
> https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
> [2] Example of DRAFT watermark (it's all CSS, it could look however we want 
> it to): 
> https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-8.x/javadoc/
>
> PS, As for the PDF, I believe there are mixed opinions about it. Some rely on 
> it, others only use it when they need it (portability, easier to search, 
> etc.), others don’t ever look at it. The fact is it’s over 1600 pages, and 
> that’s just really too big. Joel is about to add a significant number of new 
> images as part of a new "visual" guide (see SOLR-13105), which will make it 
> even longer and bigger. Trying to split it to make it smaller would bring in 
> a lot of complexity with how to deal with links between pages that end up in 
> different PDF files (believe me, I've done it before). And finally, it holds 
> us back a little - some things we could do with HTML/JS can't be done in PDF. 
> I’d be fine continuing to produce it, just not as our main artifact. We could 
> have Jenkins push that also to the SVN dist/dev repo where it currently lives.
>
> Cassandra
>

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

Rethinking how we publish the Solr Ref Guide

2019-09-18 Thread Cassandra Targett

The delays getting the Ref Guides for 8.x releases out have caused me to
think a bit about the Ref Guide publication process. It seems clear others
aren't able to pick up the process when I can't and I’m sure there are a
million individual reasons for that so I don't intend to shame or blame
anyone, but a process that relies on a single person in a community our
size isn’t a very good one. And, if I think about _why_ we have a process
like we have today [1], I’m not sure it makes a ton of sense any longer.

So, I propose making some radical changes. My ideas here require a shift
from thinking of the Guide as a release artifact like the binaries to
thinking of it similar to how we treat javadocs. These ideas also allow us
to finally get to the goal of unifying these currently separate processes.

1. Make the HTML version the “official” version.
-- What to do with the PDF is TBD after that decision, see below.

2. Stop voting for the Ref Guide release as a separate VOTE thread.

3. Jenkins jobs are already created when a release branch is cut. We can
change these jobs so they always automatically push the HTML version to the
website, although before the version binaries are released the pages would
still have a DRAFT watermark across them [2].
-- By ASF policy, release artifacts must be produced on a machine
controlled by the committer. However, the point here is that the Ref Guide
would no longer be a release artifact, so I think that gets us around that
rule? If anyone sees this differently that would change things here a
little bit.
-- I know other projects have similar Jenkins->publish workflows, but I’m
not sure exactly what’s involved in setting it up. Might need to discuss
with the Infra team and other changes may be required depending.
-- The goal, though, is to automate this as much as possible.

4. When a VOTE has passed, a simple step could be added to the release
process to run a Jenkins job to regenerate the HTML pages without the
current DRAFT watermark and automatically push them to the production
website.
-- Since we usually leave branch jobs configured-but-disabled for a little
bit in case a patch release is necessary, typos or other things fixed
“post-release" could be fixed and the Ref Guide Jenkins job would just push
new commits to the branch to the live production site.
-- These updates would be done without the DRAFT status, since the Ref
Guide in that branch is now considered “live”.
-- This part of the idea would allow us to more easily backport any docs
changes and re-publish the Guide without having to do a new vote, which we
would need today. This might be rare, but it is a question that comes up
from time-to-time. I feel that if the publication process was easier, we
might fix things retroactively more often.

5. Some tooling would be nice to automate parts of the copy edit process I
do today, so it can be run by any committer at any point in the process.
This can follow on later. I have a list.

So, that's the idea in a nutshell - thoughts?

[1] Current release process:
https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
[2] Example of DRAFT watermark (it's all CSS, it could look however we want
it to):
https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-8.x/javadoc/

PS, As for the PDF, I believe there are mixed opinions about it. Some rely
on it, others only use it when they need it (portability, easier to search,
etc.), others don’t ever look at it. The fact is it’s over 1600 pages, and
that’s just really too big. Joel is about to add a significant number of
new images as part of a new "visual" guide (see SOLR-13105), which will
make it even longer and bigger. Trying to split it to make it smaller would
bring in a lot of complexity with how to deal with links between pages that
end up in different PDF files (believe me, I've done it before). And
finally, it holds us back a little - some things we could do with HTML/JS
can't be done in PDF. I’d be fine continuing to produce it, just not as our
main artifact. We could have Jenkins push that also to the SVN dist/dev
repo where it currently lives.

Cassandra

Re: Direct I/O

Ahh yes sorry you are right Dawid and Uwe.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Sep 18, 2019 at 10:11 AM Uwe Schindler  wrote:

> The direct io has in fact the problem which was just wrongly named by
> Dawid: Block alignment is needed - on disk and not in memory. In short: You
> can't read or write a single byte anywhere in file; you need a buffering
> layer in-between that takes care of alignment. NativeUnixDir does this.
>
> Uwe
>
> Am September 18, 2019 1:54:35 PM UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
>>
>> Thanks for the explanation, Mike!
>>
>> D.
>>
>> On Wed, Sep 18, 2019 at 3:21 PM Michael McCandless
>>  wrote:
>>
>>>
>>>  Dawid, it's confusing: direct IO is different from a direct ByteBuffer!
>>>
>>>  Direct IO means you bypass all kernel "smarts", so the Linux buffer cache 
>>> is not used, no IO scheduling, no write cache that the pdflush daemon must 
>>> periodically move to disk, etc.  This is normally a bad idea, and better to 
>>> use fadvise/madvise to give kernel hints about what you are doing, and use 
>>> the buffer cache for what it's good at.  Linus hates that direct IO is even 
>>> an option for us ...
>>>
>>>  Back when I wrote NativeUnixDirectory, the idea was to prevent ongoing 
>>> merges from so heavily impacting ongoing searches, when you are doing 
>>> indexing and searching on one node.  We open the newly merged segments 
>>> files using direct IO, and do our own buffering, and then all writes go 
>>> straight to disk instead of using up precious hot pages that are in use for 
>>> searching.  I think I ran some simple performance tests back then but I 
>>> don't remember the results ... more testing is needed to see if it really 
>>> helps.
>>>
>>>  At Amazon, we are using segment based replication ever 60 seconds to copy 
>>> newly indexed segments out to all searchers, so we never have nodes doing 
>>> both indexing or searching, it's either or ... but, copying out max sized 
>>> newly merged segments to the searchers is causing some thrashing so we are 
>>> exploring using direct IO for those writes, and then separately warming the 
>>> new segments after the copy.
>>>
>>>  Mike McCandless
>>>
>>>  http://blog.mikemccandless.com
>>>
>>>
>>>  On Tue, Sep 17, 2019 at 1:16 PM Uwe Schindler  wrote:
>>>

  We discussed this already on Berlinbuzzwords (Mike and Michael). Yes it's 
 possible and may work for merges where block io is possible. But most of 
 us said: it's fine to not use io cache for merging, but it won't make 
 pages hot. So merges are invisible to OS, so you have to warm merged 
 segments if you write directly. If you read directly on merging, you won't 
 pollute cache with one time reads, but it also won't use cache if already 
 cached.
  We should better make a proposal for f/madvise. The jdk people are open 
 for that, and I am jdk committer now, so I can make a prototype.

  Uwe

  Am September 17, 2019 4:48:26 PM UTC schrieb Dawid Weiss 
 :

>
>  Isn't that restricted to aligned block-only access though? I can
>  imagine this would complicate the implementation if somebody wanted to
>  use it directly.
>
>  Dawid
>
>  On Tue, Sep 17, 2019 at 5:37 PM Michael McCandless
>   wrote:
>
>>
>>
>>   Whoa!  That would be awesome -- no more JNI to use Direct I/O?
>>   Looks like you use it like this:
>>
>>   FileChannel fc = FileChannel.open(p, StandardOpenOption.WRITE,
>> ExtendedOpenOption.DIRECT
>>
>>   But it looks like you need to enable the jdk.unsupported module, added 
>> with http://openjdk.java.net/jeps/260
>>
>>   Mike McCandless
>>
>>   http://blog.mikemccandless.com
>>
>>
>>   On Mon, Sep 16, 2019 at 11:55 AM Michael Sokolov  
>> wrote:
>>
>>>
>>>
>>>   https://bugs.openjdk.java.net/browse/JDK-8189192 makes it appear that
>>>   Direct I/O is (or may be?) available now in JDK's since JDK10. Should
>>>   we try using that API in NativeUnixDirectory in order to avoid JNI
>>>   calls?
>>> --
>>>   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
>
>
  --
  Uwe Schindler
  Achterdiek 19, 28357 Bremen
  https://www.thetaphi.de

>>> --
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Karl Wright

Welcome!
Karl

On Wed, Sep 18, 2019 at 11:38 AM Namgyu Kim  wrote:

> Congratulations and welcome, Atri! XD
>
> 2019년 9월 19일 (목) 오전 12:24, Gus Heck 님이 작성:
>
>> Welcome :)
>>
>> On Wed, Sep 18, 2019 at 11:21 AM Kevin Risden  wrote:
>>
>>> Congrats and welcome Atri!
>>>
>>> Kevin Risden
>>>
>>>
>>> On Wed, Sep 18, 2019 at 11:05 AM Yonik Seeley  wrote:
>>>
 Congrats Atri!

 -Yonik


 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 following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

2019-09-18 Thread Atri Sharma

[v] leave it as it is — I like it quiet

On Wed, 18 Sep 2019 at 19:42, Cassandra Targett 
wrote:

> [v ] Leave it as is - I like quiet
>
> I like the clear separation between the lists. It already feels less
> hectic/overwhelming to me. I will read both as often as I can anyway, so I
> don’t feel I’ll miss anything if the lists stay the way they are now.
>
> There is a Jira plugin to support email digest notifications. I know
> nothing about it, just found it in a quick Google search for Jira
> notifications. A custom bot might be a better solution, but thought I’d
> point it out in case Infra would be willing to install it:
> https://marketplace.atlassian.com/apps/1217383/email-notifications-digest?hosting=server=overview
>
> Thanks for working on these types of improvements!
>
> Cassandra
> On Sep 18, 2019, 8:54 AM -0500, Jan Høydahl ,
> wrote:
>
> Going for a daily digest bot we could clarify this in the email text:
>
> Here is a list of new Lucene/Solr issues created on -MM-DD
>
> LUCENE-NNN  Nice new feature
> SOLR-NNNUnfortunate bug
>
> To get updates for these issues in the future, watch them in JIRA.
> To get updates for all issues, subscribe to the issues@ mailing list.
>
>
> 18. sep. 2019 kl. 15:34 skrev Adrien Grand :
>
> [x] Leave it as is - I like quiet
>
> It's not that much that I like quiet, but rather that I can easily
> imagine it become confusing over time as new contributors join the
> list and think they get notified about all interactions on JIRA, only
> to notice several days later that it only includes notifications about
> new issues. This behavior can be configured easily enough in email
> clients.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
>
>
> --
Regards,

Atri
Apache Concerted

Re: The Lucene Solr Gradle Build Game plan

2019-09-18 Thread Dawid Weiss

I've been eyeballing Mark's impressive work on the build system in
Gradle. Hoss asked a
numer of questions that relate to tests and I feel I should address
them, even if some poorly. Here it comes, inlined with Hoss's
questions.

> If tests_jvms is a lucene/solr specific property, that needs to be in a users 
> "multi-project" "~/.gradle" file

Yeah... I'm not at all a fan of modifying the global gradle settings
file. While it may be ok for settings that only apply to Lucene (if
prefixed) there are other things like enabling or disabling the daemon
which should be a matter of project-local settings. Ideally, I'd like
to see something like:

checkout/gradle-defaults.properties [versioned]
checkout/gradle-local.properties [developer-tweaks, not versioned]

but short of declaring a custom "user home" for gradle (-g switch) I
don't see how this can be achieved. Perhaps the initial checkout could
not carry gradle.properties at all and the build would require an
initial setup via Mark's "defaultUserConfig". This could then write
(unversioned!) gradle.properties with the selected defaults within the
checkout folder (so there'd be no need to tweak the global file).
People can then tweak it to their liking or call defaultUserConfig
with appropriate options again to overwrite the changes.

> How do we get "reproduce with" type output (by default) when a test fails?

This should be doable -- we do it from Ant after all. You can pass
properties to gradle via "-P" so this can be used in the same way we
pass them to ant. In fact, it already works:

gradlew :lucene:lucene-core:test --tests TestDemo -Ptests.seed=deadbeef

> For that matter, how do we get *all* of the logging from failed tests to be 
> written to stdout/stderr when a test fail?

There probably is an API in gradle to do this. I know Ryan wrote a
runner for Elastic a long time ago so there may be even code to look
at. I agree it is quite important to get this to work, especially for
CI logs.

> What's the plan as far as things like "ant beast", "-Dtests.dups", 
> "-Dtests.iters" & "-Dtests.jvms" ?

Reiteration (tests.iters) is part of the test runner so it'd already
work if that property was passed to it (via -P). It isn't at the
moment -- I'll work on it.

As for tests.dups and tests.jvms this will have to be emulated somehow
at Gradle level. Don't know how though. I'm sure there'll be ways --
this is essentially a programming language.

> ("-Dtests.jvms=1" is important for figuring out if/how the execution of one 
> test might polute static variables in the JVM

I don't think it'll work even if you have one JVM unless Gradle test
runner's order is deterministic... which I'm not sure it is, even with
a single JVM that runs the tests.

> is there a simple option to prevent gradle from using curses even though it 
> detects it's being run in a tty?

You can pass --console=plain to gradle, use -Dorg.gradle.console=plain
or specify this property in any other way (via environment variable,
etc.). See here:

https://docs.gradle.org/current/userguide/build_environment.html

Dawid

On Mon, Sep 16, 2019 at 8:59 PM Chris Hostetter
 wrote:
>
>
> Some misc questions after playing around with gradle on this branch for a
> bit today in no particular order...
>
> : tests_jvms=5
> ...
> : test_jvms is controlled by us and defaults to the number of cores detected
> : / 2.
>
> If tests_jvms is a lucene/solr specific property, that needs to
> be in a users "multi-project" "~/.gradle" file ... shouldn't we name it
> namespace it with something like "lucene_solr_test_jvms" to make that
> clear reduce future confusion/collsion?  (as i anticipate this wo't be the
> last prop we may need)
>
> How do we get "reproduce with" type output (by default) when a test fails?
>
> For that matter, how do we get *all* of the logging from failed tests to
> be written to stdout/stderr when a test fail?  ... this is pretty
> important for making jenkin's console log a good "one stop shop" for
> understanding everything that went wrong in a build.
>
> ("--debug" and "--info" seem to do this, but they write a *TON* more
> gradle specific shit then "ant test" type logging use to produce by
> default, and don't care if the test passes or not ... which would make
> them way too excessively verbose for a jenkins build)
>
> What's the plan as far as things like "ant beast", "-Dtests.dups",
> "-Dtests.iters" & "-Dtests.jvms" ? ... those types of options are all
> pretty critical for diagnosing and troubleshooting failures.
> ("-Dtests.jvms=1" is important for figuring out if/how the execution of
> one test might polute static variables in the JVM that cause a failure in
> a subsequent class in the sane JVM)
>
> is there a simple option to prevent gradle from using curses even though
> it detects it's being run in a tty?
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Namgyu Kim

Congratulations and welcome, Atri! XD

2019년 9월 19일 (목) 오전 12:24, Gus Heck 님이 작성:

> Welcome :)
>
> On Wed, Sep 18, 2019 at 11:21 AM Kevin Risden  wrote:
>
>> Congrats and welcome Atri!
>>
>> Kevin Risden
>>
>>
>> On Wed, Sep 18, 2019 at 11:05 AM Yonik Seeley  wrote:
>>
>>> Congrats Atri!
>>>
>>> -Yonik
>>>
>>>
>>> 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 following activity on Lucene, this name will likely sound
 familiar to you: Atri has been very busy trying to improve Lucene over
 the past months. In particular, Atri recently started improving our
 top-hits optimizations like early termination on sorted indexes and
 WAND, when indexes are searched using multiple threads.

 Congratulations and welcome! It is a tradition to introduce yourself
 with a brief bio.

 --
 Adrien

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

>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Re: 8.3 release

2019-09-18 Thread Cassandra Targett

As I’ve mentioned to some of you over the past couple of weeks, I want to 
propose that we don’t “release” the Ref Guide at all the way we have been doing 
it.

It deserves a separate thread, which since it’s come up a few times this week I 
should start now, but in essence, my idea is to no longer treat the PDF as a 
release artifact that requires a vote, and publish the HTML as our primary 
version of the Ref Guide in effectively the same way we publish the javadocs 
(at the same time as the binary artifacts).

Instead of highjacking this thread with that discussion since it has several 
aspects, let me send another mail on it where I can flesh it out more and we 
can discuss there. I have the mail mostly queued up and ready to go already.

Cassandra
On Sep 18, 2019, 10:23 AM -0500, Gus Heck , wrote:
> I learned recently that it's actually all  documented here: 
> https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
>
> > On Tue, Sep 17, 2019 at 7:31 PM Ishan Chattopadhyaya 
> >  wrote:
> > > Hi Adrien,
> > > Indeed, meant to write about starting a vote.
> > >
> > > @Gus, I'll have to let Cassandra weigh in on this one as I'm not very 
> > > familiar with the ref guide release process.
> > >
> > > Regards,
> > > Ishan
> > >
> > > > On Mon, 16 Sep, 2019, 7:28 PM Adrien Grand,  wrote:
> > > > > +1 to start working on 8.3
> > > > >
> > > > > Did you mean "start a vote" when you wrote "release the artifacts"? It
> > > > > got me wondering because I don't think we frequently managed to go
> > > > > from cutting a branch to releasing artifacts in so little time in the
> > > > > past.
> > > > >
> > > > > On Mon, Sep 16, 2019 at 5:52 PM Ishan Chattopadhyaya
> > > > >  wrote:
> > > > > >
> > > > > > Hi all,
> > > > > > We have a lot of unreleased features and fixes. I propose that we 
> > > > > > cut
> > > > > > a 8.3 branch in two weeks (in order to have sufficient time to bake 
> > > > > > in
> > > > > > all in-progress features). If there are no objections to doing so, I
> > > > > > can volunteer for the release as an RM and plan for cutting a 
> > > > > > release
> > > > > > branch on 30 September (and release the artifacts about 3-4 days 
> > > > > > after
> > > > > > that).
> > > > > >
> > > > > > WDYT?
> > > > > > Regards,
> > > > > > Ishan
> > > > > >
> > > > > > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Adrien
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > > >
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

[ ] Leave it as is - I like quiet
[x] A mail to dev@ for every new JIRA
[x] One daily digest mail per day with a list of new JIRAs
[ ] Other (explain): ___

On Wed, Sep 18, 2019 at 5:10 AM Jan Høydahl  wrote:

> Hi,
>
> The transition to issues@ and builds@ lists (LUCENE-8951) is now
> completed, and I already enjoy a quieter dev@ folder!
>
> I'd like to check with all of you whether there is interest in getting
> notified here at dev@ about NEW Jira issue created. Currently there is an
> average of 4 new issues per day. The main motivation for this would be for
> those who want to follow new development but not all the
> details/discussions. We could easily configure JIRA to send all [Created]
> mails to dev@ in addition to issues@. Or we could try to have one daily
> digest mail of new issues, whether that's a small bot or a feature in JIRA
> (don't know). Let's to a poll:
>
> [ ] Leave it as is - I like quiet
> [ ] A mail to dev@ for every new JIRA
> [ ] One daily digest mail per day with a list of new JIRAs
> [ ] Other (explain): ___
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Welcome Atri Sharma as Lucene/Solr committer

Welcome :)

On Wed, Sep 18, 2019 at 11:21 AM Kevin Risden  wrote:

> Congrats and welcome Atri!
>
> Kevin Risden
>
>
> On Wed, Sep 18, 2019 at 11:05 AM Yonik Seeley  wrote:
>
>> Congrats Atri!
>>
>> -Yonik
>>
>>
>> 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 following activity on Lucene, this name will likely sound
>>> familiar to you: Atri has been very busy trying to improve Lucene over
>>> the past months. In particular, Atri recently started improving our
>>> top-hits optimizations like early termination on sorted indexes and
>>> WAND, when indexes are searched using multiple threads.
>>>
>>> Congratulations and welcome! It is a tradition to introduce yourself
>>> with a brief bio.
>>>
>>> --
>>> Adrien
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: 8.3 release

I learned recently that it's actually all  documented here:
https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process

On Tue, Sep 17, 2019 at 7:31 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Hi Adrien,
> Indeed, meant to write about starting a vote.
>
> @Gus, I'll have to let Cassandra weigh in on this one as I'm not very
> familiar with the ref guide release process.
>
> Regards,
> Ishan
>
> On Mon, 16 Sep, 2019, 7:28 PM Adrien Grand,  wrote:
>
>> +1 to start working on 8.3
>>
>> Did you mean "start a vote" when you wrote "release the artifacts"? It
>> got me wondering because I don't think we frequently managed to go
>> from cutting a branch to releasing artifacts in so little time in the
>> past.
>>
>> On Mon, Sep 16, 2019 at 5:52 PM Ishan Chattopadhyaya
>>  wrote:
>> >
>> > Hi all,
>> > We have a lot of unreleased features and fixes. I propose that we cut
>> > a 8.3 branch in two weeks (in order to have sufficient time to bake in
>> > all in-progress features). If there are no objections to doing so, I
>> > can volunteer for the release as an RM and plan for cutting a release
>> > branch on 30 September (and release the artifacts about 3-4 days after
>> > that).
>> >
>> > WDYT?
>> > Regards,
>> > Ishan
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Kevin Risden

Congrats and welcome Atri!

Kevin Risden


On Wed, Sep 18, 2019 at 11:05 AM Yonik Seeley  wrote:

> Congrats Atri!
>
> -Yonik
>
>
> 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 following activity on Lucene, this name will likely sound
>> familiar to you: Atri has been very busy trying to improve Lucene over
>> the past months. In particular, Atri recently started improving our
>> top-hits optimizations like early termination on sorted indexes and
>> WAND, when indexes are searched using multiple threads.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Yonik Seeley

Congrats Atri!

-Yonik


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 following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Notes from the committers' meeting at Activate 2019

Yes I've used that GitHub issues interface many many times and IMHO and it
sucks. I put up with it because it's free and I'm not rich. I have a small
herd of stuff I have tossed up in git hub over the years across 2 accounts,
and I maintain JesterJ in GitHub... I'd move it to Jira in a heart beat if
there were a way to offer access to others for free. The Jira interface is
much much better for searching/displaying/sorting issues. It's easier to
see fields on the issues (because tables make it possible to predict where
on the screen you will find the information more accurately, and your eyes
can go right to it without having to read the whole line!). Jira has more
fields, ability to add custom fields, ability to filter and sort on *any*
field including said custom fields. It's also easier to add or eliminate
fields you actually care about (column configuration) and easier to save
searches you use frequently (haven't done that latter as much with
lucene/solr but definitely like it elsewhere). AFAIK GitHub has almost none
of that, let alone ability to define workflows or differentiate access to
issues via roles. From an Issue perspective GitHub issues are no more
flexible and no more feature rich than Bugzilla was when I first
encountered it in 2002. The main thing they have going for them is the
tight integration with VCS (close with comment etc) and that they are
free... and unlike Bugzilla it's hosted so you don't have to put work into
maintenance, or find a server to run it on.

It's entirely possible that there's added stuff unlocked with paid
organizations in GitHub that I haven't seen, or other features I just
haven't discovered, but as I see it the base thing I see and interact with
on most open source projects is very meh but very free, and I think that
free bit is the only reason it's so popular.

-Gus

On Wed, Sep 18, 2019 at 8:26 AM Erick Erickson 
wrote:

> It seems like there are two discussions happening here
> 1> moving code _development_ to GitHub
> 2> moving JIRA to GitHub
>
> I want to talk about <2>
>
> Gus:
>
> Have you looked at "issues" in GitHub? See:
>
> https://github.com/apache/accumulo/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
>
> On a _very_ quick look, my two main concerns about moving off JIRA are
> addressed:
> 1> being able to search/sort issues
> 2> seeing the discussion that went into whatever the end result was
> for a particular issue
>
> Anything else you do regularly that's not supported? Originally this
> was a long scree about why JIRA needs to remain, but as long as JIRA
> remains at least available for archival reasons and the two functions
> above are available, I can probably adapt. It'd be awkward to have to
> go to two places of course.
>
> That said, I have no interest at all in moving away from JIRA unless
> there are very clear advantages. Having to go to JIRA to see the
> discussion seems like a minimal barrier to entry IMO. Using GitHub for
> code development is compatible with staying on JIRA.
>
> On Wed, Sep 18, 2019 at 4:23 AM Jan Høydahl  wrote:
> >
> > We as a project won't need to worry about "system of record" or what MS
> will do in the future. Really.
> > I encourage all to read INFRA's post about the ASF-GitHub agreement here
> https://blogs.apache.org/infra/entry/apache-and-github-a-friendly
> > In the last paragraph it states:
> >
> > For many projects, the move to GitHub means a lower bar to both
> contributing as well as troubleshooting and submitting issues to the
> projects, through the GitHub issue and pull request features.
> >
> > Our commitment to provenance, quality and open governance remains the
> same, and with our tight integration with GitHub through our linked account
> service, we are able to bring what made Apache a mark of quality to the
> many users and contributors on GitHub.
> >
> >
> > ASF has us legally covered, and from the foundation's side, GitHub
> issues is equal to JIRA issues and GitHub PRs are equal to patches in JIRA.
> >
> > INFRA also clearly states in the same post that:
> >
> > People that wish to continue using their Apache committer accounts to
> commit code may continue doing so on gitbox.apache.org with their Apache
> credentials. Nothing has changed in that respect.
> >
> >
> > So the argument against TOS or personal M$ dislikes or principles won't
> hold here.
> >
> > We can continue accepting JIRA issues, patches and commits to GitBox for
> those who favor those tools for any reason.
> > But we can equally well embrace the entire GitHub tooling which was made
> available to us by ASF earlier this year, and make that the de facto (and
> primary documented) way of interacting with Lucene/Solr.
> > I'd prefer a complete switch like Accumulo did, as a dual tracker
> situation is a bit of a mess. A third option is to automate the creation of
> linked shadow issues in GH for new JIRA issues that gets created from Syria
> :)
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS -

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

2019-09-18 Thread Cassandra Targett

[v ] Leave it as is - I like quiet

I like the clear separation between the lists. It already feels less 
hectic/overwhelming to me. I will read both as often as I can anyway, so I 
don’t feel I’ll miss anything if the lists stay the way they are now.

There is a Jira plugin to support email digest notifications. I know nothing 
about it, just found it in a quick Google search for Jira notifications. A 
custom bot might be a better solution, but thought I’d point it out in case 
Infra would be willing to install it: 
https://marketplace.atlassian.com/apps/1217383/email-notifications-digest?hosting=server=overview

Thanks for working on these types of improvements!

Cassandra
On Sep 18, 2019, 8:54 AM -0500, Jan Høydahl , wrote:
> Going for a daily digest bot we could clarify this in the email text:
>
> Here is a list of new Lucene/Solr issues created on -MM-DD
>
> LUCENE-NNN  Nice new feature
> SOLR-NNN    Unfortunate bug
>
> To get updates for these issues in the future, watch them in JIRA.
> To get updates for all issues, subscribe to the issues@ mailing list.
>
>
> > 18. sep. 2019 kl. 15:34 skrev Adrien Grand :
> >
> > [x] Leave it as is - I like quiet
> >
> > It's not that much that I like quiet, but rather that I can easily
> > imagine it become confusing over time as new contributors join the
> > list and think they get notified about all interactions on JIRA, only
> > to notice several days later that it only includes notifications about
> > new issues. This behavior can be configured easily enough in email
> > clients.
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>

Re: Direct I/O

2019-09-18 Thread Uwe Schindler

The direct io has in fact the problem which was just wrongly named by Dawid: 
Block alignment is needed - on disk and not in memory. In short: You can't read 
or write a single byte anywhere in file; you need a buffering layer in-between 
that takes care of alignment. NativeUnixDir does this.

Uwe

Am September 18, 2019 1:54:35 PM UTC schrieb Dawid Weiss 
:
>Thanks for the explanation, Mike!
>
>D.
>
>On Wed, Sep 18, 2019 at 3:21 PM Michael McCandless
> wrote:
>>
>> Dawid, it's confusing: direct IO is different from a direct
>ByteBuffer!
>>
>> Direct IO means you bypass all kernel "smarts", so the Linux buffer
>cache is not used, no IO scheduling, no write cache that the pdflush
>daemon must periodically move to disk, etc.  This is normally a bad
>idea, and better to use fadvise/madvise to give kernel hints about what
>you are doing, and use the buffer cache for what it's good at.  Linus
>hates that direct IO is even an option for us ...
>>
>> Back when I wrote NativeUnixDirectory, the idea was to prevent
>ongoing merges from so heavily impacting ongoing searches, when you are
>doing indexing and searching on one node.  We open the newly merged
>segments files using direct IO, and do our own buffering, and then all
>writes go straight to disk instead of using up precious hot pages that
>are in use for searching.  I think I ran some simple performance tests
>back then but I don't remember the results ... more testing is needed
>to see if it really helps.
>>
>> At Amazon, we are using segment based replication ever 60 seconds to
>copy newly indexed segments out to all searchers, so we never have
>nodes doing both indexing or searching, it's either or ... but, copying
>out max sized newly merged segments to the searchers is causing some
>thrashing so we are exploring using direct IO for those writes, and
>then separately warming the new segments after the copy.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Tue, Sep 17, 2019 at 1:16 PM Uwe Schindler 
>wrote:
>>>
>>> We discussed this already on Berlinbuzzwords (Mike and Michael). Yes
>it's possible and may work for merges where block io is possible. But
>most of us said: it's fine to not use io cache for merging, but it
>won't make pages hot. So merges are invisible to OS, so you have to
>warm merged segments if you write directly. If you read directly on
>merging, you won't pollute cache with one time reads, but it also won't
>use cache if already cached.
>>> We should better make a proposal for f/madvise. The jdk people are
>open for that, and I am jdk committer now, so I can make a prototype.
>>>
>>> Uwe
>>>
>>> Am September 17, 2019 4:48:26 PM UTC schrieb Dawid Weiss
>:

 Isn't that restricted to aligned block-only access though? I can
 imagine this would complicate the implementation if somebody wanted
>to
 use it directly.

 Dawid

 On Tue, Sep 17, 2019 at 5:37 PM Michael McCandless
  wrote:
>
>
>  Whoa!  That would be awesome -- no more JNI to use Direct I/O?
>  Looks like you use it like this:
>
>  FileChannel fc = FileChannel.open(p, StandardOpenOption.WRITE,
>ExtendedOpenOption.DIRECT
>
>  But it looks like you need to enable the jdk.unsupported module,
>added with http://openjdk.java.net/jeps/260
>
>  Mike McCandless
>
>  http://blog.mikemccandless.com
>
>
>  On Mon, Sep 16, 2019 at 11:55 AM Michael Sokolov
> wrote:
>>
>>
>>  https://bugs.openjdk.java.net/browse/JDK-8189192 makes it appear
>that
>>  Direct I/O is (or may be?) available now in JDK's since JDK10.
>Should
>>  we try using that API in NativeUnixDirectory in order to avoid
>JNI
>>  calls?
>> 
>>  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

>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: Direct I/O

2019-09-18 Thread Dawid Weiss

Thanks for the explanation, Mike!

D.

On Wed, Sep 18, 2019 at 3:21 PM Michael McCandless
 wrote:
>
> Dawid, it's confusing: direct IO is different from a direct ByteBuffer!
>
> Direct IO means you bypass all kernel "smarts", so the Linux buffer cache is 
> not used, no IO scheduling, no write cache that the pdflush daemon must 
> periodically move to disk, etc.  This is normally a bad idea, and better to 
> use fadvise/madvise to give kernel hints about what you are doing, and use 
> the buffer cache for what it's good at.  Linus hates that direct IO is even 
> an option for us ...
>
> Back when I wrote NativeUnixDirectory, the idea was to prevent ongoing merges 
> from so heavily impacting ongoing searches, when you are doing indexing and 
> searching on one node.  We open the newly merged segments files using direct 
> IO, and do our own buffering, and then all writes go straight to disk instead 
> of using up precious hot pages that are in use for searching.  I think I ran 
> some simple performance tests back then but I don't remember the results ... 
> more testing is needed to see if it really helps.
>
> At Amazon, we are using segment based replication ever 60 seconds to copy 
> newly indexed segments out to all searchers, so we never have nodes doing 
> both indexing or searching, it's either or ... but, copying out max sized 
> newly merged segments to the searchers is causing some thrashing so we are 
> exploring using direct IO for those writes, and then separately warming the 
> new segments after the copy.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Sep 17, 2019 at 1:16 PM Uwe Schindler  wrote:
>>
>> We discussed this already on Berlinbuzzwords (Mike and Michael). Yes it's 
>> possible and may work for merges where block io is possible. But most of us 
>> said: it's fine to not use io cache for merging, but it won't make pages 
>> hot. So merges are invisible to OS, so you have to warm merged segments if 
>> you write directly. If you read directly on merging, you won't pollute cache 
>> with one time reads, but it also won't use cache if already cached.
>> We should better make a proposal for f/madvise. The jdk people are open for 
>> that, and I am jdk committer now, so I can make a prototype.
>>
>> Uwe
>>
>> Am September 17, 2019 4:48:26 PM UTC schrieb Dawid Weiss 
>> :
>>>
>>> Isn't that restricted to aligned block-only access though? I can
>>> imagine this would complicate the implementation if somebody wanted to
>>> use it directly.
>>>
>>> Dawid
>>>
>>> On Tue, Sep 17, 2019 at 5:37 PM Michael McCandless
>>>  wrote:


  Whoa!  That would be awesome -- no more JNI to use Direct I/O?
  Looks like you use it like this:

  FileChannel fc = FileChannel.open(p, StandardOpenOption.WRITE,
ExtendedOpenOption.DIRECT

  But it looks like you need to enable the jdk.unsupported module, added 
 with http://openjdk.java.net/jeps/260

  Mike McCandless

  http://blog.mikemccandless.com


  On Mon, Sep 16, 2019 at 11:55 AM Michael Sokolov  
 wrote:
>
>
>  https://bugs.openjdk.java.net/browse/JDK-8189192 makes it appear that
>  Direct I/O is (or may be?) available now in JDK's since JDK10. Should
>  we try using that API in NativeUnixDirectory in order to avoid JNI
>  calls?
> 
>  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
>>>
>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de

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

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

Going for a daily digest bot we could clarify this in the email text:

Here is a list of new Lucene/Solr issues created on -MM-DD

LUCENE-NNN  Nice new feature
SOLR-NNNUnfortunate bug

To get updates for these issues in the future, watch them in JIRA.
To get updates for all issues, subscribe to the issues@ mailing list.


> 18. sep. 2019 kl. 15:34 skrev Adrien Grand :
> 
> [x] Leave it as is - I like quiet
> 
> It's not that much that I like quiet, but rather that I can easily
> imagine it become confusing over time as new contributors join the
> list and think they get notified about all interactions on JIRA, only
> to notice several days later that it only includes notifications about
> new issues. This behavior can be configured easily enough in email
> clients.
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

2019-09-18 Thread Adrien Grand

[x] Leave it as is - I like quiet

It's not that much that I like quiet, but rather that I can easily
imagine it become confusing over time as new contributors join the
list and think they get notified about all interactions on JIRA, only
to notice several days later that it only includes notifications about
new issues. This behavior can be configured easily enough in email
clients.

-- 
Adrien

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

Re: Direct I/O

OK I opened https://issues.apache.org/jira/browse/LUCENE-8982.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Sep 18, 2019 at 9:23 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Aha!  Yes, Uwe, now I remember you explained this to me, that we can now
> do direct IO purely in java.  I think we should fix up NativeUnixDirectory,
> and then run some more benchmarks to see if it helps?  I'll open an issue.
>
> And definitely big +1 to give us fadvise/madvise in Java so we can test
> that too.  It's better long term to give hints to the kernel and then let
> it manage its buffer cache appropriately.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Sep 17, 2019 at 1:16 PM Uwe Schindler  wrote:
>
>> We discussed this already on Berlinbuzzwords (Mike and Michael). Yes it's
>> possible and may work for merges where block io is possible. But most of us
>> said: it's fine to not use io cache for merging, but it won't make pages
>> hot. So merges are invisible to OS, so you have to warm merged segments if
>> you write directly. If you read directly on merging, you won't pollute
>> cache with one time reads, but it also won't use cache if already cached.
>> We should better make a proposal for f/madvise. The jdk people are open
>> for that, and I am jdk committer now, so I can make a prototype.
>>
>> Uwe
>>
>> Am September 17, 2019 4:48:26 PM UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>>>
>>> Isn't that restricted to aligned block-only access though? I can
>>> imagine this would complicate the implementation if somebody wanted to
>>> use it directly.
>>>
>>> Dawid
>>>
>>> On Tue, Sep 17, 2019 at 5:37 PM Michael McCandless
>>>  wrote:
>>>

  Whoa!  That would be awesome -- no more JNI to use Direct I/O?
  Looks like you use it like this:

  FileChannel fc = FileChannel.open(p, StandardOpenOption.WRITE,
ExtendedOpenOption.DIRECT

  But it looks like you need to enable the jdk.unsupported module, added 
 with http://openjdk.java.net/jeps/260

  Mike McCandless

  http://blog.mikemccandless.com


  On Mon, Sep 16, 2019 at 11:55 AM Michael Sokolov  
 wrote:

>
>  https://bugs.openjdk.java.net/browse/JDK-8189192 makes it appear that
>  Direct I/O is (or may be?) available now in JDK's since JDK10. Should
>  we try using that API in NativeUnixDirectory in order to avoid JNI
>  calls?
> --
>  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
>>>
>>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

2019-09-18 Thread Alexandre Rafalovitch

Either one of "Created" notifications works for me and would be very nice:
> [X] A mail to dev@ for every new JIRA
> [X] One daily digest mail per day with a list of new JIRAs

I sort of had that workflow already with GMail rules, so it would be
nice to have it more explicitly. And, the subscribed issues still
arrive directly anyway, so nothing needs to be changed there.

Regards,
   Alex.

On Wed, 18 Sep 2019 at 05:10, Jan Høydahl  wrote:
>
> Hi,
>
> The transition to issues@ and builds@ lists (LUCENE-8951) is now completed, 
> and I already enjoy a quieter dev@ folder!
>
> I'd like to check with all of you whether there is interest in getting 
> notified here at dev@ about NEW Jira issue created. Currently there is an 
> average of 4 new issues per day. The main motivation for this would be for 
> those who want to follow new development but not all the details/discussions. 
> We could easily configure JIRA to send all [Created] mails to dev@ in 
> addition to issues@. Or we could try to have one daily digest mail of new 
> issues, whether that's a small bot or a feature in JIRA (don't know). Let's 
> to a poll:
>
> [ ] Leave it as is - I like quiet
> [ ] A mail to dev@ for every new JIRA
> [ ] One daily digest mail per day with a list of new JIRAs
> [ ] Other (explain): ___
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> 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: Direct I/O

Aha!  Yes, Uwe, now I remember you explained this to me, that we can now do
direct IO purely in java.  I think we should fix up NativeUnixDirectory,
and then run some more benchmarks to see if it helps?  I'll open an issue.

And definitely big +1 to give us fadvise/madvise in Java so we can test
that too.  It's better long term to give hints to the kernel and then let
it manage its buffer cache appropriately.

Mike McCandless

http://blog.mikemccandless.com


On Tue, Sep 17, 2019 at 1:16 PM Uwe Schindler  wrote:

> We discussed this already on Berlinbuzzwords (Mike and Michael). Yes it's
> possible and may work for merges where block io is possible. But most of us
> said: it's fine to not use io cache for merging, but it won't make pages
> hot. So merges are invisible to OS, so you have to warm merged segments if
> you write directly. If you read directly on merging, you won't pollute
> cache with one time reads, but it also won't use cache if already cached.
> We should better make a proposal for f/madvise. The jdk people are open
> for that, and I am jdk committer now, so I can make a prototype.
>
> Uwe
>
> Am September 17, 2019 4:48:26 PM UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
>>
>> Isn't that restricted to aligned block-only access though? I can
>> imagine this would complicate the implementation if somebody wanted to
>> use it directly.
>>
>> Dawid
>>
>> On Tue, Sep 17, 2019 at 5:37 PM Michael McCandless
>>  wrote:
>>
>>>
>>>  Whoa!  That would be awesome -- no more JNI to use Direct I/O?
>>>  Looks like you use it like this:
>>>
>>>  FileChannel fc = FileChannel.open(p, StandardOpenOption.WRITE,
>>>ExtendedOpenOption.DIRECT
>>>
>>>  But it looks like you need to enable the jdk.unsupported module, added 
>>> with http://openjdk.java.net/jeps/260
>>>
>>>  Mike McCandless
>>>
>>>  http://blog.mikemccandless.com
>>>
>>>
>>>  On Mon, Sep 16, 2019 at 11:55 AM Michael Sokolov  
>>> wrote:
>>>

  https://bugs.openjdk.java.net/browse/JDK-8189192 makes it appear that
  Direct I/O is (or may be?) available now in JDK's since JDK10. Should
  we try using that API in NativeUnixDirectory in order to avoid JNI
  calls?
 --
  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
>>
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Re: Direct I/O

Dawid, it's confusing: direct IO is different from a direct ByteBuffer!

Direct IO means you bypass all kernel "smarts", so the Linux buffer cache
is not used, no IO scheduling, no write cache that the pdflush daemon must
periodically move to disk, etc.  This is normally a bad idea, and better to
use fadvise/madvise to give kernel hints about what you are doing, and use
the buffer cache for what it's good at.  Linus hates that direct IO is even
an option for us ...

Back when I wrote NativeUnixDirectory, the idea was to prevent ongoing
merges from so heavily impacting ongoing searches, when you are doing
indexing and searching on one node.  We open the newly merged segments
files using direct IO, and do our own buffering, and then all writes go
straight to disk instead of using up precious hot pages that are in use for
searching.  I think I ran some simple performance tests back then but I
don't remember the results ... more testing is needed to see if it really
helps.

At Amazon, we are using segment based replication ever 60 seconds to copy
newly indexed segments out to all searchers, so we never have nodes doing
both indexing or searching, it's either or ... but, copying out max sized
newly merged segments to the searchers is causing some thrashing so we are
exploring using direct IO for those writes, and then separately warming the
new segments after the copy.

Mike McCandless

http://blog.mikemccandless.com

On Tue, Sep 17, 2019 at 1:16 PM Uwe Schindler  wrote:

> We discussed this already on Berlinbuzzwords (Mike and Michael). Yes it's
> possible and may work for merges where block io is possible. But most of us
> said: it's fine to not use io cache for merging, but it won't make pages
> hot. So merges are invisible to OS, so you have to warm merged segments if
> you write directly. If you read directly on merging, you won't pollute
> cache with one time reads, but it also won't use cache if already cached.
> We should better make a proposal for f/madvise. The jdk people are open
> for that, and I am jdk committer now, so I can make a prototype.
>
> Uwe
>
> Am September 17, 2019 4:48:26 PM UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
>>
>> Isn't that restricted to aligned block-only access though? I can
>> imagine this would complicate the implementation if somebody wanted to
>> use it directly.
>>
>> Dawid
>>
>> On Tue, Sep 17, 2019 at 5:37 PM Michael McCandless
>>  wrote:
>>
>>>
>>>  Whoa!  That would be awesome -- no more JNI to use Direct I/O?
>>>  Looks like you use it like this:
>>>
>>>  FileChannel fc = FileChannel.open(p, StandardOpenOption.WRITE,
>>>ExtendedOpenOption.DIRECT
>>>
>>>  But it looks like you need to enable the jdk.unsupported module, added 
>>> with http://openjdk.java.net/jeps/260
>>>
>>>  Mike McCandless
>>>
>>>  http://blog.mikemccandless.com
>>>
>>>
>>>  On Mon, Sep 16, 2019 at 11:55 AM Michael Sokolov  
>>> wrote:
>>>

  https://bugs.openjdk.java.net/browse/JDK-8189192 makes it appear that
  Direct I/O is (or may be?) available now in JDK's since JDK10. Should
  we try using that API in NativeUnixDirectory in order to avoid JNI
  calls?
 --
  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
>>
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Atri Sharma

Thank you, everybody, for the warm welcome.

I work at Amazon, where I am focused on the core product search engine
which serves all of our retail entities. My background is in relational and
non relational databases, with a penchant for statistical and heuristics
based query optimisation. I was introduced to the wonderful world of Lucene
by my mentor, Mike Mccandless, and immediately saw a synergy between the
project and my interests.

I would like to thank the entire community for being so welcoming  (and
patient!). Looking forward to helping shape the future of Lucene, together.

Regards,

Atri

On Wed, 18 Sep 2019 at 16:52, Erik Hatcher  wrote:

> /me humbly bows
>
> I'm glad you are here, Atri!
>
>   Erik
>
> > On Sep 18, 2019, at 03:11, Adrien Grand  wrote:
> >
> > Hi all,
> >
> > Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
> >
> > If you are following activity on Lucene, this name will likely sound
> > familiar to you: Atri has been very busy trying to improve Lucene over
> > the past months. In particular, Atri recently started improving our
> > top-hits optimizations like early termination on sorted indexes and
> > WAND, when indexes are searched using multiple threads.
> >
> > Congratulations and welcome! It is a tradition to introduce yourself
> > with a brief bio.
> >
> > --
> > Adrien
> >
> > -
> > 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
>
> --
Regards,

Atri
Apache Concerted

Re: Notes from the committers' meeting at Activate 2019

2019-09-18 Thread Erick Erickson

It seems like there are two discussions happening here
1> moving code _development_ to GitHub
2> moving JIRA to GitHub

I want to talk about <2>

Gus:

Have you looked at "issues" in GitHub? See:
https://github.com/apache/accumulo/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

On a _very_ quick look, my two main concerns about moving off JIRA are
addressed:
1> being able to search/sort issues
2> seeing the discussion that went into whatever the end result was
for a particular issue

Anything else you do regularly that's not supported? Originally this
was a long scree about why JIRA needs to remain, but as long as JIRA
remains at least available for archival reasons and the two functions
above are available, I can probably adapt. It'd be awkward to have to
go to two places of course.

That said, I have no interest at all in moving away from JIRA unless
there are very clear advantages. Having to go to JIRA to see the
discussion seems like a minimal barrier to entry IMO. Using GitHub for
code development is compatible with staying on JIRA.

On Wed, Sep 18, 2019 at 4:23 AM Jan Høydahl  wrote:
>
> We as a project won't need to worry about "system of record" or what MS will 
> do in the future. Really.
> I encourage all to read INFRA's post about the ASF-GitHub agreement here 
> https://blogs.apache.org/infra/entry/apache-and-github-a-friendly
> In the last paragraph it states:
>
> For many projects, the move to GitHub means a lower bar to both contributing 
> as well as troubleshooting and submitting issues to the projects, through the 
> GitHub issue and pull request features.
>
> Our commitment to provenance, quality and open governance remains the same, 
> and with our tight integration with GitHub through our linked account 
> service, we are able to bring what made Apache a mark of quality to the many 
> users and contributors on GitHub.
>
>
> ASF has us legally covered, and from the foundation's side, GitHub issues is 
> equal to JIRA issues and GitHub PRs are equal to patches in JIRA.
>
> INFRA also clearly states in the same post that:
>
> People that wish to continue using their Apache committer accounts to commit 
> code may continue doing so on gitbox.apache.org with their Apache 
> credentials. Nothing has changed in that respect.
>
>
> So the argument against TOS or personal M$ dislikes or principles won't hold 
> here.
>
> We can continue accepting JIRA issues, patches and commits to GitBox for 
> those who favor those tools for any reason.
> But we can equally well embrace the entire GitHub tooling which was made 
> available to us by ASF earlier this year, and make that the de facto (and 
> primary documented) way of interacting with Lucene/Solr.
> I'd prefer a complete switch like Accumulo did, as a dual tracker situation 
> is a bit of a mess. A third option is to automate the creation of linked 
> shadow issues in GH for new JIRA issues that gets created from Syria :)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 18. sep. 2019 kl. 06:58 skrev Gus Heck :
>
> I wrote quickly and didn't expound much, let me clarify that my comments are 
> in reference to having bug tracking in GitHub. Using the mirror doesn't 
> bother me since the system of record is apache gitbox (the GitHub mirror is 
> WAY better UI than gitbox). Having the record of what bugs were resolved in 
> what versions and the thought that went into it, only exist outside apache is 
> all I'm worried about. I'm not anti git, nor am I anti code review in GitHub, 
> as long as major direction changes and decisions s are summarized in jira, or 
> in code comments. I also have generally assumed that pull request reviews 
> were meant to mostly be code review, i.e. focused comments on specific lines 
> or classes . Discussion of how to solve bugs or possible directions for 
> features would be in jira.
>
> In more concrete terms one thing I will definitely miss if we go to GitHub is 
> the tabular view of issues, especially the ability to sort by issue ID which 
> I use regularly to get a view of (roughly) chronologically history of changes 
> on a topic. I really find their way of listing issues very hard to read. It 
> would be much easier to scan down a column of milestones for example.
>
> By the way, how would we plan to handle fix versions in GitHub issues? 
> Milestones? What about affects version etc.
>
> And I don't agree that "everyone is on GitHub" I still have yet to encounter 
> a single client site that was using GitHub (~20 clients in 6 years ranging 
> from 1 man startups to Fortune 50 companies). Plenty using git, often 
> bitbucket, but nobody using github itself. Plenty of open source projects 
> (including minor ones I started) use GitHub... But the idea that folks out 
> there won't know how to adapt to anything other than GitHub seems 
> preposterous to me. The only folks who are not going to be able to absorb a 
> new bug tracking system are the very junior devs, few of

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Erik Hatcher

/me humbly bows 

I'm glad you are here, Atri!

  Erik

> On Sep 18, 2019, at 03:11, Adrien Grand  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
> 
> If you are following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
> 
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
> 
> -- 
> Adrien
> 
> -
> 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: [POLL] Should notifications of NEW Jira issues go to dev@?

2019-09-18 Thread Erick Erickson

Always some clown doesn't follow the rules. I think there's
significant value in seeing the new JIRAs go by, and 4 e-mails a day
isn't onerous so either of the choices I've marked are fine with me.

And thanks for working on this! Unfortunately my laptop is in the shop
with screen problems and all my Apple Mail filters went with it so I
don't get the benefit of all this goodness (yet). Sgh...

[ ] Leave it as is - I like quiet
[v] A mail to dev@ for every new JIRA
[v] One daily digest mail per day with a list of new JIRAs
[ ] Other (explain): ___

On Wed, Sep 18, 2019 at 5:25 AM Mikhail Khludnev  wrote:
>
> [ ] Leave it as is - I like quiet
> [ ] A mail to dev@ for every new JIRA
> [v] One daily digest mail per day with a list of new JIRAs
> [ ] Other (explain): ___
>
> On Wed, Sep 18, 2019 at 12:10 PM Jan Høydahl  wrote:
>>
>> Hi,
>>
>> The transition to issues@ and builds@ lists (LUCENE-8951) is now completed, 
>> and I already enjoy a quieter dev@ folder!
>>
>> I'd like to check with all of you whether there is interest in getting 
>> notified here at dev@ about NEW Jira issue created. Currently there is an 
>> average of 4 new issues per day. The main motivation for this would be for 
>> those who want to follow new development but not all the 
>> details/discussions. We could easily configure JIRA to send all [Created] 
>> mails to dev@ in addition to issues@. Or we could try to have one daily 
>> digest mail of new issues, whether that's a small bot or a feature in JIRA 
>> (don't know). Let's to a poll:
>>
>> [ ] Leave it as is - I like quiet
>> [ ] A mail to dev@ for every new JIRA
>> [ ] One daily digest mail per day with a list of new JIRAs
>> [ ] Other (explain): ___
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev

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

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Erick Erickson

Welcome Atri! Well deserved.

On Wed, Sep 18, 2019 at 6:47 AM Michael Sokolov  wrote:
>
> Welcome Atri!
>
> On Wed, Sep 18, 2019, 3:12 AM Adrien Grand  wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>>
>> If you are following activity on Lucene, this name will likely sound
>> familiar to you: Atri has been very busy trying to improve Lucene over
>> the past months. In particular, Atri recently started improving our
>> top-hits optimizations like early termination on sorted indexes and
>> WAND, when indexes are searched using multiple threads.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>>
>> --
>> Adrien
>>
>> -
>> 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: Github PR Collaboration Question

2019-09-18 Thread Jason Gerlowski

Thanks for chiming in guys.  I created a JIRA for this (SOLR-13775).
Haven't really thought about wording or anything yet, if either of you
have any suggestions.  Otherwise I'll hope to get to this over the
weekend.

Jason

On Tue, Sep 17, 2019 at 3:39 PM David Smiley  wrote:
>
> RE the idea of shash-merge from a PR:  that would be cool were it not for 
> CHANGES.txt; ah well.
>
> +1 to "put it in the PR template checklist"
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Sep 17, 2019 at 2:37 PM Jan Høydahl  wrote:
>>
>> I like the idea to put it in the PR template checklist. Or you can ask the 
>> contributor to check that box. I once made a PR against another PR branch 
>> and it worked but was too many steps.
>>
>> I like the 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 :
>> >
>> > Github does have an option that fork-owners can click when they create
>> > a PR that will give those with karma on the upstream repo the same
>> > karma on their PR branch.  [1] That would solve this problem somewhat.
>> > But it's still up to users to choose that themselves.  Maybe it makes
>> > sense to mention 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 Jason Gerlowski  
>> >> wrote:
>> >>
>> >> 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 yet, or to show what I’m suggesting with
>> >> a particular review comment, or to clean up little things like
>> >> whitespace formatting, etc.  In the patch world, this is easy to do
>> >> without requiring review/acking by other contributors…you apply the
>> >> latest patch, make your additional changes, and re-upload to jira.
>> >> But in Github, you have to juggle branch/PR ownership.  PR’s are often
>> >> from personal forks, where others don't have write access there.  So I
>> >> can't add to the "main" PR without either (a) asking the contributor
>> >> to give me the right karma, or (b) opening my own "secondary" PR
>> >> against their "main" PR branch, and asking them to review/merge my
>> >> "secondary" PR.
>> >>
>> >> Is there some simpler approach I'm missing?  I love the in-line
>> >> comments that Github supports for code-review, and it seems like more
>> >> committers are starting to use it.  I'd love to figure out how to make
>> >> it work for me.  But two developers collaborating on the same PR seems
>> >> like a pretty fundamental use case to be so heavyweight.  This must be
>> >> a problem that's solved, right?
>> >>
>> >> 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: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Michael Sokolov

Welcome Atri!

On Wed, Sep 18, 2019, 3:12 AM Adrien Grand  wrote:

> Hi all,
>
> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>
> If you are following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Joel Bernstein

Welcome Atri!


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


On Wed, Sep 18, 2019 at 6:32 AM Jason Gerlowski 
wrote:

> 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 following activity on Lucene, this name will likely sound
> >> familiar to you: Atri has been very busy trying to improve Lucene over
> >> the past months. In particular, Atri recently started improving our
> >> top-hits optimizations like early termination on sorted indexes and
> >> WAND, when indexes are searched using multiple threads.
> >>
> >> Congratulations and welcome! It is a tradition to introduce yourself
> >> with a brief bio.
> >>
> >> --
> >> Adrien
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > --
> > Regards,
> > Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Jason Gerlowski

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 following activity on Lucene, this name will likely sound
>> familiar to you: Atri has been very busy trying to improve Lucene over
>> the past months. In particular, Atri recently started improving our
>> top-hits optimizations like early termination on sorted indexes and
>> WAND, when indexes are searched using multiple threads.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.

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

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Shalin Shekhar Mangar

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 following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Regards,
Shalin Shekhar Mangar.

Re: 8.3 release

2019-09-18 Thread Joel Bernstein

That timeframe sounds good. A major focus for me will be completing and
merging SOLR-13105  which
is part of the ref guide.


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


On Tue, Sep 17, 2019 at 9:19 PM Anshum Gupta  wrote:

> I think it makes sense to just bundle the code and ref guide release into
> one. Right now, it's been Cassandra and Hoss who have taken care of the ref
> guide, but that shouldn't be the case.
>
> It might mean that the ref guide is a little behind when the code
> releases, but then we should just be better at committing the documentation
> when we commit the code. Hopefully, we'll get better at that and the ref
> guide releases would contain all new features but overall, having a
> different release/voting process for the ref guide is a lot of overhead
> that isn't really needed.
>
>
> On Tue, Sep 17, 2019 at 4:31 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Hi Adrien,
>> Indeed, meant to write about starting a vote.
>>
>> @Gus, I'll have to let Cassandra weigh in on this one as I'm not very
>> familiar with the ref guide release process.
>>
>> Regards,
>> Ishan
>>
>> On Mon, 16 Sep, 2019, 7:28 PM Adrien Grand,  wrote:
>>
>>> +1 to start working on 8.3
>>>
>>> Did you mean "start a vote" when you wrote "release the artifacts"? It
>>> got me wondering because I don't think we frequently managed to go
>>> from cutting a branch to releasing artifacts in so little time in the
>>> past.
>>>
>>> On Mon, Sep 16, 2019 at 5:52 PM Ishan Chattopadhyaya
>>>  wrote:
>>> >
>>> > Hi all,
>>> > We have a lot of unreleased features and fixes. I propose that we cut
>>> > a 8.3 branch in two weeks (in order to have sufficient time to bake in
>>> > all in-progress features). If there are no objections to doing so, I
>>> > can volunteer for the release as an RM and plan for cutting a release
>>> > branch on 30 September (and release the artifacts about 3-4 days after
>>> > that).
>>> >
>>> > WDYT?
>>> > Regards,
>>> > Ishan
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>>
>>>
>>> --
>>> Adrien
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>
> --
> Anshum Gupta
>

Re: Welcome Atri Sharma as Lucene/Solr committer

Congratulations Atri!

Mike McCandless

http://blog.mikemccandless.com

On Wed, Sep 18, 2019 at 5:49 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Congrats and welcome, Atri!
>
> On Wed, 18 Sep, 2019, 12:15 PM MUNENDRA S N, 
> wrote:
>
>> Congratulations and welcome, Atri
>>
>>
>> On Wed, Sep 18, 2019 at 2:12 PM Mikhail Khludnev  wrote:
>>
>>> Welcome, Atri.
>>>
>>> On Wed, Sep 18, 2019 at 10:12 AM Adrien Grand  wrote:
>>>
 Hi all,

 Please join me in welcoming Atri Sharma as Lucene/ Solr committer!

 If you are following activity on Lucene, this name will likely sound
 familiar to you: Atri has been very busy trying to improve Lucene over
 the past months. In particular, Atri recently started improving our
 top-hits optimizations like early termination on sorted indexes and
 WAND, when indexes are searched using multiple threads.

 Congratulations and welcome! It is a tradition to introduce yourself
 with a brief bio.

 --
 Adrien

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

>>>
>>> --
>>> Sincerely yours
>>> Mikhail Khludnev
>>>
>>

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Ishan Chattopadhyaya

Congrats and welcome, Atri!

On Wed, 18 Sep, 2019, 12:15 PM MUNENDRA S N, 
wrote:

> Congratulations and welcome, Atri
>
>
> On Wed, Sep 18, 2019 at 2:12 PM Mikhail Khludnev  wrote:
>
>> Welcome, Atri.
>>
>> On Wed, Sep 18, 2019 at 10:12 AM Adrien Grand  wrote:
>>
>>> Hi all,
>>>
>>> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>>>
>>> If you are following activity on Lucene, this name will likely sound
>>> familiar to you: Atri has been very busy trying to improve Lucene over
>>> the past months. In particular, Atri recently started improving our
>>> top-hits optimizations like early termination on sorted indexes and
>>> WAND, when indexes are searched using multiple threads.
>>>
>>> Congratulations and welcome! It is a tradition to introduce yourself
>>> with a brief bio.
>>>
>>> --
>>> Adrien
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>>
>

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

2019-09-18 Thread Mikhail Khludnev

[ ] Leave it as is - I like quiet
[ ] A mail to dev@ for every new JIRA
[v] One daily digest mail per day with a list of new JIRAs
[ ] Other (explain): ___

On Wed, Sep 18, 2019 at 12:10 PM Jan Høydahl  wrote:

> Hi,
>
> The transition to issues@ and builds@ lists (LUCENE-8951) is now
> completed, and I already enjoy a quieter dev@ folder!
>
> I'd like to check with all of you whether there is interest in getting
> notified here at dev@ about NEW Jira issue created. Currently there is an
> average of 4 new issues per day. The main motivation for this would be for
> those who want to follow new development but not all the
> details/discussions. We could easily configure JIRA to send all [Created]
> mails to dev@ in addition to issues@. Or we could try to have one daily
> digest mail of new issues, whether that's a small bot or a feature in JIRA
> (don't know). Let's to a poll:
>
> [ ] Leave it as is - I like quiet
> [ ] A mail to dev@ for every new JIRA
> [ ] One daily digest mail per day with a list of new JIRAs
> [ ] Other (explain): ___
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Sincerely yours
Mikhail Khludnev

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread MUNENDRA S N

Congratulations and welcome, Atri


On Wed, Sep 18, 2019 at 2:12 PM Mikhail Khludnev  wrote:

> Welcome, Atri.
>
> On Wed, Sep 18, 2019 at 10:12 AM Adrien Grand  wrote:
>
>> Hi all,
>>
>> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>>
>> If you are following activity on Lucene, this name will likely sound
>> familiar to you: Atri has been very busy trying to improve Lucene over
>> the past months. In particular, Atri recently started improving our
>> top-hits optimizations like early termination on sorted indexes and
>> WAND, when indexes are searched using multiple threads.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

[POLL] Should notifications of NEW Jira issues go to dev@?

Hi,

The transition to issues@ and builds@ lists (LUCENE-8951) is now completed, and 
I already enjoy a quieter dev@ folder!

I'd like to check with all of you whether there is interest in getting notified 
here at dev@ about NEW Jira issue created. Currently there is an average of 4 
new issues per day. The main motivation for this would be for those who want to 
follow new development but not all the details/discussions. We could easily 
configure JIRA to send all [Created] mails to dev@ in addition to issues@. Or 
we could try to have one daily digest mail of new issues, whether that's a 
small bot or a feature in JIRA (don't know). Let's to a poll:

[ ] Leave it as is - I like quiet
[ ] A mail to dev@ for every new JIRA
[ ] One daily digest mail per day with a list of new JIRAs
[ ] Other (explain): ___

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


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

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Mikhail Khludnev

Welcome, Atri.

On Wed, Sep 18, 2019 at 10:12 AM Adrien Grand  wrote:

> Hi all,
>
> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>
> If you are following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
>
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Sincerely yours
Mikhail Khludnev

Re: [ANNOUNCE] New builds@ and issues@ mailing lists

REMINDER

As you may have noticed, it's now much more quite around here at dev@.
Automated email announcements from JIRA, Git and Jenkins now go to the new 
lists.
If you missed this announcement earlier (due to all the noise), now is the time 
to subscribe, see instructions below.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 9. sep. 2019 kl. 09:53 skrev Jan Høydahl :
> 
> The Lucene project has added two new announce mailing lists,
> `iss...@lucene.aparche.org` and `bui...@lucene.apache.org`.  High-volume
> automated emails from our bug tracker, JIRA and GitHub will be moved
> from the `dev@` list to `issues@` and automated emails from our Jenkins
> CI build servers will be moved from the `dev@` list to `builds@`. This
> will happen during the next few days.
> 
> This is an effort to reduce the sometimes overwhelming email volume on
> our main development mailing list and thus make it easier for the
> community to follow important discussions by humans on the
> `dev@lucene.apache.org` list.
> 
> Everyone who wants to continue receiving these automated emails should
> sign up for one or both of the two new lists. Sign-up instructions can
> be found on the Lucene-java[1] and Solr[2] web sites.
> 
> [1] https://lucene.apache.org/core/discussion.html
> [2] https://lucene.apache.org/solr/community.html
> 
> --
> Jan Høydahl, on behalf of the Lucene PMC

Re: Welcome Atri Sharma as Lucene/Solr committer

2019-09-18 Thread Jitendra soni

Welcome Atri

On Wed, 18 Sep 2019 at 17:31, jim ferenczi  wrote:

> Congratulations Atri!
>
> Le mer. 18 sept. 2019 à 09:28, Ignacio Vera  a écrit :
>
>> Welcome Atri!
>>
>> On Wed, Sep 18, 2019 at 9:12 AM Adrien Grand  wrote:
>>
>>> Hi all,
>>>
>>> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>>>
>>> If you are following activity on Lucene, this name will likely sound
>>> familiar to you: Atri has been very busy trying to improve Lucene over
>>> the past months. In particular, Atri recently started improving our
>>> top-hits optimizations like early termination on sorted indexes and
>>> WAND, when indexes are searched using multiple threads.
>>>
>>> Congratulations and welcome! It is a tradition to introduce yourself
>>> with a brief bio.
>>>
>>> --
>>> Adrien
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
Thanks
Jitendra

Re: Welcome Atri Sharma as Lucene/Solr committer

Welcome, Atri!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 18. sep. 2019 kl. 09:11 skrev Adrien Grand :
> 
> Hi all,
> 
> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
> 
> If you are following activity on Lucene, this name will likely sound
> familiar to you: Atri has been very busy trying to improve Lucene over
> the past months. In particular, Atri recently started improving our
> top-hits optimizations like early termination on sorted indexes and
> WAND, when indexes are searched using multiple threads.
> 
> Congratulations and welcome! It is a tradition to introduce yourself
> with a brief bio.
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: Notes from the committers' meeting at Activate 2019