Re: [VOTE] Lucene logo contest, third time's a charm

[Dawid Weiss]

D. Binding.

Dawid

On Tue, Sep 1, 2020 at 10:21 PM Ryan Ernst  wrote:

> Dear Lucene and Solr developers!
>
> Sorry for the multiple threads. This should be the last one.
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. The second attempt [second-vote] yesterday had incorrect links
> for one of the submissions. I would like to call a new vote, now with more
> explicit instructions on how to vote, and corrected links.
>
> *Please read the following rules carefully* before submitting your vote.
>
> *Who can vote?*
>
> Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
>
>
> *How do I vote?*
> Votes can be cast simply by replying to this email. It is a ranked-choice
> vote [rank-choice-voting]. Multiple selections may be made, where the order
> of preference must be specified. If an entry gets more than half the votes,
> it is the winner. Otherwise, the entry with the lowest number of votes is
> removed, and the votes are retallied, taking into account the next
> preferred entry for those whose first entry was removed. This process
> repeats until there is a winner.
>
> The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> *Entries*
>
> The entries are as follows:
>
> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1]
>
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the
> linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
>
> [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1]
>
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2]
>
> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
> [C3]
>
> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
> [C4]
>
> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
> [C5]
>
> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
> [C6]
>
> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
> [C7]
>
> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
> [C8]
>
> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D]
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close about one
> week from today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
>
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [second-vote
> 
> ]
>
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
> [rank-choice-voting
> ]
> https://en.wikipedia.org/wiki/Instant-runoff_voting
>

master/gradle seems to expand JIRA IDs in documentation filepath references

[Alexandre Rafalovitch]

Hi,
I am doing some work in a branch named after JIRA and gradle refuses
to build because explands a variable and then seems to expand the
SOLR-XYZ in the path with the Jira link:

Specifically:
*[Lucene Documentation](${project.luceneDocUrl}/index.html) in
solr/site.index.template.md (or maybe the .xsl version)
becomes:
https://issues.apache.org/jira/browse/SOLR-14792)-velocity/lucene/build/documentation//index.html">Lucene
Documentation

The file path is:
/Users/arafalov/Projects/solr/working-branches/SOLR-14792-velocity/build

This is undesirable expanded part:
[SOLR-14792](https://issues.apache.org/jira/browse/SOLR-14792)

This does not happen on master branch, as it does not have that
pattern in the URL.

I can work around it for now by doing
./gradlew check -x :solr:checkBrokenLinks , though I don't know how
much I am shortcuting this way.

Regards,
   Alex.

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

Re: [VOTE] Lucene logo contest, third time's a charm

[Abu Abdullah]

A2, A1

Re: Annoying but harmless exceptions due to filepermissions when running tests

[Chris Hostetter]

: Hmmm, that’s kind of an dilemma then. Are you saying that 
: he test can see that the directory appears writable then tries
: to write to it then gets tripped up by the framework?
: 
: Seems to me that a test that tries to write, thinks it can and then
: can’t should fail anyway.
: 
: Well, I don’t think there are very many tests that have this problem
: anyway, so maybe I can examine them one-by-one and not 
: introduce new failures...

You keep using the phrase "the test" in the context of (trying to) create 
these directories ("userfiles" and "filestore") ... the "test CODE" isn't 
making any choices about trying to write those files -- the choice is 
being made by the "CoreContainer CODE".

These features were added with the explicit implementation choice to _TRY_ 
to write the "usersfiles" (and/or "filestore") directory to "solr home" IF 
POSSIBLE, and if so then enable a bunch of features -- if NOT then log a 
WARNing and don't enable those features.

So what you're seeing here isn't an artifact/result of any particular 
choices "a test" or "the test" makes -- it's a concious choice of the 
developer who added this feature to solr.  These WARN messages that show 
up in tests where the solr home dir isn't writable (which is actaully the 
vast majority of tests because of how the test framework works) are the 
same types of WARN messages that a "real" solr deployment might get if 
their solr home dir isn't wriable (ie: maybe the use ${solr.data.dir} to 
point to a diff drive).



: 
: > On Aug 31, 2020, at 1:29 PM, Chris Hostetter  
wrote:
: > 
: > 
: > Some tests "create" a new solr home dir and copy config files there, but 
: > you'll see this type of WARN logging for any test that just uses the test 
: > configs "in place" because of how the code is designed to _try_ and create 
: > a userfiles directory in the solr home if it's writable.
: > 
: > 
: > : Date: Sat, 29 Aug 2020 09:25:17 -0400
: > : From: Erick Erickson 
: > : Reply-To: dev@lucene.apache.org
: > : To: dev@lucene.apache.org
: > : Subject: Re: Annoying but harmless exceptions due to filepermissions when
: > : running tests
: > : 
: > : Well, as Uwe and I discussed offline, he’s right and I’m wrong.
: > : 
: > : In CoreContainer [364] there’s code like this:
: > : 
: > : Path userFilesPath = return solrHome.resolve("userfiles"); // TODO make 
configurable on cfg?
: > : try {
: > :   Files.createDirectories(userFilesPath); // does nothing if already 
exists
: > : } catch (Exception e) {
: > :   log.warn("Unable to create [{}].  Features requiring this directory may 
fail.", userFilesPath, e);
: > : }
: > : 
: > : So I assumed it would happen on most every test, at least in cloud mode. 
But when I tried to make it happen on a different test, there was no exception.
: > : 
: > : I’ll have to poke some more to see what’s really happening…
: > : 
: > : Never Mind….
: > : 
: > : > On Aug 29, 2020, at 8:59 AM, Uwe Schindler  wrote:
: > : > 
: > : > Hi,
: > : > 
: > : > this is a bug in the test! It should never ever modify files outside 
its sandbox. It should not even modify files in build directory. It is fully 
valid to reject those writes - has nothing to do with users, it's just 
forbidden by the test framework. Modifying this file is harmful, as it may 
affect later tests.
: > : > 
: > : > So the correct way is to copy those files to the solr container running 
inside test's sandbox. That's one of the main advantages of the Test sandbox: 
No write access anywhere outside the test, see policy file.
: > : > 
: > : > Uwe
: > : > 
: > : > -
: > : > Uwe Schindler
: > : > Achterdiek 19, D-28357 Bremen
: > : > https://www.thetaphi.de
: > : > eMail: u...@thetaphi.de
: > : > 
: > : >> -Original Message-
: > : >> From: Erick Erickson 
: > : >> Sent: Saturday, August 29, 2020 2:54 PM
: > : >> To: dev@lucene.apache.org
: > : >> Subject: Annoying but harmless exceptions due to filepermissions when 
running
: > : >> tests
: > : >> 
: > : >> These exceptions are handled in the code and don’t affect running 
tests, but
: > : >> they can be a distraction when trying to figure out what’s causing a 
failure.
: > : >> When CoreContainer is being initialized, these two paths get 
“Permission
: > : >> Denied” errors since they try to create directories/files.
: > : >> 
: > : >> java.security.AccessControlException: access denied 
("java.io.FilePermission"
: > : >> 
"/Users/Erick/apache/solrJiras/master/solr/core/build/resources/test/solr/filest
: > : >> ore" "write”)
: > : >> 
: > : >> java.security.AccessControlException: access denied 
("java.io.FilePermission"
: > : >> 
"/Users/Erick/apache/solrJiras/master/solr/core/build/resources/test/solr/userf
: > : >> iles" "write”)
: > : >> 
: > : >> In both cases, the code logs a warning like "Features requiring this 
directory
: > : >> may fail”.
: > : >> 
: > : >> “build” is permitted this way, so I guess gradle runs as some other 
user?
: > : >> 
: > : >> drwxr-xr-x  11 Erick  staff352 Aug 

Re: [VOTE] Lucene logo contest, third time's a charm

[Gus Heck]

A2, A1, D (binding)

On Tue, Sep 1, 2020 at 7:37 PM Varun Thacker  wrote:

> (non-binding)
> vote: A1, A2, D
>
> On Tue, Sep 1, 2020 at 1:21 PM Ryan Ernst  wrote:
>
>> Dear Lucene and Solr developers!
>>
>> Sorry for the multiple threads. This should be the last one.
>>
>> In February a contest was started to design a new logo for Lucene
>> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
>> some confusion on the rules, as well the request for one additional
>> submission. The second attempt [second-vote] yesterday had incorrect links
>> for one of the submissions. I would like to call a new vote, now with more
>> explicit instructions on how to vote, and corrected links.
>>
>> *Please read the following rules carefully* before submitting your vote.
>>
>> *Who can vote?*
>>
>> Anyone is welcome to cast a vote in support of their favorite
>> submission(s). Note that only PMC member's votes are binding. If you are a
>> PMC member, please indicate with your vote that the vote is binding, to
>> ease collection of votes. In tallying the votes, I will attempt to verify
>> only those marked as binding.
>>
>>
>> *How do I vote?*
>> Votes can be cast simply by replying to this email. It is a ranked-choice
>> vote [rank-choice-voting]. Multiple selections may be made, where the order
>> of preference must be specified. If an entry gets more than half the votes,
>> it is the winner. Otherwise, the entry with the lowest number of votes is
>> removed, and the votes are retallied, taking into account the next
>> preferred entry for those whose first entry was removed. This process
>> repeats until there is a winner.
>>
>> The entries are broken up by variants, since some entries have multiple
>> color or style variations. The entry identifiers are first a capital
>> letter, followed by a variation id (described with each entry below), if
>> applicable. As an example, if you prefer variant 1 of entry A, followed by
>> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
>> of entry B, the following should be in your reply:
>>
>> (binding)
>> vote: A1, A2, C3, D, B4e
>>
>> *Entries*
>>
>> The entries are as follows:
>>
>> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>>
>> [A1]
>> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>> [A2]
>> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>>
>> B. Submitted by Stamatis Zampetakis. This has several variants. Within
>> the linked entry there are 7 patterns and 7 color palettes. Any vote for B
>> should contain the pattern number followed by the lowercase letter of the
>> color palette. For example, B3e or B1a.
>>
>> [B]
>> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>>
>> C. Submitted by Baris Kazar. This entry has 8 variants.
>>
>> [C1]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>> [C2]
>> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
>> [C3]
>> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
>> [C4]
>> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
>> [C5]
>> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
>> [C6]
>> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
>> [C7]
>> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
>> [C8]
>> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>>
>> D. The current Lucene logo.
>>
>> [D]
>> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>>
>> Please vote for one of the above choices. This vote will close about one
>> week from today, Mon, Sept 7, 2020 at 11:59PM.
>>
>> Thanks!
>>
>> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
>> [first-vote]
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>> [second-vote]
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
>> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>>
>

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

Re: Approach towards solving split package issues?

[Gus Heck]

+1 to fixing and +1 to doing it in a major release.

On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand  wrote:

> +1 Changing packages of many classes should be done in a major.
>
> On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida 
> wrote:
>
>> Just to make sure, could I confirm "when the changes will be out"...
>> Resolving split package issues should break backward compatibility
>> (changing package names and moving classes from one module to another
>> modules). So we have just two options, we can have these changes only on
>> major releases - 9.0.0 or 10.0.0; we cannot release such changes at minor
>> versions. Is that correct?
>>
>> Tomoko
>>
>>
>> 2020年9月1日(火) 22:08 Tomoko Uchida :
>>
>>> > As I recall one issue was around where to put analysis packages?
>>>
>>> It's LUCENE-9317. I had worked on it before, you can see what changes
>>> will be needed for analyzers-common (and core).
>>>
>>>
>>> 2020年9月1日(火) 22:00 Michael Sokolov :
>>>
 I'm in favor - there may be some difficult choices though. As I recall
 one issue was around where to put analysis packages? I forget the
 details, but there was some pretty strong feeling that you should have
 a functioning system with core only. However some basic analysis tools
 are required for that, while most of our analyzers and so on are in a
 separate analysis module. Perhaps we will need to move some basic
 analyzers out of com.amazon.lucene.analysis? Or the reverse - move all
 the analysis code into the analysis module and acknowledge that it is
 a fundamental dependency (more essential than core, really).

 On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida
  wrote:
 >
 > yes, Jigsaw was on my mind too...
 >
 > > why not go ahead and try to clean it up right away?
 >
 > > So a strong +1 to clean this up!
 >
 > OK, maybe I should open two issues, one for Lucene and one for Solr,
 and link existing wip issues to them.
 > Once we start it, these will be blockers for 9.0.0 release I believe
 (for now I have no idea about the volume of the changes or technical
 obstacles). Are there any objections or comments?
 >
 >
 > 2020年9月1日(火) 19:34 Uwe Schindler :
 >>
 >> Hi,
 >>
 >> The biggest issue is that split packages make migrating to the Java
 9 module system impossible. It's not allowed to have same package name
 (with classes) in different JAR files.
 >>
 >> Some of those require to open up visibility of classes. Some split
 packages issues were done because of package private access, which is very
 bad between JAR files. This also affects the test framework, although this
 is not such a big deal (I would exclude that for now), because you would
 never run UNIT tests inside a module system, only integration tests.
 >>
 >> So a strong +1 to clean this up!
 >> Uwe
 >>
 >> -
 >> Uwe Schindler
 >> Achterdiek 19, D-28357 Bremen
 >> https://www.thetaphi.de
 >> eMail: u...@thetaphi.de
 >>
 >> > -Original Message-
 >> > From: Dawid Weiss 
 >> > Sent: Tuesday, September 1, 2020 9:22 AM
 >> > To: Lucene Dev 
 >> > Subject: Re: Approach towards solving split package issues?
 >> >
 >> > This is a big headache for many things. I wouldn't mind doing this
 >> > even for 9x. This is a major release, why not go ahead and try to
 >> > clean it up right away?
 >> >
 >> > Dawid
 >> >
 >> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
 >> >  wrote:
 >> > >
 >> > > Hello devs,
 >> > >
 >> > > we have lots of package name conflicts (shared package names)
 between
 >> > modules in the Lucene/Solr source tree. It is not only annoying
 for devs/users
 >> > but also indeed bad practice since Java 9 (according to my
 understanding), and
 >> > we already have some problems with Javadocs due to these splitted
 packages
 >> > as some of us would know. I'm curious about the issue from a while
 ago. My
 >> > questions are, Q1: How can we solve the issue in an organized way?
 Q2: How
 >> > many of us really have interests about that?
 >> > >
 >> > > To break down Q1,
 >> > > - A JIRA for building a grand design and organizing sub tasks is
 needed? We
 >> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about
 it and I
 >> > had been playing around them before; but I feel like an umbrella
 ticket would
 >> > be needed.
 >> > > - When to start and what's the target version to be out? My
 feeling is that
 >> > after cutting branch_9x is the right moment to start and 10.0.0 is
 suitable for
 >> > the target, does this make sense?
 >> > > - Are there any other tasks/concerns to be considered except for
 just
 >> > renaming packages?
 >> > >
 >> > > Regarding Q2,
 >> > > I know some of us have deep 

Re: [VOTE] Lucene logo contest, third time's a charm

[Varun Thacker]

(non-binding)
vote: A1, A2, D

On Tue, Sep 1, 2020 at 1:21 PM Ryan Ernst  wrote:

> Dear Lucene and Solr developers!
>
> Sorry for the multiple threads. This should be the last one.
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. The second attempt [second-vote] yesterday had incorrect links
> for one of the submissions. I would like to call a new vote, now with more
> explicit instructions on how to vote, and corrected links.
>
> *Please read the following rules carefully* before submitting your vote.
>
> *Who can vote?*
>
> Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
>
>
> *How do I vote?*
> Votes can be cast simply by replying to this email. It is a ranked-choice
> vote [rank-choice-voting]. Multiple selections may be made, where the order
> of preference must be specified. If an entry gets more than half the votes,
> it is the winner. Otherwise, the entry with the lowest number of votes is
> removed, and the votes are retallied, taking into account the next
> preferred entry for those whose first entry was removed. This process
> repeats until there is a winner.
>
> The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> *Entries*
>
> The entries are as follows:
>
> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1]
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the
> linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
>
> [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2]
> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
> [C3]
> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
> [C4]
> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
> [C5]
> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
> [C6]
> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
> [C7]
> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
> [C8]
> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D]
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close about one
> week from today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [second-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>

Re: [VOTE] Lucene logo contest, third time's a charm

[Ameer Albahem]

D

Regards
Ameer


On Wed, 2 Sep 2020 at 08:21, Steve Rowe  wrote:

> D (binding)
>
> --
> Steve
>
> > On Sep 1, 2020, at 4:21 PM, Ryan Ernst  wrote:
> >
> > Dear Lucene and Solr developers!
> >
> > Sorry for the multiple threads. This should be the last one.
> >
> > In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. The second attempt [second-vote] yesterday had incorrect links
> for one of the submissions. I would like to call a new vote, now with more
> explicit instructions on how to vote, and corrected links.
> >
> > Please read the following rules carefully before submitting your vote.
> >
> > Who can vote?
> >
> > Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
> >
> > How do I vote?
> >
> > Votes can be cast simply by replying to this email. It is a
> ranked-choice vote [rank-choice-voting]. Multiple selections may be made,
> where the order of preference must be specified. If an entry gets more than
> half the votes, it is the winner. Otherwise, the entry with the lowest
> number of votes is removed, and the votes are retallied, taking into
> account the next preferred entry for those whose first entry was removed.
> This process repeats until there is a winner.
> >
> > The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
> >
> > (binding)
> > vote: A1, A2, C3, D, B4e
> >
> > Entries
> >
> > The entries are as follows:
> >
> > A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
> >
> > [A1]
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> <
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> >
> > [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png <
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png>
> >
> > B. Submitted by Stamatis Zampetakis. This has several variants. Within
> the linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
> >
> > [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>  >
> >
> > C. Submitted by Baris Kazar. This entry has 8 variants.
> >
> > [C1]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> >
> > [C2]
> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
> >
> > [C3]
> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
> >
> > [C4]
> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
> >
> > [C5]
> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
> >
> > [C6]
> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
> >
> > [C7]
> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
> >
> > [C8]
> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
> <
> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
> >
> >
> > D. The current Lucene logo.
> >
> > [D]
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png <
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png>
> >
> > Please vote for one of the above choices. This vote will close about one
> week from today, Mon, Sept 7, 2020 at 11:59PM.
> >
> > Thanks!
> >
> > [jira-issue] 

Re: [VOTE] Lucene logo contest, third time's a charm

[Andi Vajda]

D (binding)

Andi..

> On Sep 1, 2020, at 12:21, Steve Rowe  wrote:
> 
> D (binding)
> 
> --
> Steve
> 
>> On Sep 1, 2020, at 4:21 PM, Ryan Ernst  wrote:
>> 
>> Dear Lucene and Solr developers!
>> 
>> Sorry for the multiple threads. This should be the last one.
>> 
>> In February a contest was started to design a new logo for Lucene 
>> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
>> some confusion on the rules, as well the request for one additional 
>> submission. The second attempt [second-vote] yesterday had incorrect links 
>> for one of the submissions. I would like to call a new vote, now with more 
>> explicit instructions on how to vote, and corrected links.
>> 
>> Please read the following rules carefully before submitting your vote.
>> 
>> Who can vote?
>> 
>> Anyone is welcome to cast a vote in support of their favorite submission(s). 
>> Note that only PMC member's votes are binding. If you are a PMC member, 
>> please indicate with your vote that the vote is binding, to ease collection 
>> of votes. In tallying the votes, I will attempt to verify only those marked 
>> as binding.
>> 
>> How do I vote?
>> 
>> Votes can be cast simply by replying to this email. It is a ranked-choice 
>> vote [rank-choice-voting]. Multiple selections may be made, where the order 
>> of preference must be specified. If an entry gets more than half the votes, 
>> it is the winner. Otherwise, the entry with the lowest number of votes is 
>> removed, and the votes are retallied, taking into account the next preferred 
>> entry for those whose first entry was removed. This process repeats until 
>> there is a winner.
>> 
>> The entries are broken up by variants, since some entries have multiple 
>> color or style variations. The entry identifiers are first a capital letter, 
>> followed by a variation id (described with each entry below), if applicable. 
>> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
>> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, 
>> the following should be in your reply:
>> 
>> (binding)
>> vote: A1, A2, C3, D, B4e
>> 
>> Entries
>> 
>> The entries are as follows:
>> 
>> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>> 
>> [A1] 
>> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>> 
>> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
>> linked entry there are 7 patterns and 7 color palettes. Any vote for B 
>> should contain the pattern number followed by the lowercase letter of the 
>> color palette. For example, B3e or B1a.
>> 
>> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>> 
>> C. Submitted by Baris Kazar. This entry has 8 variants.
>> 
>> [C1] 
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>> [C2] 
>> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
>> [C3] 
>> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
>> [C4] 
>> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
>> [C5] 
>> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
>> [C6] 
>> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
>> [C7] 
>> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
>> [C8] 
>> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>> 
>> D. The current Lucene logo.
>> 
>> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>> 
>> Please vote for one of the above choices. This vote will close about one 
>> week from today, Mon, Sept 7, 2020 at 11:59PM.
>> 
>> Thanks!
>> 
>> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
>> [first-vote] 
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>> [second-vote] 
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
>> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
> 

Re: [VOTE] Lucene logo contest, third time's a charm

[Steve Rowe]

D (binding)

--
Steve

> On Sep 1, 2020, at 4:21 PM, Ryan Ernst  wrote:
> 
> Dear Lucene and Solr developers!
> 
> Sorry for the multiple threads. This should be the last one.
> 
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. The second attempt [second-vote] yesterday had incorrect links 
> for one of the submissions. I would like to call a new vote, now with more 
> explicit instructions on how to vote, and corrected links.
> 
> Please read the following rules carefully before submitting your vote.
> 
> Who can vote?
> 
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
> 
> How do I vote?
> 
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
> 
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
> 
> (binding)
> vote: A1, A2, C3, D, B4e
> 
> Entries
> 
> The entries are as follows:
> 
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
> 
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>  
> 
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png 
> 
> 
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
> 
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf 
> 
> 
> C. Submitted by Baris Kazar. This entry has 8 variants.
> 
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>  
> 
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
>  
> 
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
>  
> 
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
>  
> 
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
>  
> 
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
>  
> 
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
>  
> 
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>  
> 
> 
> D. The current Lucene logo.
> 
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png 
> 
> 
> Please vote for one of the above choices. This vote will close about one week 
> from today, Mon, Sept 7, 2020 at 11:59PM.
> 
> Thanks!
> 
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 
> 
> [first-vote] 
> 

Re: [VOTE] Lucene logo contest, third time's a charm

[Aurélien MAZOYER]

A1 :-)

On Tue, Sep 1, 2020, 10:21 PM Ryan Ernst  wrote:

> Dear Lucene and Solr developers!
>
> Sorry for the multiple threads. This should be the last one.
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. The second attempt [second-vote] yesterday had incorrect links
> for one of the submissions. I would like to call a new vote, now with more
> explicit instructions on how to vote, and corrected links.
>
> *Please read the following rules carefully* before submitting your vote.
>
> *Who can vote?*
>
> Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
>
>
> *How do I vote?*
> Votes can be cast simply by replying to this email. It is a ranked-choice
> vote [rank-choice-voting]. Multiple selections may be made, where the order
> of preference must be specified. If an entry gets more than half the votes,
> it is the winner. Otherwise, the entry with the lowest number of votes is
> removed, and the votes are retallied, taking into account the next
> preferred entry for those whose first entry was removed. This process
> repeats until there is a winner.
>
> The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> *Entries*
>
> The entries are as follows:
>
> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1]
>
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the
> linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
>
> [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1]
>
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2]
>
> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
> [C3]
>
> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
> [C4]
>
> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
> [C5]
>
> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
> [C6]
>
> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
> [C7]
>
> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
> [C8]
>
> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D]
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close about one
> week from today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
>
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [second-vote
> 
> ]
>
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
> [rank-choice-voting
> ]
> https://en.wikipedia.org/wiki/Instant-runoff_voting
>

Re: [VOTE] Lucene logo contest, third time's a charm

[Houston Putman]

(non-binding)
vote: A1, A2, D

On Tue, Sep 1, 2020 at 4:31 PM Adrien Grand  wrote:

> A1, A2, D (binding)
>
> On Tue, Sep 1, 2020 at 10:21 PM Ryan Ernst  wrote:
>
>> Dear Lucene and Solr developers!
>>
>> Sorry for the multiple threads. This should be the last one.
>>
>> In February a contest was started to design a new logo for Lucene
>> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
>> some confusion on the rules, as well the request for one additional
>> submission. The second attempt [second-vote] yesterday had incorrect links
>> for one of the submissions. I would like to call a new vote, now with more
>> explicit instructions on how to vote, and corrected links.
>>
>> *Please read the following rules carefully* before submitting your vote.
>>
>> *Who can vote?*
>>
>> Anyone is welcome to cast a vote in support of their favorite
>> submission(s). Note that only PMC member's votes are binding. If you are a
>> PMC member, please indicate with your vote that the vote is binding, to
>> ease collection of votes. In tallying the votes, I will attempt to verify
>> only those marked as binding.
>>
>>
>> *How do I vote?*
>> Votes can be cast simply by replying to this email. It is a ranked-choice
>> vote [rank-choice-voting]. Multiple selections may be made, where the order
>> of preference must be specified. If an entry gets more than half the votes,
>> it is the winner. Otherwise, the entry with the lowest number of votes is
>> removed, and the votes are retallied, taking into account the next
>> preferred entry for those whose first entry was removed. This process
>> repeats until there is a winner.
>>
>> The entries are broken up by variants, since some entries have multiple
>> color or style variations. The entry identifiers are first a capital
>> letter, followed by a variation id (described with each entry below), if
>> applicable. As an example, if you prefer variant 1 of entry A, followed by
>> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
>> of entry B, the following should be in your reply:
>>
>> (binding)
>> vote: A1, A2, C3, D, B4e
>>
>> *Entries*
>>
>> The entries are as follows:
>>
>> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>>
>> [A1]
>> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>> [A2]
>> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>>
>> B. Submitted by Stamatis Zampetakis. This has several variants. Within
>> the linked entry there are 7 patterns and 7 color palettes. Any vote for B
>> should contain the pattern number followed by the lowercase letter of the
>> color palette. For example, B3e or B1a.
>>
>> [B]
>> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>>
>> C. Submitted by Baris Kazar. This entry has 8 variants.
>>
>> [C1]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>> [C2]
>> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
>> [C3]
>> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
>> [C4]
>> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
>> [C5]
>> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
>> [C6]
>> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
>> [C7]
>> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
>> [C8]
>> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>>
>> D. The current Lucene logo.
>>
>> [D]
>> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>>
>> Please vote for one of the above choices. This vote will close about one
>> week from today, Mon, Sept 7, 2020 at 11:59PM.
>>
>> Thanks!
>>
>> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
>> [first-vote]
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>> [second-vote]
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
>> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>>
>>
>>
>
> --
> Adrien
>
>
>

Re: Approach towards solving split package issues?

[Adrien Grand]

+1 Changing packages of many classes should be done in a major.

On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida 
wrote:

> Just to make sure, could I confirm "when the changes will be out"...
> Resolving split package issues should break backward compatibility
> (changing package names and moving classes from one module to another
> modules). So we have just two options, we can have these changes only on
> major releases - 9.0.0 or 10.0.0; we cannot release such changes at minor
> versions. Is that correct?
>
> Tomoko
>
>
> 2020年9月1日(火) 22:08 Tomoko Uchida :
>
>> > As I recall one issue was around where to put analysis packages?
>>
>> It's LUCENE-9317. I had worked on it before, you can see what changes
>> will be needed for analyzers-common (and core).
>>
>>
>> 2020年9月1日(火) 22:00 Michael Sokolov :
>>
>>> I'm in favor - there may be some difficult choices though. As I recall
>>> one issue was around where to put analysis packages? I forget the
>>> details, but there was some pretty strong feeling that you should have
>>> a functioning system with core only. However some basic analysis tools
>>> are required for that, while most of our analyzers and so on are in a
>>> separate analysis module. Perhaps we will need to move some basic
>>> analyzers out of com.amazon.lucene.analysis? Or the reverse - move all
>>> the analysis code into the analysis module and acknowledge that it is
>>> a fundamental dependency (more essential than core, really).
>>>
>>> On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida
>>>  wrote:
>>> >
>>> > yes, Jigsaw was on my mind too...
>>> >
>>> > > why not go ahead and try to clean it up right away?
>>> >
>>> > > So a strong +1 to clean this up!
>>> >
>>> > OK, maybe I should open two issues, one for Lucene and one for Solr,
>>> and link existing wip issues to them.
>>> > Once we start it, these will be blockers for 9.0.0 release I believe
>>> (for now I have no idea about the volume of the changes or technical
>>> obstacles). Are there any objections or comments?
>>> >
>>> >
>>> > 2020年9月1日(火) 19:34 Uwe Schindler :
>>> >>
>>> >> Hi,
>>> >>
>>> >> The biggest issue is that split packages make migrating to the Java 9
>>> module system impossible. It's not allowed to have same package name (with
>>> classes) in different JAR files.
>>> >>
>>> >> Some of those require to open up visibility of classes. Some split
>>> packages issues were done because of package private access, which is very
>>> bad between JAR files. This also affects the test framework, although this
>>> is not such a big deal (I would exclude that for now), because you would
>>> never run UNIT tests inside a module system, only integration tests.
>>> >>
>>> >> So a strong +1 to clean this up!
>>> >> Uwe
>>> >>
>>> >> -
>>> >> Uwe Schindler
>>> >> Achterdiek 19, D-28357 Bremen
>>> >> https://www.thetaphi.de
>>> >> eMail: u...@thetaphi.de
>>> >>
>>> >> > -Original Message-
>>> >> > From: Dawid Weiss 
>>> >> > Sent: Tuesday, September 1, 2020 9:22 AM
>>> >> > To: Lucene Dev 
>>> >> > Subject: Re: Approach towards solving split package issues?
>>> >> >
>>> >> > This is a big headache for many things. I wouldn't mind doing this
>>> >> > even for 9x. This is a major release, why not go ahead and try to
>>> >> > clean it up right away?
>>> >> >
>>> >> > Dawid
>>> >> >
>>> >> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
>>> >> >  wrote:
>>> >> > >
>>> >> > > Hello devs,
>>> >> > >
>>> >> > > we have lots of package name conflicts (shared package names)
>>> between
>>> >> > modules in the Lucene/Solr source tree. It is not only annoying for
>>> devs/users
>>> >> > but also indeed bad practice since Java 9 (according to my
>>> understanding), and
>>> >> > we already have some problems with Javadocs due to these splitted
>>> packages
>>> >> > as some of us would know. I'm curious about the issue from a while
>>> ago. My
>>> >> > questions are, Q1: How can we solve the issue in an organized way?
>>> Q2: How
>>> >> > many of us really have interests about that?
>>> >> > >
>>> >> > > To break down Q1,
>>> >> > > - A JIRA for building a grand design and organizing sub tasks is
>>> needed? We
>>> >> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it
>>> and I
>>> >> > had been playing around them before; but I feel like an umbrella
>>> ticket would
>>> >> > be needed.
>>> >> > > - When to start and what's the target version to be out? My
>>> feeling is that
>>> >> > after cutting branch_9x is the right moment to start and 10.0.0 is
>>> suitable for
>>> >> > the target, does this make sense?
>>> >> > > - Are there any other tasks/concerns to be considered except for
>>> just
>>> >> > renaming packages?
>>> >> > >
>>> >> > > Regarding Q2,
>>> >> > > I know some of us have deep knowledge and thoughts in this topic,
>>> but for
>>> >> > now I am not sure how many of you have the will to give help or
>>> take time for
>>> >> > that.
>>> >> > > It can't be a one-man effort. The more people understand and can
>>> 

Re: [VOTE] Lucene logo contest, third time's a charm

[Adrien Grand]

A1, A2, D (binding)

On Tue, Sep 1, 2020 at 10:21 PM Ryan Ernst  wrote:

> Dear Lucene and Solr developers!
>
> Sorry for the multiple threads. This should be the last one.
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. The second attempt [second-vote] yesterday had incorrect links
> for one of the submissions. I would like to call a new vote, now with more
> explicit instructions on how to vote, and corrected links.
>
> *Please read the following rules carefully* before submitting your vote.
>
> *Who can vote?*
>
> Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
>
>
> *How do I vote?*
> Votes can be cast simply by replying to this email. It is a ranked-choice
> vote [rank-choice-voting]. Multiple selections may be made, where the order
> of preference must be specified. If an entry gets more than half the votes,
> it is the winner. Otherwise, the entry with the lowest number of votes is
> removed, and the votes are retallied, taking into account the next
> preferred entry for those whose first entry was removed. This process
> repeats until there is a winner.
>
> The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> *Entries*
>
> The entries are as follows:
>
> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1]
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the
> linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
>
> [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2]
> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
> [C3]
> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
> [C4]
> https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
> [C5]
> https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
> [C6]
> https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
> [C7]
> https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
> [C8]
> https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D]
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close about one
> week from today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [second-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>


-- 
Adrien

[VOTE] Lucene logo contest, third time's a charm

[Ryan Ernst]

Dear Lucene and Solr developers!

Sorry for the multiple threads. This should be the last one.

In February a contest was started to design a new logo for Lucene
[jira-issue]. The initial attempt [first-vote] to call a vote resulted in
some confusion on the rules, as well the request for one additional
submission. The second attempt [second-vote] yesterday had incorrect links
for one of the submissions. I would like to call a new vote, now with more
explicit instructions on how to vote, and corrected links.

*Please read the following rules carefully* before submitting your vote.

*Who can vote?*

Anyone is welcome to cast a vote in support of their favorite
submission(s). Note that only PMC member's votes are binding. If you are a
PMC member, please indicate with your vote that the vote is binding, to
ease collection of votes. In tallying the votes, I will attempt to verify
only those marked as binding.


*How do I vote?*
Votes can be cast simply by replying to this email. It is a ranked-choice
vote [rank-choice-voting]. Multiple selections may be made, where the order
of preference must be specified. If an entry gets more than half the votes,
it is the winner. Otherwise, the entry with the lowest number of votes is
removed, and the votes are retallied, taking into account the next
preferred entry for those whose first entry was removed. This process
repeats until there is a winner.

The entries are broken up by variants, since some entries have multiple
color or style variations. The entry identifiers are first a capital
letter, followed by a variation id (described with each entry below), if
applicable. As an example, if you prefer variant 1 of entry A, followed by
variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
of entry B, the following should be in your reply:

(binding)
vote: A1, A2, C3, D, B4e

*Entries*

The entries are as follows:

A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.

[A1]
https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
[A2]
https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png

B. Submitted by Stamatis Zampetakis. This has several variants. Within the
linked entry there are 7 patterns and 7 color palettes. Any vote for B
should contain the pattern number followed by the lowercase letter of the
color palette. For example, B3e or B1a.

[B]
https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf

C. Submitted by Baris Kazar. This entry has 8 variants.

[C1]
https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
[C2]
https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
[C3]
https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
[C4]
https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
[C5]
https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
[C6]
https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
[C7]
https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
[C8]
https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf

D. The current Lucene logo.

[D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png

Please vote for one of the above choices. This vote will close about one
week from today, Mon, Sept 7, 2020 at 11:59PM.

Thanks!

[jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
[first-vote]
http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
[second-vote]
http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
[rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting

Re: [VOTE] Lucene logo contest, here we go again

[Ryan Ernst]

dev@ got dropped from this, including the note here as well

On Tue, Sep 1, 2020 at 12:15 PM Ryan Ernst  wrote:

> Apologies Baris, I messed up the links because I copied the first of
> your links, and then replaced the number, thinking that would work
> correctly. But..computers.
>
> To ensure fairness, I will restart the vote, in just a few minutes.
>
> THIS VOTE IS CLOSED.
> Please see the new vote thread coming.
>
> On Tue, Sep 1, 2020 at 11:20 AM  wrote:
>
>> Hi,-
>>
>>   i am afraid this voting should be redone again as all of C's are the
>> same.
>>
>> I hope i am not doing something wrong. when i download each C candidate,
>> i see the same thing.
>>
>> I wonder why nobody said anything, am i doing something wrong here?
>>
>> Best regards
>>
>>
>> On 8/31/20 8:26 PM, Ryan Ernst wrote:
>> > Dear Lucene and Solr developers!
>> >
>> > In February a contest was started to design a new logo for Lucene
>> > [jira-issue]. The initial attempt [first-vote] to call a vote resulted
>> in
>> > some confusion on the rules, as well the request for one additional
>> > submission. I would like to call a new vote, now with more explicit
>> > instructions on how to vote.
>> >
>> > *Please read the following rules carefully* before submitting your vote.
>> >
>> > *Who can vote?*
>> >
>> > Anyone is welcome to cast a vote in support of their favorite
>> > submission(s). Note that only PMC member's votes are binding. If you
>> are a
>> > PMC member, please indicate with your vote that the vote is binding, to
>> > ease collection of votes. In tallying the votes, I will attempt to
>> verify
>> > only those marked as binding.
>> >
>> >
>> > *How do I vote?*
>> > Votes can be cast simply by replying to this email. It is a
>> ranked-choice
>> > vote [rank-choice-voting]. Multiple selections may be made, where the
>> order
>> > of preference must be specified. If an entry gets more than half the
>> votes,
>> > it is the winner. Otherwise, the entry with the lowest number of votes
>> is
>> > removed, and the votes are retallied, taking into account the next
>> > preferred entry for those whose first entry was removed. This process
>> > repeats until there is a winner.
>> >
>> > The entries are broken up by variants, since some entries have multiple
>> > color or style variations. The entry identifiers are first a capital
>> > letter, followed by a variation id (described with each entry below), if
>> > applicable. As an example, if you prefer variant 1 of entry A, followed
>> by
>> > variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant
>> 4e
>> > of entry B, the following should be in your reply:
>> >
>> > (binding)
>> > vote: A1, A2, C3, D, B4e
>> >
>> > *Entries*
>> >
>> > The entries are as follows:
>> >
>> > A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>> >
>> > [A1]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/12999548/Screen*20Shot*202020-04-10*20at*208.29.32*20AM.png__;JSUlJSU!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18JguMoPrRMw$
>> > [A2]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png__;!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18JgsWXGG_HQ$
>> >
>> > B. Submitted by Stamatis Zampetakis. This has several variants. Within
>> the
>> > linked entry there are 7 patterns and 7 color palettes. Any vote for B
>> > should contain the pattern number followed by the lowercase letter of
>> the
>> > color palette. For example, B3e or B1a.
>> >
>> > [B]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf__;!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18JgvPMUvwrQ$
>> >
>> > C. Submitted by Baris Kazar. This entry has 8 variants.
>> >
>> > [C1]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf__;!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18JgtoX1z6Yg$
>> > [C2]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf__;!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18JgtpAnIVGg$
>> > [C3]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf__;!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18JgsyPALnew$
>> > [C4]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf__;!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18Jgvd5JwhBA$
>> > [C5]
>> >
>> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf__;!!GqivPVa7Brio!JgXZ50SROMPIvwQUnc6YZqLl0mBhVxdDyqRU8SwN7lRfSROEh7KwzR18JgtP0Ld2BA$
>> > [C6]
>> >
>> 

Re: SIP-10: Solr 9 examples: Can we use Ref Guide as a dogfood example?

[Alexandre Rafalovitch]

That Jeopardy set reads very dubious. Content that was collected by
scraping and available on various sharing sites (including Mega!). I
would not feel comfortable working with that in our context.

There are other dataset sources. I like the ones that Data is Plural
newsletter collects: https://tinyletter.com/data-is-plural (full list
at: 
https://docs.google.com/spreadsheets/d/1wZhPLMCHKJvwOkP4juclhjFgqIY8fQFMemwKL2c64vk/edit#gid=0
). Again, copyright is important and I think having a local copy is
important too, for at least tutorial purposes.

But I wish we could figure out a way to include the RefGuide. It is
just so much more triple-bottom line solution than just random other
dataset. We could do a graph of cross-references in the guide, figure
out how to extract java path references, etc.

Anyway, it is not something that is super-urgent. I don't even know
whether our new build processes can be augmented to do this. I guess
it is a bit similar to how we run tests.

I just wanted to get a strong yay/nay on the idea. So far it feels
like I got one strong yay, one caution and one soft nay.

Regards,
   Alex.



On Tue, 1 Sep 2020 at 12:28, Jan Høydahl  wrote:
>
> What about 200.000 Jeopardy questions in JSON format?
> https://www.reddit.com/r/datasets/comments/1uyd0t/20_jeopardy_questions_in_a_json_file/
> I downloaded the file in a few seconds, and it also has some structured 
> content, e.g.
>
>   {
> "category": "NOVELS",
> "air_date": "2005-01-27",
> "question": "'Even the epilogue is lengthy in this 1869 Tolstoy epic; it 
> comes out in 2 parts &, in our copy, is 105 pages long'",
> "value": "$400",
> "answer": "War and Peace",
> "round": "Jeopardy!",
> "show_number": "4699"
>   },
>   {
> "category": "BRIGHT IDEAS",
> "air_date": "2005-01-27",
> "question": "'In 1948 scientists at Bristol-Meyers \"buffered\" this 
> medicine for the first time'",
> "value": "$400",
> "answer": "aspirin",
> "round": "Jeopardy!",
> "show_number": "4699"
>   },
>
> Lots of docs. Enough free-text to learn some analysis, enough metadata for 
> some meaningful facets / filters…
>
> As long as we only provide a URL and not re-distribute the content, licensing 
> is less of a concern.
>
> Jan
>
> 1. sep. 2020 kl. 15:59 skrev Alexandre Rafalovitch :
>
> I've thought of providing instructions. But for good indexing, we
> should use adoc format as source, rather than html (as Cassandra's
> presentation showed), so that means dependencies to build by user to
> get asciidoctor library. And the way to get content, so either git
> clone or download the whole source and unpack and figure out the
> directory locations. It feels messy. Then, it may as well be an
> external package or even an external independent project. And
> therefore, it would lose value as a shipped tutorial material.
>
> We could also discuss actually shipping the Solr Reference Guide with
> Solr now that the release cycles align, but that would actually not
> help my sub-project too much, again because of adoc vs. html formats.
>
> In terms of other datasets:
> *) I could just stay with limited full-text in the one I am thinking
> of. The bulk download mode allows for fields such as Occupation,
> Company and Vehicle model which are 2-7 words long. That's about the
> same length as current examples we ship. It does not allow for a
> meaningful discussion about longer-text issues such as
> length-normalization, but we don't have those now anyway.
> *) I could use a public domain book and break it into parts. From
> somewhere like https://standardebooks.org/ . But there is a question
> about licensing and also whether we will be able to show interesting
> effects with that.
> *) I was also told that there is Wikipedia, but again, would we just
> include a couple of articles at random? What's the license?
> *) It is possible to index Stack Overflow questions, either from the
> feed (DIH was doing that) or as a download. I think the license was
> compatible.
> *) I could augment the dataset with some mix of the above, like a
> "favourite quote" field with random book sentences. This feels like
> fun, but possibly a whole separate project of its own.
>
> Anyway, I am open to further thoughts. It is quite likely I missed something.
>
> Regards,
>   Alex.
>
> T
>
> On Tue, 1 Sep 2020 at 03:10, Jan Høydahl  wrote:
>
>
> I’d rather ship a tutorial and tooling that explains how to index the 
> ref-guide, than shipping a binary index.
> What other full-text datasets have you considered as candidates for 
> getting-started examples?
>
> Jan
>
> 1. sep. 2020 kl. 05:53 skrev Alexandre Rafalovitch :
>
> I did not say it was trivial, but I also did not quite mention the previous 
> research.
>
> https://github.com/arafalov/solr-refguide-indexing/blob/master/src/com/solrstart/refguide/Indexer.java
>
> Uses official AsciidoctorJ library directory. Not sure if that's just JRuby 
> version of Asciidoctor we currently 

Re: SIP-10: Solr 9 examples: Can we use Ref Guide as a dogfood example?

[Jan Høydahl]

What about 200.000 Jeopardy questions in JSON format?
https://www.reddit.com/r/datasets/comments/1uyd0t/20_jeopardy_questions_in_a_json_file/
 

I downloaded the file in a few seconds, and it also has some structured 
content, e.g.

  {
"category": "NOVELS",
"air_date": "2005-01-27",
"question": "'Even the epilogue is lengthy in this 1869 Tolstoy epic; it 
comes out in 2 parts &, in our copy, is 105 pages long'",
"value": "$400",
"answer": "War and Peace",
"round": "Jeopardy!",
"show_number": "4699"
  },
  {
"category": "BRIGHT IDEAS",
"air_date": "2005-01-27",
"question": "'In 1948 scientists at Bristol-Meyers \"buffered\" this 
medicine for the first time'",
"value": "$400",
"answer": "aspirin",
"round": "Jeopardy!",
"show_number": "4699"
  },

Lots of docs. Enough free-text to learn some analysis, enough metadata for some 
meaningful facets / filters…

As long as we only provide a URL and not re-distribute the content, licensing 
is less of a concern.

Jan

> 1. sep. 2020 kl. 15:59 skrev Alexandre Rafalovitch :
> 
> I've thought of providing instructions. But for good indexing, we
> should use adoc format as source, rather than html (as Cassandra's
> presentation showed), so that means dependencies to build by user to
> get asciidoctor library. And the way to get content, so either git
> clone or download the whole source and unpack and figure out the
> directory locations. It feels messy. Then, it may as well be an
> external package or even an external independent project. And
> therefore, it would lose value as a shipped tutorial material.
> 
> We could also discuss actually shipping the Solr Reference Guide with
> Solr now that the release cycles align, but that would actually not
> help my sub-project too much, again because of adoc vs. html formats.
> 
> In terms of other datasets:
> *) I could just stay with limited full-text in the one I am thinking
> of. The bulk download mode allows for fields such as Occupation,
> Company and Vehicle model which are 2-7 words long. That's about the
> same length as current examples we ship. It does not allow for a
> meaningful discussion about longer-text issues such as
> length-normalization, but we don't have those now anyway.
> *) I could use a public domain book and break it into parts. From
> somewhere like https://standardebooks.org/ . But there is a question
> about licensing and also whether we will be able to show interesting
> effects with that.
> *) I was also told that there is Wikipedia, but again, would we just
> include a couple of articles at random? What's the license?
> *) It is possible to index Stack Overflow questions, either from the
> feed (DIH was doing that) or as a download. I think the license was
> compatible.
> *) I could augment the dataset with some mix of the above, like a
> "favourite quote" field with random book sentences. This feels like
> fun, but possibly a whole separate project of its own.
> 
> Anyway, I am open to further thoughts. It is quite likely I missed something.
> 
> Regards,
>   Alex.
> 
> T
> 
> On Tue, 1 Sep 2020 at 03:10, Jan Høydahl  wrote:
>> 
>> I’d rather ship a tutorial and tooling that explains how to index the 
>> ref-guide, than shipping a binary index.
>> What other full-text datasets have you considered as candidates for 
>> getting-started examples?
>> 
>> Jan
>> 
>> 1. sep. 2020 kl. 05:53 skrev Alexandre Rafalovitch :
>> 
>> I did not say it was trivial, but I also did not quite mention the previous 
>> research.
>> 
>> https://github.com/arafalov/solr-refguide-indexing/blob/master/src/com/solrstart/refguide/Indexer.java
>> 
>> Uses official AsciidoctorJ library directory. Not sure if that's just JRuby 
>> version of Asciidoctor we currently use to build. But this should only 
>> affect the development process, not the final built package.
>> 
>> I think I am more trying to figure out what people think about shipping an 
>> actual core with the distribution. That is something I haven't seen done 
>> before. And may have issues I did not think of.
>> 
>> Regards,
>>Alex
>> 
>> On Mon., Aug. 31, 2020, 10:11 p.m. Gus Heck,  wrote:
>>> 
>>> Some background to consider before committing to that... it might not be as 
>>> trivial as you think. (I've often thought it ironic that we don't have real 
>>> search for our ref guide... )
>>> 
>>> https://www.youtube.com/watch?v=DixlnxAk08s
>>> 
>>> -Gus
>>> 
>>> On Mon, Aug 31, 2020 at 2:06 PM Ishan Chattopadhyaya 
>>>  wrote:
 
 I love the idea of making the ref guide itself as an example dataset. That 
 way, we won't need to ship anything separately. Python's beautiful soup 
 can extract text from the html pages. I'm sure there maybe such things in 
 Java too (can Tika do this?).
 
 On Mon, 31 Aug, 2020, 11:18 pm Alexandre Rafalovitch,  
 wrote:
> 
> Hi,
> I 

Re: [VOTE] Lucene logo contest, here we go again

[Houston Putman]

A1, A2, D (non-binding)

On Tue, Sep 1, 2020 at 11:28 AM Steve Rowe  wrote:

> D (binding)
>
> --
> Steve
>
> On Aug 31, 2020, at 8:26 PM, Ryan Ernst  wrote:
>
> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. I would like to call a new vote, now with more explicit
> instructions on how to vote.
>
> *Please read the following rules carefully* before submitting your vote.
>
> *Who can vote?*
>
> Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
>
>
> *How do I vote?*
> Votes can be cast simply by replying to this email. It is a ranked-choice
> vote [rank-choice-voting]. Multiple selections may be made, where the order
> of preference must be specified. If an entry gets more than half the votes,
> it is the winner. Otherwise, the entry with the lowest number of votes is
> removed, and the votes are retallied, taking into account the next
> preferred entry for those whose first entry was removed. This process
> repeats until there is a winner.
>
> The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> *Entries*
>
> The entries are as follows:
>
> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1]
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the
> linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
>
> [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> [C3]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> [C4]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> [C5]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> [C6]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> [C7]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> [C8]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D]
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close one week
> from today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>
>
>

Re: Approach towards solving split package issues?

[Tomoko Uchida]

Just to make sure, could I confirm "when the changes will be out"...
Resolving split package issues should break backward compatibility
(changing package names and moving classes from one module to another
modules). So we have just two options, we can have these changes only on
major releases - 9.0.0 or 10.0.0; we cannot release such changes at minor
versions. Is that correct?

Tomoko


2020年9月1日(火) 22:08 Tomoko Uchida :

> > As I recall one issue was around where to put analysis packages?
>
> It's LUCENE-9317. I had worked on it before, you can see what changes will
> be needed for analyzers-common (and core).
>
>
> 2020年9月1日(火) 22:00 Michael Sokolov :
>
>> I'm in favor - there may be some difficult choices though. As I recall
>> one issue was around where to put analysis packages? I forget the
>> details, but there was some pretty strong feeling that you should have
>> a functioning system with core only. However some basic analysis tools
>> are required for that, while most of our analyzers and so on are in a
>> separate analysis module. Perhaps we will need to move some basic
>> analyzers out of com.amazon.lucene.analysis? Or the reverse - move all
>> the analysis code into the analysis module and acknowledge that it is
>> a fundamental dependency (more essential than core, really).
>>
>> On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida
>>  wrote:
>> >
>> > yes, Jigsaw was on my mind too...
>> >
>> > > why not go ahead and try to clean it up right away?
>> >
>> > > So a strong +1 to clean this up!
>> >
>> > OK, maybe I should open two issues, one for Lucene and one for Solr,
>> and link existing wip issues to them.
>> > Once we start it, these will be blockers for 9.0.0 release I believe
>> (for now I have no idea about the volume of the changes or technical
>> obstacles). Are there any objections or comments?
>> >
>> >
>> > 2020年9月1日(火) 19:34 Uwe Schindler :
>> >>
>> >> Hi,
>> >>
>> >> The biggest issue is that split packages make migrating to the Java 9
>> module system impossible. It's not allowed to have same package name (with
>> classes) in different JAR files.
>> >>
>> >> Some of those require to open up visibility of classes. Some split
>> packages issues were done because of package private access, which is very
>> bad between JAR files. This also affects the test framework, although this
>> is not such a big deal (I would exclude that for now), because you would
>> never run UNIT tests inside a module system, only integration tests.
>> >>
>> >> So a strong +1 to clean this up!
>> >> Uwe
>> >>
>> >> -
>> >> Uwe Schindler
>> >> Achterdiek 19, D-28357 Bremen
>> >> https://www.thetaphi.de
>> >> eMail: u...@thetaphi.de
>> >>
>> >> > -Original Message-
>> >> > From: Dawid Weiss 
>> >> > Sent: Tuesday, September 1, 2020 9:22 AM
>> >> > To: Lucene Dev 
>> >> > Subject: Re: Approach towards solving split package issues?
>> >> >
>> >> > This is a big headache for many things. I wouldn't mind doing this
>> >> > even for 9x. This is a major release, why not go ahead and try to
>> >> > clean it up right away?
>> >> >
>> >> > Dawid
>> >> >
>> >> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
>> >> >  wrote:
>> >> > >
>> >> > > Hello devs,
>> >> > >
>> >> > > we have lots of package name conflicts (shared package names)
>> between
>> >> > modules in the Lucene/Solr source tree. It is not only annoying for
>> devs/users
>> >> > but also indeed bad practice since Java 9 (according to my
>> understanding), and
>> >> > we already have some problems with Javadocs due to these splitted
>> packages
>> >> > as some of us would know. I'm curious about the issue from a while
>> ago. My
>> >> > questions are, Q1: How can we solve the issue in an organized way?
>> Q2: How
>> >> > many of us really have interests about that?
>> >> > >
>> >> > > To break down Q1,
>> >> > > - A JIRA for building a grand design and organizing sub tasks is
>> needed? We
>> >> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it
>> and I
>> >> > had been playing around them before; but I feel like an umbrella
>> ticket would
>> >> > be needed.
>> >> > > - When to start and what's the target version to be out? My
>> feeling is that
>> >> > after cutting branch_9x is the right moment to start and 10.0.0 is
>> suitable for
>> >> > the target, does this make sense?
>> >> > > - Are there any other tasks/concerns to be considered except for
>> just
>> >> > renaming packages?
>> >> > >
>> >> > > Regarding Q2,
>> >> > > I know some of us have deep knowledge and thoughts in this topic,
>> but for
>> >> > now I am not sure how many of you have the will to give help or take
>> time for
>> >> > that.
>> >> > > It can't be a one-man effort. The more people understand and can
>> contribute
>> >> > to the build, the more healthy it will be. (I borrowed this phrase
>> from Gradle
>> >> > build issue LUCENE-9077).
>> >> > >
>> >> > > I don't intend to rush into making a decision, my purpose here is
>> to collect
>> >> > 

Re: [VOTE] Lucene logo contest, here we go again

[Steve Rowe]

D (binding)

--
Steve

> On Aug 31, 2020, at 8:26 PM, Ryan Ernst  wrote:
> 
> Dear Lucene and Solr developers!
> 
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. I would like to call a new vote, now with more explicit 
> instructions on how to vote.
> 
> Please read the following rules carefully before submitting your vote.
> 
> Who can vote?
> 
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
> 
> How do I vote?
> 
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
> 
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
> 
> (binding)
> vote: A1, A2, C3, D, B4e
> 
> Entries
> 
> The entries are as follows:
> 
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
> 
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>  
> 
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png 
> 
> 
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
> 
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf 
> 
> 
> C. Submitted by Baris Kazar. This entry has 8 variants.
> 
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>  
> 
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
>  
> 
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
>  
> 
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
>  
> 
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
>  
> 
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
>  
> 
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
>  
> 
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>  
> 
> 
> D. The current Lucene logo.
> 
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png 
> 
> 
> Please vote for one of the above choices. This vote will close one week from 
> today, Mon, Sept 7, 2020 at 11:59PM.
> 
> Thanks!
> 
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 
> 
> [first-vote] 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>  
> 

Remove ExternalFileField?

[Erick Erickson]

Is this another thing we really should remove? What use-cases are served by 
this that are _not_ served by updating SV numeric values?
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 90 - Failure!

[Uwe Schindler]

That's the issue:

> Task :validateSourcePatterns
tabs instead spaces: solr/bin/solr.cmd

> Task :validateSourcePatterns FAILED

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

> -Original Message-
> From: Apache Jenkins Server 
> Sent: Tuesday, September 1, 2020 5:01 PM
> To: bui...@lucene.apache.org
> Subject: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 90 - Failure!
> 
> Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-
> master/90/
> 
> All tests passed
> 
> Build Log:
> [...truncated 1543 lines...]
> BUILD FAILED in 1h 5m 58s
> 838 actionable tasks: 838 executed
> Build step 'Invoke Gradle script' changed build result to FAILURE
> Build step 'Invoke Gradle script' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any


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

Re: SIP-10: Solr 9 examples: Can we use Ref Guide as a dogfood example?

[Alexandre Rafalovitch]

I've thought of providing instructions. But for good indexing, we
should use adoc format as source, rather than html (as Cassandra's
presentation showed), so that means dependencies to build by user to
get asciidoctor library. And the way to get content, so either git
clone or download the whole source and unpack and figure out the
directory locations. It feels messy. Then, it may as well be an
external package or even an external independent project. And
therefore, it would lose value as a shipped tutorial material.

We could also discuss actually shipping the Solr Reference Guide with
Solr now that the release cycles align, but that would actually not
help my sub-project too much, again because of adoc vs. html formats.

In terms of other datasets:
*) I could just stay with limited full-text in the one I am thinking
of. The bulk download mode allows for fields such as Occupation,
Company and Vehicle model which are 2-7 words long. That's about the
same length as current examples we ship. It does not allow for a
meaningful discussion about longer-text issues such as
length-normalization, but we don't have those now anyway.
*) I could use a public domain book and break it into parts. From
somewhere like https://standardebooks.org/ . But there is a question
about licensing and also whether we will be able to show interesting
effects with that.
*) I was also told that there is Wikipedia, but again, would we just
include a couple of articles at random? What's the license?
*) It is possible to index Stack Overflow questions, either from the
feed (DIH was doing that) or as a download. I think the license was
compatible.
*) I could augment the dataset with some mix of the above, like a
"favourite quote" field with random book sentences. This feels like
fun, but possibly a whole separate project of its own.

Anyway, I am open to further thoughts. It is quite likely I missed something.

Regards,
   Alex.

T

On Tue, 1 Sep 2020 at 03:10, Jan Høydahl  wrote:
>
> I’d rather ship a tutorial and tooling that explains how to index the 
> ref-guide, than shipping a binary index.
> What other full-text datasets have you considered as candidates for 
> getting-started examples?
>
> Jan
>
> 1. sep. 2020 kl. 05:53 skrev Alexandre Rafalovitch :
>
> I did not say it was trivial, but I also did not quite mention the previous 
> research.
>
> https://github.com/arafalov/solr-refguide-indexing/blob/master/src/com/solrstart/refguide/Indexer.java
>
> Uses official AsciidoctorJ library directory. Not sure if that's just JRuby 
> version of Asciidoctor we currently use to build. But this should only affect 
> the development process, not the final built package.
>
> I think I am more trying to figure out what people think about shipping an 
> actual core with the distribution. That is something I haven't seen done 
> before. And may have issues I did not think of.
>
> Regards,
> Alex
>
> On Mon., Aug. 31, 2020, 10:11 p.m. Gus Heck,  wrote:
>>
>> Some background to consider before committing to that... it might not be as 
>> trivial as you think. (I've often thought it ironic that we don't have real 
>> search for our ref guide... )
>>
>> https://www.youtube.com/watch?v=DixlnxAk08s
>>
>> -Gus
>>
>> On Mon, Aug 31, 2020 at 2:06 PM Ishan Chattopadhyaya 
>>  wrote:
>>>
>>> I love the idea of making the ref guide itself as an example dataset. That 
>>> way, we won't need to ship anything separately. Python's beautiful soup can 
>>> extract text from the html pages. I'm sure there maybe such things in Java 
>>> too (can Tika do this?).
>>>
>>> On Mon, 31 Aug, 2020, 11:18 pm Alexandre Rafalovitch,  
>>> wrote:

 Hi,
 I need a sanity check.

 I am in the planning stages for the new example datasets to ship with
 Solr 9. The one I am looking at is great for structured information,
 but is quite light on full-text content. So, I am thinking of how
 important that is and what other sources could be used.

 One - only slightly - crazy idea is to use Solr Reference Guide itself
 as a document source. I am not saying we need to include the guide
 with Solr distribution, but:
 1) I could include a couple of sample pages
 2) I could index the whole guide (with custom Java-code) during the
 final build and we could ship the full index (with stored=false) with
 Solr, which then basically becomes a local search for the remote guide
 (with absolute URLs).

 Either way would allow us to also explore what a good search
 configuration could look like for the Ref Guide for when we are
 actually ready to move beyond its current "headings-only" javascript
 search. Actually, done right, same/similar tool could also feed
 subheadings into the javascript search.

 Like I said, sanity check?

 Regards,
Alex.

 -
 To unsubscribe, e-mail: 

Re: Approach towards solving split package issues?

[Tomoko Uchida]

> As I recall one issue was around where to put analysis packages?

It's LUCENE-9317. I had worked on it before, you can see what changes will
be needed for analyzers-common (and core).


2020年9月1日(火) 22:00 Michael Sokolov :

> I'm in favor - there may be some difficult choices though. As I recall
> one issue was around where to put analysis packages? I forget the
> details, but there was some pretty strong feeling that you should have
> a functioning system with core only. However some basic analysis tools
> are required for that, while most of our analyzers and so on are in a
> separate analysis module. Perhaps we will need to move some basic
> analyzers out of com.amazon.lucene.analysis? Or the reverse - move all
> the analysis code into the analysis module and acknowledge that it is
> a fundamental dependency (more essential than core, really).
>
> On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida
>  wrote:
> >
> > yes, Jigsaw was on my mind too...
> >
> > > why not go ahead and try to clean it up right away?
> >
> > > So a strong +1 to clean this up!
> >
> > OK, maybe I should open two issues, one for Lucene and one for Solr, and
> link existing wip issues to them.
> > Once we start it, these will be blockers for 9.0.0 release I believe
> (for now I have no idea about the volume of the changes or technical
> obstacles). Are there any objections or comments?
> >
> >
> > 2020年9月1日(火) 19:34 Uwe Schindler :
> >>
> >> Hi,
> >>
> >> The biggest issue is that split packages make migrating to the Java 9
> module system impossible. It's not allowed to have same package name (with
> classes) in different JAR files.
> >>
> >> Some of those require to open up visibility of classes. Some split
> packages issues were done because of package private access, which is very
> bad between JAR files. This also affects the test framework, although this
> is not such a big deal (I would exclude that for now), because you would
> never run UNIT tests inside a module system, only integration tests.
> >>
> >> So a strong +1 to clean this up!
> >> Uwe
> >>
> >> -
> >> Uwe Schindler
> >> Achterdiek 19, D-28357 Bremen
> >> https://www.thetaphi.de
> >> eMail: u...@thetaphi.de
> >>
> >> > -Original Message-
> >> > From: Dawid Weiss 
> >> > Sent: Tuesday, September 1, 2020 9:22 AM
> >> > To: Lucene Dev 
> >> > Subject: Re: Approach towards solving split package issues?
> >> >
> >> > This is a big headache for many things. I wouldn't mind doing this
> >> > even for 9x. This is a major release, why not go ahead and try to
> >> > clean it up right away?
> >> >
> >> > Dawid
> >> >
> >> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
> >> >  wrote:
> >> > >
> >> > > Hello devs,
> >> > >
> >> > > we have lots of package name conflicts (shared package names)
> between
> >> > modules in the Lucene/Solr source tree. It is not only annoying for
> devs/users
> >> > but also indeed bad practice since Java 9 (according to my
> understanding), and
> >> > we already have some problems with Javadocs due to these splitted
> packages
> >> > as some of us would know. I'm curious about the issue from a while
> ago. My
> >> > questions are, Q1: How can we solve the issue in an organized way?
> Q2: How
> >> > many of us really have interests about that?
> >> > >
> >> > > To break down Q1,
> >> > > - A JIRA for building a grand design and organizing sub tasks is
> needed? We
> >> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it
> and I
> >> > had been playing around them before; but I feel like an umbrella
> ticket would
> >> > be needed.
> >> > > - When to start and what's the target version to be out? My feeling
> is that
> >> > after cutting branch_9x is the right moment to start and 10.0.0 is
> suitable for
> >> > the target, does this make sense?
> >> > > - Are there any other tasks/concerns to be considered except for
> just
> >> > renaming packages?
> >> > >
> >> > > Regarding Q2,
> >> > > I know some of us have deep knowledge and thoughts in this topic,
> but for
> >> > now I am not sure how many of you have the will to give help or take
> time for
> >> > that.
> >> > > It can't be a one-man effort. The more people understand and can
> contribute
> >> > to the build, the more healthy it will be. (I borrowed this phrase
> from Gradle
> >> > build issue LUCENE-9077).
> >> > >
> >> > > I don't intend to rush into making a decision, my purpose here is
> to collect
> >> > information to see if I can handle it before opening a JIRA.
> >> > >
> >> > > Thanks,
> >> > > Tomoko
> >> >
> >> > -
> >> > 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: [VOTE] Lucene logo contest, here we go again

[Erik Hatcher]

D (binding)

> On Aug 31, 2020, at 8:26 PM, Ryan Ernst  wrote:
> 
> Dear Lucene and Solr developers!
> 
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. I would like to call a new vote, now with more explicit 
> instructions on how to vote.
> 
> Please read the following rules carefully before submitting your vote.
> 
> Who can vote?
> 
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
> 
> How do I vote?
> 
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
> 
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
> 
> (binding)
> vote: A1, A2, C3, D, B4e
> 
> Entries
> 
> The entries are as follows:
> 
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
> 
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>  
> 
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png 
> 
> 
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
> 
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf 
> 
> 
> C. Submitted by Baris Kazar. This entry has 8 variants.
> 
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>  
> 
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
>  
> 
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
>  
> 
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
>  
> 
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
>  
> 
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
>  
> 
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
>  
> 
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>  
> 
> 
> D. The current Lucene logo.
> 
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png 
> 
> 
> Please vote for one of the above choices. This vote will close one week from 
> today, Mon, Sept 7, 2020 at 11:59PM.
> 
> Thanks!
> 
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 
> 
> [first-vote] 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>  
> 

Re: Approach towards solving split package issues?

[Michael Sokolov]

I'm in favor - there may be some difficult choices though. As I recall
one issue was around where to put analysis packages? I forget the
details, but there was some pretty strong feeling that you should have
a functioning system with core only. However some basic analysis tools
are required for that, while most of our analyzers and so on are in a
separate analysis module. Perhaps we will need to move some basic
analyzers out of com.amazon.lucene.analysis? Or the reverse - move all
the analysis code into the analysis module and acknowledge that it is
a fundamental dependency (more essential than core, really).

On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida
 wrote:
>
> yes, Jigsaw was on my mind too...
>
> > why not go ahead and try to clean it up right away?
>
> > So a strong +1 to clean this up!
>
> OK, maybe I should open two issues, one for Lucene and one for Solr, and link 
> existing wip issues to them.
> Once we start it, these will be blockers for 9.0.0 release I believe (for now 
> I have no idea about the volume of the changes or technical obstacles). Are 
> there any objections or comments?
>
>
> 2020年9月1日(火) 19:34 Uwe Schindler :
>>
>> Hi,
>>
>> The biggest issue is that split packages make migrating to the Java 9 module 
>> system impossible. It's not allowed to have same package name (with classes) 
>> in different JAR files.
>>
>> Some of those require to open up visibility of classes. Some split packages 
>> issues were done because of package private access, which is very bad 
>> between JAR files. This also affects the test framework, although this is 
>> not such a big deal (I would exclude that for now), because you would never 
>> run UNIT tests inside a module system, only integration tests.
>>
>> So a strong +1 to clean this up!
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Dawid Weiss 
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev 
>> > Subject: Re: Approach towards solving split package issues?
>> >
>> > This is a big headache for many things. I wouldn't mind doing this
>> > even for 9x. This is a major release, why not go ahead and try to
>> > clean it up right away?
>> >
>> > Dawid
>> >
>> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
>> >  wrote:
>> > >
>> > > Hello devs,
>> > >
>> > > we have lots of package name conflicts (shared package names) between
>> > modules in the Lucene/Solr source tree. It is not only annoying for 
>> > devs/users
>> > but also indeed bad practice since Java 9 (according to my understanding), 
>> > and
>> > we already have some problems with Javadocs due to these splitted packages
>> > as some of us would know. I'm curious about the issue from a while ago. My
>> > questions are, Q1: How can we solve the issue in an organized way? Q2: How
>> > many of us really have interests about that?
>> > >
>> > > To break down Q1,
>> > > - A JIRA for building a grand design and organizing sub tasks is needed? 
>> > > We
>> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it and I
>> > had been playing around them before; but I feel like an umbrella ticket 
>> > would
>> > be needed.
>> > > - When to start and what's the target version to be out? My feeling is 
>> > > that
>> > after cutting branch_9x is the right moment to start and 10.0.0 is 
>> > suitable for
>> > the target, does this make sense?
>> > > - Are there any other tasks/concerns to be considered except for just
>> > renaming packages?
>> > >
>> > > Regarding Q2,
>> > > I know some of us have deep knowledge and thoughts in this topic, but for
>> > now I am not sure how many of you have the will to give help or take time 
>> > for
>> > that.
>> > > It can't be a one-man effort. The more people understand and can 
>> > > contribute
>> > to the build, the more healthy it will be. (I borrowed this phrase from 
>> > Gradle
>> > build issue LUCENE-9077).
>> > >
>> > > I don't intend to rush into making a decision, my purpose here is to 
>> > > collect
>> > information to see if I can handle it before opening a JIRA.
>> > >
>> > > Thanks,
>> > > Tomoko
>> >
>> > -
>> > 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: [VOTE] Lucene logo contest, here we go again

[Michael Sokolov]

A1, binding

On Mon, Aug 31, 2020 at 8:26 PM Ryan Ernst  wrote:
>
> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. I would like to call a new vote, now with more explicit 
> instructions on how to vote.
>
> Please read the following rules carefully before submitting your vote.
>
> Who can vote?
>
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
>
> How do I vote?
>
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
>
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> Entries
>
> The entries are as follows:
>
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
>
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close one week from 
> today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote] 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting

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

Re: Approach towards solving split package issues?

[Tomoko Uchida]

yes, Jigsaw was on my mind too...

> why not go ahead and try to clean it up right away?

> So a strong +1 to clean this up!

OK, maybe I should open two issues, one for Lucene and one for Solr, and
link existing wip issues to them.
Once we start it, these will be blockers for 9.0.0 release I believe (for
now I have no idea about the volume of the changes or technical obstacles).
Are there any objections or comments?


2020年9月1日(火) 19:34 Uwe Schindler :

> Hi,
>
> The biggest issue is that split packages make migrating to the Java 9
> module system impossible. It's not allowed to have same package name (with
> classes) in different JAR files.
>
> Some of those require to open up visibility of classes. Some split
> packages issues were done because of package private access, which is very
> bad between JAR files. This also affects the test framework, although this
> is not such a big deal (I would exclude that for now), because you would
> never run UNIT tests inside a module system, only integration tests.
>
> So a strong +1 to clean this up!
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Dawid Weiss 
> > Sent: Tuesday, September 1, 2020 9:22 AM
> > To: Lucene Dev 
> > Subject: Re: Approach towards solving split package issues?
> >
> > This is a big headache for many things. I wouldn't mind doing this
> > even for 9x. This is a major release, why not go ahead and try to
> > clean it up right away?
> >
> > Dawid
> >
> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
> >  wrote:
> > >
> > > Hello devs,
> > >
> > > we have lots of package name conflicts (shared package names) between
> > modules in the Lucene/Solr source tree. It is not only annoying for
> devs/users
> > but also indeed bad practice since Java 9 (according to my
> understanding), and
> > we already have some problems with Javadocs due to these splitted
> packages
> > as some of us would know. I'm curious about the issue from a while ago.
> My
> > questions are, Q1: How can we solve the issue in an organized way? Q2:
> How
> > many of us really have interests about that?
> > >
> > > To break down Q1,
> > > - A JIRA for building a grand design and organizing sub tasks is
> needed? We
> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it and I
> > had been playing around them before; but I feel like an umbrella ticket
> would
> > be needed.
> > > - When to start and what's the target version to be out? My feeling is
> that
> > after cutting branch_9x is the right moment to start and 10.0.0 is
> suitable for
> > the target, does this make sense?
> > > - Are there any other tasks/concerns to be considered except for just
> > renaming packages?
> > >
> > > Regarding Q2,
> > > I know some of us have deep knowledge and thoughts in this topic, but
> for
> > now I am not sure how many of you have the will to give help or take
> time for
> > that.
> > > It can't be a one-man effort. The more people understand and can
> contribute
> > to the build, the more healthy it will be. (I borrowed this phrase from
> Gradle
> > build issue LUCENE-9077).
> > >
> > > I don't intend to rush into making a decision, my purpose here is to
> collect
> > information to see if I can handle it before opening a JIRA.
> > >
> > > Thanks,
> > > Tomoko
> >
> > -
> > 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: [VOTE] Lucene logo contest, here we go again

[Ignacio Vera]

here is my vote:

A1, A2 (binding)

On Tue, Sep 1, 2020 at 1:49 PM Aurélien MAZOYER 
wrote:

> Hi community,
>
> I would vote for A1.
>
> Aurélien
>
>
>
> On Tue, 1 Sep 2020 at 13:26, Andrzej Białecki  wrote:
>
> > A1, D (binding)
> >
> > > On 1 Sep 2020, at 02:26, Ryan Ernst  wrote:
> > >
> > > Dear Lucene and Solr developers!
> > >
> > > In February a contest was started to design a new logo for Lucene
> > > [jira-issue]. The initial attempt [first-vote] to call a vote resulted
> in
> > > some confusion on the rules, as well the request for one additional
> > > submission. I would like to call a new vote, now with more explicit
> > > instructions on how to vote.
> > >
> > > *Please read the following rules carefully* before submitting your
> vote.
> > >
> > > *Who can vote?*
> > >
> > > Anyone is welcome to cast a vote in support of their favorite
> > > submission(s). Note that only PMC member's votes are binding. If you
> are
> > a
> > > PMC member, please indicate with your vote that the vote is binding, to
> > > ease collection of votes. In tallying the votes, I will attempt to
> verify
> > > only those marked as binding.
> > >
> > >
> > > *How do I vote?*
> > > Votes can be cast simply by replying to this email. It is a
> ranked-choice
> > > vote [rank-choice-voting]. Multiple selections may be made, where the
> > order
> > > of preference must be specified. If an entry gets more than half the
> > votes,
> > > it is the winner. Otherwise, the entry with the lowest number of votes
> is
> > > removed, and the votes are retallied, taking into account the next
> > > preferred entry for those whose first entry was removed. This process
> > > repeats until there is a winner.
> > >
> > > The entries are broken up by variants, since some entries have multiple
> > > color or style variations. The entry identifiers are first a capital
> > > letter, followed by a variation id (described with each entry below),
> if
> > > applicable. As an example, if you prefer variant 1 of entry A, followed
> > by
> > > variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant
> > 4e
> > > of entry B, the following should be in your reply:
> > >
> > > (binding)
> > > vote: A1, A2, C3, D, B4e
> > >
> > > *Entries*
> > >
> > > The entries are as follows:
> > >
> > > A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
> > >
> > > [A1]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> > > [A2]
> > >
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
> > >
> > > B. Submitted by Stamatis Zampetakis. This has several variants. Within
> > the
> > > linked entry there are 7 patterns and 7 color palettes. Any vote for B
> > > should contain the pattern number followed by the lowercase letter of
> the
> > > color palette. For example, B3e or B1a.
> > >
> > > [B]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
> > >
> > > C. Submitted by Baris Kazar. This entry has 8 variants.
> > >
> > > [C1]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> > > [C2]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> > > [C3]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> > > [C4]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> > > [C5]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> > > [C6]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> > > [C7]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> > > [C8]
> > >
> >
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
> > >
> > > D. The current Lucene logo.
> > >
> > > [D]
> > https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
> > >
> > > Please vote for one of the above choices. This vote will close one week
> > > from today, Mon, Sept 7, 2020 at 11:59PM.
> > >
> > > Thanks!
> > >
> > > [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> > > [first-vote]
> > >
> >
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> > > [rank-choice-voting]
> https://en.wikipedia.org/wiki/Instant-runoff_voting
> >
> >
> > -
> > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: java-user-h...@lucene.apache.org
> >
> >
>

Re: [VOTE] Lucene logo contest, here we go again

[Andrzej Białecki]

A1, D (binding)

> On 1 Sep 2020, at 02:26, Ryan Ernst  wrote:
> 
> Dear Lucene and Solr developers!
> 
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. I would like to call a new vote, now with more explicit
> instructions on how to vote.
> 
> *Please read the following rules carefully* before submitting your vote.
> 
> *Who can vote?*
> 
> Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
> 
> 
> *How do I vote?*
> Votes can be cast simply by replying to this email. It is a ranked-choice
> vote [rank-choice-voting]. Multiple selections may be made, where the order
> of preference must be specified. If an entry gets more than half the votes,
> it is the winner. Otherwise, the entry with the lowest number of votes is
> removed, and the votes are retallied, taking into account the next
> preferred entry for those whose first entry was removed. This process
> repeats until there is a winner.
> 
> The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
> 
> (binding)
> vote: A1, A2, C3, D, B4e
> 
> *Entries*
> 
> The entries are as follows:
> 
> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
> 
> [A1]
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
> 
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the
> linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
> 
> [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
> 
> C. Submitted by Baris Kazar. This entry has 8 variants.
> 
> [C1]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> [C3]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> [C4]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> [C5]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> [C6]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> [C7]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> [C8]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
> 
> D. The current Lucene logo.
> 
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
> 
> Please vote for one of the above choices. This vote will close one week
> from today, Mon, Sept 7, 2020 at 11:59PM.
> 
> Thanks!
> 
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting


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

RE: Approach towards solving split package issues?

[Uwe Schindler]

Hi,

The biggest issue is that split packages make migrating to the Java 9 module 
system impossible. It's not allowed to have same package name (with classes) in 
different JAR files.

Some of those require to open up visibility of classes. Some split packages 
issues were done because of package private access, which is very bad between 
JAR files. This also affects the test framework, although this is not such a 
big deal (I would exclude that for now), because you would never run UNIT tests 
inside a module system, only integration tests.

So a strong +1 to clean this up!
Uwe

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

> -Original Message-
> From: Dawid Weiss 
> Sent: Tuesday, September 1, 2020 9:22 AM
> To: Lucene Dev 
> Subject: Re: Approach towards solving split package issues?
> 
> This is a big headache for many things. I wouldn't mind doing this
> even for 9x. This is a major release, why not go ahead and try to
> clean it up right away?
> 
> Dawid
> 
> On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
>  wrote:
> >
> > Hello devs,
> >
> > we have lots of package name conflicts (shared package names) between
> modules in the Lucene/Solr source tree. It is not only annoying for devs/users
> but also indeed bad practice since Java 9 (according to my understanding), and
> we already have some problems with Javadocs due to these splitted packages
> as some of us would know. I'm curious about the issue from a while ago. My
> questions are, Q1: How can we solve the issue in an organized way? Q2: How
> many of us really have interests about that?
> >
> > To break down Q1,
> > - A JIRA for building a grand design and organizing sub tasks is needed? We
> have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it and I
> had been playing around them before; but I feel like an umbrella ticket would
> be needed.
> > - When to start and what's the target version to be out? My feeling is that
> after cutting branch_9x is the right moment to start and 10.0.0 is suitable 
> for
> the target, does this make sense?
> > - Are there any other tasks/concerns to be considered except for just
> renaming packages?
> >
> > Regarding Q2,
> > I know some of us have deep knowledge and thoughts in this topic, but for
> now I am not sure how many of you have the will to give help or take time for
> that.
> > It can't be a one-man effort. The more people understand and can contribute
> to the build, the more healthy it will be. (I borrowed this phrase from Gradle
> build issue LUCENE-9077).
> >
> > I don't intend to rush into making a decision, my purpose here is to collect
> information to see if I can handle it before opening a JIRA.
> >
> > Thanks,
> > Tomoko
> 
> -
> 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: [VOTE] Lucene logo contest, here we go again

[Adrien Grand]

Ryan, FYI the links to proposals C are incorrect as they all use the
attachment ID of the first proposal, so all links point to the same logo,
here are the correct links:

[C1]
https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
[C2]
https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf
[C3]
https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf
[C4]
https://issues.apache.org/jira/secure/attachment/13006395/lucene_logo4_full.pdf
[C5]
https://issues.apache.org/jira/secure/attachment/13006396/lucene_logo5_full.pdf
[C6]
https://issues.apache.org/jira/secure/attachment/13006397/lucene_logo6_full.pdf
[C7]
https://issues.apache.org/jira/secure/attachment/13006398/lucene_logo7_full.pdf
[C8]
https://issues.apache.org/jira/secure/attachment/13006399/lucene_logo8_full.pdf

And here is my vote:
A1, A2, D (binding)

On Tue, Sep 1, 2020 at 9:35 AM Gus Heck  wrote:

> A1, D (binding)
>
> On Tue, Sep 1, 2020 at 3:33 AM Anshum Gupta 
> wrote:
>
>> Based on the options, I like the current one the most.
>>
>> D (binding)
>>
>> On Mon, Aug 31, 2020 at 5:26 PM Ryan Ernst  wrote:
>>
>>> Dear Lucene and Solr developers!
>>>
>>> In February a contest was started to design a new logo for Lucene
>>> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
>>> some confusion on the rules, as well the request for one additional
>>> submission. I would like to call a new vote, now with more explicit
>>> instructions on how to vote.
>>>
>>> *Please read the following rules carefully* before submitting your vote.
>>>
>>> *Who can vote?*
>>>
>>> Anyone is welcome to cast a vote in support of their favorite
>>> submission(s). Note that only PMC member's votes are binding. If you are a
>>> PMC member, please indicate with your vote that the vote is binding, to
>>> ease collection of votes. In tallying the votes, I will attempt to verify
>>> only those marked as binding.
>>>
>>>
>>> *How do I vote?*
>>> Votes can be cast simply by replying to this email. It is a
>>> ranked-choice vote [rank-choice-voting]. Multiple selections may be made,
>>> where the order of preference must be specified. If an entry gets more than
>>> half the votes, it is the winner. Otherwise, the entry with the lowest
>>> number of votes is removed, and the votes are retallied, taking into
>>> account the next preferred entry for those whose first entry was removed.
>>> This process repeats until there is a winner.
>>>
>>> The entries are broken up by variants, since some entries have multiple
>>> color or style variations. The entry identifiers are first a capital
>>> letter, followed by a variation id (described with each entry below), if
>>> applicable. As an example, if you prefer variant 1 of entry A, followed by
>>> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
>>> of entry B, the following should be in your reply:
>>>
>>> (binding)
>>> vote: A1, A2, C3, D, B4e
>>>
>>> *Entries*
>>>
>>> The entries are as follows:
>>>
>>> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>>>
>>> [A1]
>>> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>>> [A2]
>>> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>>>
>>> B. Submitted by Stamatis Zampetakis. This has several variants. Within
>>> the linked entry there are 7 patterns and 7 color palettes. Any vote for B
>>> should contain the pattern number followed by the lowercase letter of the
>>> color palette. For example, B3e or B1a.
>>>
>>> [B]
>>> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>>>
>>> C. Submitted by Baris Kazar. This entry has 8 variants.
>>>
>>> [C1]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>>> [C2]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
>>> [C3]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
>>> [C4]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
>>> [C5]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
>>> [C6]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
>>> [C7]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
>>> [C8]
>>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>>>
>>> D. The current Lucene logo.
>>>
>>> [D]
>>> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>>>
>>> Please vote for one of the above choices. This vote will close one week
>>> from today, Mon, Sept 7, 2020 at 11:59PM.
>>>
>>> Thanks!
>>>
>>> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
>>> [first-vote]
>>> 

Re: [VOTE] Lucene logo contest, here we go again

[Gus Heck]

A1, D (binding)

On Tue, Sep 1, 2020 at 3:33 AM Anshum Gupta  wrote:

> Based on the options, I like the current one the most.
>
> D (binding)
>
> On Mon, Aug 31, 2020 at 5:26 PM Ryan Ernst  wrote:
>
>> Dear Lucene and Solr developers!
>>
>> In February a contest was started to design a new logo for Lucene
>> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
>> some confusion on the rules, as well the request for one additional
>> submission. I would like to call a new vote, now with more explicit
>> instructions on how to vote.
>>
>> *Please read the following rules carefully* before submitting your vote.
>>
>> *Who can vote?*
>>
>> Anyone is welcome to cast a vote in support of their favorite
>> submission(s). Note that only PMC member's votes are binding. If you are a
>> PMC member, please indicate with your vote that the vote is binding, to
>> ease collection of votes. In tallying the votes, I will attempt to verify
>> only those marked as binding.
>>
>>
>> *How do I vote?*
>> Votes can be cast simply by replying to this email. It is a ranked-choice
>> vote [rank-choice-voting]. Multiple selections may be made, where the order
>> of preference must be specified. If an entry gets more than half the votes,
>> it is the winner. Otherwise, the entry with the lowest number of votes is
>> removed, and the votes are retallied, taking into account the next
>> preferred entry for those whose first entry was removed. This process
>> repeats until there is a winner.
>>
>> The entries are broken up by variants, since some entries have multiple
>> color or style variations. The entry identifiers are first a capital
>> letter, followed by a variation id (described with each entry below), if
>> applicable. As an example, if you prefer variant 1 of entry A, followed by
>> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
>> of entry B, the following should be in your reply:
>>
>> (binding)
>> vote: A1, A2, C3, D, B4e
>>
>> *Entries*
>>
>> The entries are as follows:
>>
>> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>>
>> [A1]
>> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>> [A2]
>> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>>
>> B. Submitted by Stamatis Zampetakis. This has several variants. Within
>> the linked entry there are 7 patterns and 7 color palettes. Any vote for B
>> should contain the pattern number followed by the lowercase letter of the
>> color palette. For example, B3e or B1a.
>>
>> [B]
>> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>>
>> C. Submitted by Baris Kazar. This entry has 8 variants.
>>
>> [C1]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>> [C2]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
>> [C3]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
>> [C4]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
>> [C5]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
>> [C6]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
>> [C7]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
>> [C8]
>> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>>
>> D. The current Lucene logo.
>>
>> [D]
>> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>>
>> Please vote for one of the above choices. This vote will close one week
>> from today, Mon, Sept 7, 2020 at 11:59PM.
>>
>> Thanks!
>>
>> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
>> [first-vote]
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>>
>
>
> --
> Anshum Gupta
>


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

Re: [VOTE] Lucene logo contest, here we go again

[Anshum Gupta]

Based on the options, I like the current one the most.

D (binding)

On Mon, Aug 31, 2020 at 5:26 PM Ryan Ernst  wrote:

> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in
> some confusion on the rules, as well the request for one additional
> submission. I would like to call a new vote, now with more explicit
> instructions on how to vote.
>
> *Please read the following rules carefully* before submitting your vote.
>
> *Who can vote?*
>
> Anyone is welcome to cast a vote in support of their favorite
> submission(s). Note that only PMC member's votes are binding. If you are a
> PMC member, please indicate with your vote that the vote is binding, to
> ease collection of votes. In tallying the votes, I will attempt to verify
> only those marked as binding.
>
>
> *How do I vote?*
> Votes can be cast simply by replying to this email. It is a ranked-choice
> vote [rank-choice-voting]. Multiple selections may be made, where the order
> of preference must be specified. If an entry gets more than half the votes,
> it is the winner. Otherwise, the entry with the lowest number of votes is
> removed, and the votes are retallied, taking into account the next
> preferred entry for those whose first entry was removed. This process
> repeats until there is a winner.
>
> The entries are broken up by variants, since some entries have multiple
> color or style variations. The entry identifiers are first a capital
> letter, followed by a variation id (described with each entry below), if
> applicable. As an example, if you prefer variant 1 of entry A, followed by
> variant 2 of entry A, variant 3 of entry C, entry D, and lastly variant 4e
> of entry B, the following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> *Entries*
>
> The entries are as follows:
>
> A*.* Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1]
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2]
> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the
> linked entry there are 7 patterns and 7 color palettes. Any vote for B
> should contain the pattern number followed by the lowercase letter of the
> color palette. For example, B3e or B1a.
>
> [B]
> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> [C3]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> [C4]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> [C5]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> [C6]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> [C7]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> [C8]
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D]
> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close one week
> from today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>


-- 
Anshum Gupta

Re: [VOTE] Lucene logo contest, here we go again

[Noble Paul]

D (binding)

On Tue, Sep 1, 2020 at 5:15 PM Jan Høydahl  wrote:
>
> D (binding)
>
> Jan
>
> 1. sep. 2020 kl. 02:26 skrev Ryan Ernst :
>
> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. I would like to call a new vote, now with more explicit 
> instructions on how to vote.
>
> Please read the following rules carefully before submitting your vote.
>
> Who can vote?
>
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
>
> How do I vote?
>
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
>
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> Entries
>
> The entries are as follows:
>
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
>
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close one week from 
> today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote] 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>
>


-- 
-
Noble Paul

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

Re: Approach towards solving split package issues?

[Dawid Weiss]

This is a big headache for many things. I wouldn't mind doing this
even for 9x. This is a major release, why not go ahead and try to
clean it up right away?

Dawid

On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
 wrote:
>
> Hello devs,
>
> we have lots of package name conflicts (shared package names) between modules 
> in the Lucene/Solr source tree. It is not only annoying for devs/users but 
> also indeed bad practice since Java 9 (according to my understanding), and we 
> already have some problems with Javadocs due to these splitted packages as 
> some of us would know. I'm curious about the issue from a while ago. My 
> questions are, Q1: How can we solve the issue in an organized way? Q2: How 
> many of us really have interests about that?
>
> To break down Q1,
> - A JIRA for building a grand design and organizing sub tasks is needed? We 
> have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319) about it and I had 
> been playing around them before; but I feel like an umbrella ticket would be 
> needed.
> - When to start and what's the target version to be out? My feeling is that 
> after cutting branch_9x is the right moment to start and 10.0.0 is suitable 
> for the target, does this make sense?
> - Are there any other tasks/concerns to be considered except for just 
> renaming packages?
>
> Regarding Q2,
> I know some of us have deep knowledge and thoughts in this topic, but for now 
> I am not sure how many of you have the will to give help or take time for 
> that.
> It can't be a one-man effort. The more people understand and can contribute 
> to the build, the more healthy it will be. (I borrowed this phrase from 
> Gradle build issue LUCENE-9077).
>
> I don't intend to rush into making a decision, my purpose here is to collect 
> information to see if I can handle it before opening a JIRA.
>
> Thanks,
> Tomoko

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

[ANNOUNCE] Apache Solr 8.6.2 released

[Ignacio Vera]

01 September 2020, Apache Solr™ 8.6.2 available

The Lucene PMC is pleased to announce the release of Apache Solr 8.6.2

Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search and analytics, rich document
parsing, geospatial search, extensive REST APIs as well as parallel SQL.
Solr is enterprise grade, secure and highly scalable, providing fault
tolerant distributed search and indexing, and powers the search and
navigation features of many of the world's largest internet sites.

This release contains two bug fixes. The release is available for immediate
download at:

The release is available for immediate download at:

https://lucene.apache.org/solr/downloads.html

Solr 8.6.2 Bug Fixes:

SOLR-14751: Zookeeper Admin screen not working for old ZK versions.

Solr 8.6.2 also includes 1 bugfix in the corresponding Apache Lucene
release:



Please report any feedback to the mailing lists (
https://lucene.apache.org/solr/community.html#mailing-lists-irc)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also goes for Maven access.

[ANNOUNCE] Apache Lucene 8.6.2 released

[Ignacio Vera]

01 September 2020, Apache Lucene™ 8.6.2 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.6.2.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains one bug fix. The release is available for immediate
download at:

https://lucene.apache.org/core/downloads.html

Lucene 8.6.2 Bug Fixes:

LUCENE-9478: IndexWriter leaked about 500 byte of heap space for each
full-flush, getReader or commit. This was a regression in 6.8.0

Further details of changes are available in the change log available at:
https://lucene.apache.org/core/8_6_2/changes/Changes.html


Please report any feedback to the mailing lists (
https://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

Re: Checking dependencies in gradle after code is removed

[Dawid Weiss]

bq. you get a lot of entries there

That's why this is to large degree automated. You do have a lot of
entries because it's a union of all dependencies across all
sub-projects. While this may seem like a negative, it's not - it
ensures everyone stays on the same set of dependencies. Makes life
easier in the long run.

Also, you can check what depends on what by looking at the .lock file;
for example:

com.github.jnr:jffi:1.2.18 (1 constraints: b20902ab)

if you ask for this hash, you'll see where the dependency comes from
(and so on, recursively). Note that some of these dependencies are
built-time, not runtime.

O:\repos\lucene-master>gradlew why --hash=b20902ab
Starting a Gradle Daemon (subsequent builds will be faster)

> Task :why
com.github.jnr:jffi:1.2.18
org.jruby:jruby-core -> 1.2.18

O:\repos\lucene-master>gradlew why --hash=0f08b57d

> Task :why
org.jruby:jruby-core:9.2.6.0
org.jruby:jruby -> 9.2.6.0

org.jruby:jruby-stdlib:9.2.6.0
org.jruby:jruby -> 9.2.6.0

O:\repos\lucene-master>gradlew why --hash=490d7d28

> Task :why
org.jruby:jruby:9.2.6.0
org.asciidoctor:asciidoctorj -> 9.2.6.0

etc.

Dawid

On Tue, Sep 1, 2020 at 1:20 AM Erick Erickson  wrote:
>
> Excellent, I’ve put it in my notes… you get a lot of entries there… Thanks!
>
> > On Aug 31, 2020, at 2:59 PM, Dawid Weiss  wrote:
> >
> >> Is there an easy way to insure that versions.props only has necessary 
> >> dependencies listed? Ideally it would be just a top-level command.
> >
> > If a dependency isn't used, check will fail. It's a feature of
> > palantir's version control plugin. The concrete task that does it is
> > named checkUnusedConstraints but you should not need to know it (or
> > care). Use check at the top level and it'll be run automatically.
> >
> >> gradlew dependencies lists pretty much everything, is it the case that if 
> >> a dependency does _not_ show up in a project that it’s unused?
> >
> > That's because solr depends on pretty much everything...
> >
> > D.
> >
> > -
> > 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: [VOTE] Lucene logo contest, here we go again

[Jan Høydahl]

D (binding)

Jan

> 1. sep. 2020 kl. 02:26 skrev Ryan Ernst :
> 
> Dear Lucene and Solr developers!
> 
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. I would like to call a new vote, now with more explicit 
> instructions on how to vote.
> 
> Please read the following rules carefully before submitting your vote.
> 
> Who can vote?
> 
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
> 
> How do I vote?
> 
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
> 
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
> 
> (binding)
> vote: A1, A2, C3, D, B4e
> 
> Entries
> 
> The entries are as follows:
> 
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
> 
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>  
> 
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png 
> 
> 
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
> 
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf 
> 
> 
> C. Submitted by Baris Kazar. This entry has 8 variants.
> 
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
>  
> 
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
>  
> 
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
>  
> 
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
>  
> 
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
>  
> 
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
>  
> 
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
>  
> 
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>  
> 
> 
> D. The current Lucene logo.
> 
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png 
> 
> 
> Please vote for one of the above choices. This vote will close one week from 
> today, Mon, Sept 7, 2020 at 11:59PM.
> 
> Thanks!
> 
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 
> 
> [first-vote] 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
>  
> 

Re: [VOTE] Lucene logo contest, here we go again

[Dawid Weiss]

I'm still in favor of the current logo (D), binding vote.

Dawid

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

Re: SIP-10: Solr 9 examples: Can we use Ref Guide as a dogfood example?

[Jan Høydahl]

I’d rather ship a tutorial and tooling that explains how to index the 
ref-guide, than shipping a binary index.
What other full-text datasets have you considered as candidates for 
getting-started examples?

Jan

> 1. sep. 2020 kl. 05:53 skrev Alexandre Rafalovitch :
> 
> I did not say it was trivial, but I also did not quite mention the previous 
> research.
> 
> https://github.com/arafalov/solr-refguide-indexing/blob/master/src/com/solrstart/refguide/Indexer.java
>  
> 
> 
> Uses official AsciidoctorJ library directory. Not sure if that's just JRuby 
> version of Asciidoctor we currently use to build. But this should only affect 
> the development process, not the final built package. 
> 
> I think I am more trying to figure out what people think about shipping an 
> actual core with the distribution. That is something I haven't seen done 
> before. And may have issues I did not think of. 
> 
> Regards, 
> Alex
> 
> On Mon., Aug. 31, 2020, 10:11 p.m. Gus Heck,  > wrote:
> Some background to consider before committing to that... it might not be as 
> trivial as you think. (I've often thought it ironic that we don't have real 
> search for our ref guide... )
> 
> https://www.youtube.com/watch?v=DixlnxAk08s 
> 
> 
> -Gus
> 
> On Mon, Aug 31, 2020 at 2:06 PM Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>> wrote:
> I love the idea of making the ref guide itself as an example dataset. That 
> way, we won't need to ship anything separately. Python's beautiful soup can 
> extract text from the html pages. I'm sure there maybe such things in Java 
> too (can Tika do this?).
> 
> On Mon, 31 Aug, 2020, 11:18 pm Alexandre Rafalovitch,  > wrote:
> Hi,
> I need a sanity check.
> 
> I am in the planning stages for the new example datasets to ship with
> Solr 9. The one I am looking at is great for structured information,
> but is quite light on full-text content. So, I am thinking of how
> important that is and what other sources could be used.
> 
> One - only slightly - crazy idea is to use Solr Reference Guide itself
> as a document source. I am not saying we need to include the guide
> with Solr distribution, but:
> 1) I could include a couple of sample pages
> 2) I could index the whole guide (with custom Java-code) during the
> final build and we could ship the full index (with stored=false) with
> Solr, which then basically becomes a local search for the remote guide
> (with absolute URLs).
> 
> Either way would allow us to also explore what a good search
> configuration could look like for the Ref Guide for when we are
> actually ready to move beyond its current "headings-only" javascript
> search. Actually, done right, same/similar tool could also feed
> subheadings into the javascript search.
> 
> Like I said, sanity check?
> 
> Regards,
>Alex.
> 
> -
> 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)