RE: Release Announcement: General Availability of Java 13 / JDK 13

[Uwe Schindler]

Hi Rory,

 

thanks for the reminder! I updated all Jenkins jobs to now use the GA build and 
I also updated the JDK 14-ea builds.

 

Thanks,

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Rory O'Donnell  
Sent: Tuesday, September 17, 2019 10:43 PM
To: uwe.h.schind...@gmail.com
Cc: rory.odonn...@oracle.com; Dalibor Topic ; 
Balchandra Vaidya ; Deepak Damodaran 
; Muneer Kolarkunnu 
; Dawid Weiss ; 
dev@lucene.apache.org
Subject: Release Announcement: General Availability of Java 13 / JDK 13

 

 Hi Uwe & Dawid, 

Release Announcement: General Availability of Java 13 / JDK 13 [1] 

*   JDK 13, the reference implementation of Java 13, is now Generally 
Available. 
*   GPL-licensed OpenJDK builds from Oracle are available here: 
https://jdk.java.net/13
*   Release notes - https://jdk.java.net/13/release-notes

This release includes the following five features: 

*   350: Dynamic CDS Archives
*   351: ZGC: Uncommit Unused Memory
*   353: Reimplement the Legacy Socket API
*   354: Switch Expressions (Preview)
*   355: Text Blocks (Preview)

Along with many smaller enhancements and bug fixes.

Thanks to everyone who contributed JDK 13, whether by creating features or 
enhancements, logging  bugs, or downloading and testing the early-access 
builds. 

JDK 14 EA build 14, under both the GPL and Oracle EA licenses, is now available 
at http://jdk.java.net/14 .

*   JEPs targeted to JDK 14, so far

*   352 - Non-Volatile Mapped Byte Buffers 
 

*   Release Notes 

*   https://jdk.java.net/14/release-notes

*   Recent Bug fixes of Interest

*   Build 14:

*   8229785: MethodType::fromMethodDescriptorString requires 
"getClassLoader" permission
*   8212117: Classes are now loaded and linked by Class.forName()
*   8228854: Default ErrorListener No Longer Reports Warnings and Errors to 
the Console 

*   Changes in this build 

  [14]

Quality Report for September 2019 is available

*   
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+September+2019

Rgds,Rory

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-September/003335.html




-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland

Re: The Lucene Solr Gradle Build Game plan

[Mark Miller]

On Wed, Sep 18, 2019 at 10:46 AM Dawid Weiss  wrote:

>
> > 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:


I find the Gradle way of doing things odd, but I knew better than to try
and go directly against them.

So none of this is really my choosing, I went with how you are supposed to
do it.

When it comes to allowing another prop file just for our project, I'm all
for it - just not the standard gradle.properties that is supposed to be
committed in a gradle project.

You cannot override any settings from your gradle home file regardless, so
it's a little non intuitive - gradle home props rule all.

Anyway, I have exposed like one of our properties, so no, it's not thought
out or how it's going to be at all. Probably that property should be name
spaced beyond tests_jvms (translated from tests.jvms), but then we might
want to support a short cut notation for command line.

Sucking in a user prop file like we do with ant sounds great, just have to
get used to the fact that you cannot override your global settings. Trying
to subvert that in some way def feels like a bad path.

Anyway, I've never found it to be a problem. I didn't expect everyone would
customize our project settings in their gradle home file, I usually put
stuff there that I want to apply to all my checkouts (tests.jvms is
actually one of them), but all that is very individual.

You can also set these on the command line - it's mostly the same as ant.
If you leave stuff out of your home gradle file and just add to some file
we suck in, ezpeasy. I haven't prescribed or enforced anything here.

There will be more/better getting started doc and more finished stuff the
closer we get.

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

I've been having plenty of issues with just regular tests. Gradle
statically assigns all tests in basically fs order to N JVMs. If you run
tests against all the Solr modules, it's pretty sweet because it doesn't
just use a few executors on the small modules and go a module at a time -
it does them together more and less and keeps things busy.
But running tests within a module, or even running all modules tests, was
no good. You have solr-core tests coming late, you have many tests that pop
up from short runs to minutes+ (often tests with many sub class tests), and
you have a static JVM assignment for each test. So basically, it's easy to
be running long tests at the end of a run and use few JVM's, and with our
tests, this can be devastating.
Now Dawids Ant test launcher tries to be a lot smarter about all this and
caches run times so that it can order tests and holds some back for idle
JVM's, etc. So I was looking at already very slow tests times on master
often being much worse on gradle depending on if you ran tests across
modules (which even the field a bit).
We are a terrible case for gradles parallel tests.

I figured I would improve tests times like usual to solve this as much as I
could, but it's really not enough - our project is too large, too many
tests, projects much smaller than our complain about this gradle issue.

Luckily though, the abstractions and code that runs tests is super simple.
So in the end, I made a new test target called testFast for now, and it's
mostly feature complete with the test target (extends the Test task) except
that it doesn't support rerunning just failed tests currently and doesn't
support looking for tests via reflection, just file inclusions / exclusion
regex.

It's really just simple logic changes of a pretty simple process and gives
us a lot of options. Of course we will leave gradles default test task in
place and this will be an alternate target.

The regular test task will find tests and send every single one in before
any ever get processed, so that is changed to start processing right away
instead (which is why the retry failed tests processor was taken out of the
chain). So testFast scans all the tests and puts them into normal, slow,
and slowest categories based on annotations. It shuffles those buckets and
sends the slowest to the JVMs first. Then we hold tests back if too many
are outstanding so that when we get towards the end, tests can go to idle
JVM's instead of lining up early not knowing if it's a very slow line. When
the tests hit the JVM's, instead of simple round robin, we look at how many
tests are already in line at each JVM and choose the shortest line or
shuffle.

So I started with solr-core generally taking 20+ minutes or more on my 18
core machine, and with some other simple test taming, testFail can now do
it in just 

Re: The Lucene Solr Gradle Build Game plan

[Chris Hostetter]

: 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

I gather from your comments (and from the link you mentioned in another 
question) that gradle does not have a direct equivilent of ant's...

  

...but some naive google searching suggests it's possible to do something 
similar using "apply from" to load in a *.gradle file using an arbitrary 
path, which could contain property declarations which would then evidently 
by overlayed on the existing groovy file? 
(maybe?)

Ex: this in our build.gradle file...

apply from: '$USER_HOME/lucene.properties.gradle'

...and this in my ~/lucene.properties.gradle file...

ext { 
test_jvms = 42
}

...would that work?


: > ("-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.

FWIW: I'm not sure if the deterministic ordering is that important --
although you reminded me that being able to *review* the list of tests 
that ran in the same JVM when a failure happens is helpful...

(i don't know that i've ever tried to rerun that exact list of every test 
that ran in the same JVM in the same order as what was reported -- or even 
how i would if i wanted to other then with a really fucking complicated 
-Dtests.class=... param)

I'd guess that 90% of the time when i currently use "-Dtests.jvms=1" it's 
when running a single test class with -Dtests.dups=N to confirm & fix 
shitty use of statics in BeforeClass/AfterClass methods (typically 
problematic if/when the jenkins [repro] target does something like 
-Dtests.dups=5 -DtestcaseSomeTestThatFailed but defaults to using 
tests.jvms=3, so we see 2/5 suite level failures that look nothing like 
whatever the original failure was that jenkins was attempting to 
reproduce)

the 10% of the time -- where that's not the issue, and a failure in one 
test really was caused byt some previous test in the same JVM mucking up 
some static variable state -- eyeballing the list of tests that also ran 
in that JVM usually helps narrow down the list of suspects, and then i 
just try beasting those 2 (or 3) tests together with "-Dtests.jvms=1", not 
worrying about the order and just trusting that if i'm right eventually 
they'll be run in the problematic order.


-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: Notes from the committers' meeting at Activate 2019

[Noble Paul]

My 2 sents
I like the workflow of PR and code review in github.
But, I still prefer JIRA and I don't want it to replace it with github issues

On Tue, Sep 17, 2019 at 5:57 AM Jan Høydahl  wrote:
>
> 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.
>
> Until then, I made a script that "diffs" GH and JIRA and outputs a report, 
> see 
> https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy
>
> Running the tool shows that we're not very successful in keeping the two in 
> sync, we also forget to close PRs after JIRAs are resolved:
>
> $ ./githubPRs.py
> Lucene/Solr Github PR report
> 
> Number of open Pull Requests: 208
>
> PRs lacking JIRA reference in title
>   #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
>   #880: Tweak header format.
>   [… many more ]
>
> Open PRs with a resolved JIRA
>   #723: SOLR-13545 status=Closed, resolution=Fixed, 
> resolutiondate=2019-06-22T13:04:47.000+ (SOLR-13545: AutoClose stream in 
> ContentStreamUpdateRequest)
>   #643: SOLR-13391 status=Resolved, resolution=Resolved, 
> resolutiondate=2019-04-12T14:09:27.000+ (SOLR-13391: Add variance and 
> standard deviation stream evaluators)
>   [… many more]
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki :
>
>
> On 16 Sep 2019, at 19:38, Yonik Seeley  wrote:
>
> >  - PR is opened - should automatically create a jira if it doesn’t exist yet
>
> What were the reasons behind this? Shouldn't a JIRA just be optional if we 
> started with a PR?
>
>
> That’s why we need to discuss this :)
>
> I remember that at some point ASF treated JIRA as the system of record for 
> the legal validation of contributions.
>
> I also remember that at some point we used to say that if a discussion didn’t 
> happen in JIRA then it didn’t exist, and that any decisions regarding code 
> should be recorded in JIRA because we can’t expect people to monitor and 
> contribute / object to decisions happening elsewhere.
>
> —
>
> Andrzej Białecki
>
>


-- 
-
Noble Paul

-
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

[Noble Paul]

First of all a big thanks to Cassandra to help coordinate and build
our ref guide to make it professional. It really used to be pathetic
before you took over

. Yes we need to avoid "creating work" . There should be no need for a
ref guide release.

+1 for your plan

On Thu, Sep 19, 2019 at 11:57 PM Cassandra Targett
 wrote:
>
> The pages do already have a “Site last generated” date on them at the bottom. 
> It’s specifically worded that way for a reason.
>
> We actually wanted the date the .adoc file was last updated to be in the 
> footer too, but the problem has always been that a static site generator 
> always regenerates all pages every time - so every single page, edited or 
> not, always has the same exact date on it.
>
> And, our build works by copying everything under `solr/solr-ref-guide/src` to 
> `solr/build`, so every file really has a create date and last updated date 
> that are always the date you do the build. Basically, the files you see and 
> work with are not actually the same files that get built - we build from 
> copies that are made at build-time.
>
> (That’s all why it says “Site last generated” instead of “Last updated”.)
>
> I’m not saying there’s no way to add a last updated date for the underlying 
> file, it’s just not obvious how to do it so we skipped it.
>
> No problem, though, adding a link to Github - that’s actually kind of a 
> different thing and I’m pretty sure we could do that right now.
>
> Cassandra
> On Sep 19, 2019, 7:07 AM -0500, Anshum Gupta , wrote:
>
> I agree that we should be able to fix mistakes, my only suggestion was that 
> those mistakes not be non-trivial. But the more I think about it, the more I 
> feel convinced about just publishing the updates - however, having a time 
> stamp on when the guide was last updated would be nice to have. Anything else 
> would require much more effort and I'm not sure it's worth it.
>
> On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter  
> wrote:
>>
>>
>> : > 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
>>
>> : 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,
>>
>> Yeah, there are a lot of options we could pursue for generating a
>> "changes" list as part of an automated build process -- but i would
>> consider this idea a "nice to have" feature that shouldn't block moving
>> forward.
>>
>> Given 2 options, I would much rather:
>>   a) have the ability to quickly/easily "fix" mistakes/ommisions in
>> "official X.y ref-guide" on our site and have it automatically republish,
>> w/o it being immediately obvious to users that a page may have changed
>> between yesterday and today.
>>   ... over ...
>>   b) *NOT* being able to re-publish at all just for the sake of users
>> knowing that the (incorrect) content they are reading is consistent
>> between yesterday and today.
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Anshum Gupta



-- 
-
Noble Paul

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

Re: Moving Lucene web site to git and .asf.yaml

[Jan Høydahl]

I just wanted to kickstart the discussion and let you know what exists, and 
INFRA just happens to support Pelican ootb.
Pelican also supports asciidoc through a plugin plugin 
https://github.com/getpelican/pelican-plugins/tree/master/asciidoc_reader, but 
our current web site is already in MD and I suppose it would be much quicker to 
just convert the pages into Pelican template syntax as is to complete the move 
to git, and then we could iterate from there. Jekyll would work too, but we'd 
need to provide the tooling and build infrastructure as well as rewrite all 
pages from md to asciidoc which suddenly becomes a quite much bigger project..

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

> 19. sep. 2019 kl. 15:39 skrev Cassandra Targett :
> 
> Sort of playing devil’s advocate for sake of discussion, why would we pick 
> Pelican static site generator over Jekyll static site generator which we 
> already use for the Ref Guide? Why would we stay with Markdown when we 
> already know that Asciidoc is a much more expressive markup language that we 
> already use for hundreds of pages of content?
> 
> I know nothing about Pelican - your mail is the first I heard of it - so 
> asking that really just as a way to get more info for why you prefer it.
> 
> Assuming we move to a world where something like the Ref Guide is simply 
> “website content”, I could see it becoming burdensome to generate HTML files 
> with 2 different systems in 2 different formats, etc. Is that a valid concern 
> or not something you’re worried about?
> 
> Cassandra
> On Sep 19, 2019, 3:33 AM -0500, Jan Høydahl , wrote:
>> Hi all,
>> 
>> INFRA announced a few weeks back a new self-serve mechanism .asf.yaml:
>> 
>> https://s.apache.org/asfyaml
>> 
>> As I understand it, the old forrest CMS built from svn will eventually go 
>> away
>> and this is the new shiny way to publish (and stage) project websites.
>> 
>> I propose that we start to play with .asf.yaml by first adding the file to 
>> change
>> our GitHub project description which now says "Mirror of Apache Lucene + 
>> Solr" :)
>> 
>> Next let's migrate our web site from the svn over to a new branch in our git 
>> repo.
>> We could choose to use the Pelican static site generator, and then 
>> stage/publish
>> the site automatically using .asf.yaml magic. Moving from forrest to Pelican
>> (https://blog.getpelican.com) will take some effort, but they are both based 
>> on
>> markdown and templating so should not be an impossible task :)
>> 
>> A positive site effect of moving our site to git could be that it gets 
>> easier to
>> dump our JavaDocs, RefGuide, future developer-Guides by simply committing 
>> html
>> files to the site git branch.
>> 
>> We should also design a new Lucene landing page but that's for another day...
>> 
>> --
>> 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

[Atri Sharma]

Thank you!

On Thu, Sep 19, 2019 at 2:04 PM Uwe Schindler  wrote:
>
> Welcome!
>
> Congratulations and I hope to work together with you in the future (although 
> I am a bit busy at the moment, so I have not much time).
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Adrien Grand 
> > Sent: Wednesday, September 18, 2019 9:12 AM
> > To: Lucene Dev 
> > Subject: Welcome Atri Sharma as Lucene/Solr committer
> >
> > 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

-
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

[Cassandra Targett]

The pages do already have a “Site last generated” date on them at the bottom. 
It’s specifically worded that way for a reason.

We actually wanted the date the .adoc file was last updated to be in the footer 
too, but the problem has always been that a static site generator always 
regenerates all pages every time - so every single page, edited or not, always 
has the same exact date on it.

And, our build works by copying everything under `solr/solr-ref-guide/src` to 
`solr/build`, so every file really has a create date and last updated date that 
are always the date you do the build. Basically, the files you see and work 
with are not actually the same files that get built - we build from copies that 
are made at build-time.

(That’s all why it says “Site last generated” instead of “Last updated”.)

I’m not saying there’s no way to add a last updated date for the underlying 
file, it’s just not obvious how to do it so we skipped it.

No problem, though, adding a link to Github - that’s actually kind of a 
different thing and I’m pretty sure we could do that right now.

Cassandra
On Sep 19, 2019, 7:07 AM -0500, Anshum Gupta , wrote:
> I agree that we should be able to fix mistakes, my only suggestion was that 
> those mistakes not be non-trivial. But the more I think about it, the more I 
> feel convinced about just publishing the updates - however, having a time 
> stamp on when the guide was last updated would be nice to have. Anything else 
> would require much more effort and I'm not sure it's worth it.
>
> > On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter  
> > wrote:
> > >
> > > : > 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
> > >
> > > : 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,
> > >
> > > Yeah, there are a lot of options we could pursue for generating a
> > > "changes" list as part of an automated build process -- but i would
> > > consider this idea a "nice to have" feature that shouldn't block moving
> > > forward.
> > >
> > > Given 2 options, I would much rather:
> > >   a) have the ability to quickly/easily "fix" mistakes/ommisions in
> > > "official X.y ref-guide" on our site and have it automatically republish,
> > > w/o it being immediately obvious to users that a page may have changed
> > > between yesterday and today.
> > >       ... over ...
> > >   b) *NOT* being able to re-publish at all just for the sake of users
> > > knowing that the (incorrect) content they are reading is consistent
> > > between yesterday and today.
> > >
> > >
> > > -Hoss
> > > http://www.lucidworks.com/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
>
>
> --
> Anshum Gupta

Re: Moving Lucene web site to git and .asf.yaml

[Cassandra Targett]

Sort of playing devil’s advocate for sake of discussion, why would we pick 
Pelican static site generator over Jekyll static site generator which we 
already use for the Ref Guide? Why would we stay with Markdown when we already 
know that Asciidoc is a much more expressive markup language that we already 
use for hundreds of pages of content?

I know nothing about Pelican - your mail is the first I heard of it - so asking 
that really just as a way to get more info for why you prefer it.

Assuming we move to a world where something like the Ref Guide is simply 
“website content”, I could see it becoming burdensome to generate HTML files 
with 2 different systems in 2 different formats, etc. Is that a valid concern 
or not something you’re worried about?

Cassandra
On Sep 19, 2019, 3:33 AM -0500, Jan Høydahl , wrote:
> Hi all,
>
> INFRA announced a few weeks back a new self-serve mechanism .asf.yaml:
>
> https://s.apache.org/asfyaml
>
> As I understand it, the old forrest CMS built from svn will eventually go away
> and this is the new shiny way to publish (and stage) project websites.
>
> I propose that we start to play with .asf.yaml by first adding the file to 
> change
> our GitHub project description which now says "Mirror of Apache Lucene + 
> Solr" :)
>
> Next let's migrate our web site from the svn over to a new branch in our git 
> repo.
> We could choose to use the Pelican static site generator, and then 
> stage/publish
> the site automatically using .asf.yaml magic. Moving from forrest to Pelican
> (https://blog.getpelican.com) will take some effort, but they are both based 
> on
> markdown and templating so should not be an impossible task :)
>
> A positive site effect of moving our site to git could be that it gets easier 
> to
> dump our JavaDocs, RefGuide, future developer-Guides by simply committing html
> files to the site git branch.
>
> We should also design a new Lucene landing page but that's for another day...
>
> --
> 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: Rethinking how we publish the Solr Ref Guide

[Anshum Gupta]

I agree that we should be able to fix mistakes, my only suggestion was that
those mistakes not be non-trivial. But the more I think about it, the more
I feel convinced about just publishing the updates - however, having a time
stamp on when the guide was last updated would be nice to have. Anything
else would require much more effort and I'm not sure it's worth it.

On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter 
wrote:

>
> : > 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
>
> : 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,
>
> Yeah, there are a lot of options we could pursue for generating a
> "changes" list as part of an automated build process -- but i would
> consider this idea a "nice to have" feature that shouldn't block moving
> forward.
>
> Given 2 options, I would much rather:
>   a) have the ability to quickly/easily "fix" mistakes/ommisions in
> "official X.y ref-guide" on our site and have it automatically republish,
> w/o it being immediately obvious to users that a page may have changed
> between yesterday and today.
>   ... over ...
>   b) *NOT* being able to re-publish at all just for the sake of users
> knowing that the (incorrect) content they are reading is consistent
> between yesterday and today.
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> 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

[Uwe Schindler]

Welcome!

Congratulations and I hope to work together with you in the future (although I 
am a bit busy at the moment, so I have not much time).

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Adrien Grand 
> Sent: Wednesday, September 18, 2019 9:12 AM
> To: Lucene Dev 
> Subject: Welcome Atri Sharma as Lucene/Solr committer
> 
> 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

Moving Lucene web site to git and .asf.yaml

[Jan Høydahl]

Hi all,

INFRA announced a few weeks back a new self-serve mechanism .asf.yaml:

https://s.apache.org/asfyaml

As I understand it, the old forrest CMS built from svn will eventually go away
and this is the new shiny way to publish (and stage) project websites.

I propose that we start to play with .asf.yaml by first adding the file to 
change
our GitHub project description which now says "Mirror of Apache Lucene + Solr" 
:)

Next let's migrate our web site from the svn over to a new branch in our git 
repo.
We could choose to use the Pelican static site generator, and then stage/publish
the site automatically using .asf.yaml magic. Moving from forrest to Pelican
(https://blog.getpelican.com) will take some effort, but they are both based on 
markdown and templating so should not be an impossible task :)

A positive site effect of moving our site to git could be that it gets easier to
dump our JavaDocs, RefGuide, future developer-Guides by simply committing html
files to the site git branch.

We should also design a new Lucene landing page but that's for another day...

--
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: [POLL] Should notifications of NEW Jira issues go to dev@?

[Uwe Schindler]

My vote:

> [ ] 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): ___

I am often not interested in all updates on existing issues, I just pick some 
of them. But as new issues need to be assigned to somebody, a mail to a 
separate list is a good idea.

I know, you can do this with mail filters matching "issue created", but sending 
the new issues to dev@ makes also a good way for an external person to figure 
out what's going on and to get an overview what is currently worked on.

A daily digest is also fine, although I am not sure how to implement this. 
Option (2) is easy, as we just have to add dev@lao in the notification scheme 
to the event "issue created". Plain simple.

Uwe


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