[jira] [Resolved] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-10 Thread Andreas Vajda (Jira) 


 [ 
https://issues.apache.org/jira/browse/PYLUCENE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Vajda resolved PYLUCENE-51.
---
Resolution: Invalid

Resolving as INVALID since I don't know what this is actually about.
Feel free to reopen if you have more information.


> "AttributeError: __module__" when running doctest
> -
>
> Key: PYLUCENE-51
> URL: https://issues.apache.org/jira/browse/PYLUCENE-51
> Project: PyLucene
>  Issue Type: Bug
> Environment: Ubuntu 19.04, Python 3.7
>Reporter: Clément Jonglez
>Priority: Major
>
> Dear all,
> I am using the Orekit Python wrapper by [~petrush] . I am running into errors 
> & warnings when trying to run tests with doctest. When collecting tests, it 
> analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
> into the following error:
> {noformat}
> [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
>  for test in finder.find(module):
>  [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
>  extraglobs)
>  [...]/lib/python3.7/doctest.py:932: in find
>  self._find(tests, obj, name, module, source_lines, globs, {})
>  [...]/lib/python3.7/doctest.py:993: in _find
>  self._from_module(module, val)):
>  [...]/lib/python3.7/doctest.py:960: in _from_module
>  return module._name_ == object._module_
>  E AttributeError: _module_{noformat}
>  
> In doctest 
> ([https://github.com/python/cpython/blob/master/Lib/doctest.py#L959]), the
> {code:java}
> inspect.isclass(object) {code}
> condition at line 959 returns `True`, and therefore doctest tries to access 
> the object's __module__ attribute, which does not seem to exist.
> Besides, pytest prints a warning for each Java class being wrapped, also 
> because they have no __module__ attribute (this is one example of 1000+ 
> warnings):
> {noformat}
> [...]/lib/python3.7/importlib/bootstrap.py:219: DeprecationWarning: builtin 
> type ExtendedKalmanFilter has no __module_ attribute
>  return f(*args, **kwds){noformat}
> This phenomenon is new because 6 months ago I could run pytest & doctest 
> successfully with Orekit. I could not find which module contains the change 
> that broke stuff since then though.
> To reproduce the phenomenon, you can check out 
> [https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164]
>  I was trying to validate some poliastro features using the Orekit python 
> wrapper. So this code requires poliastro, it is available on conda-forge.
> Cheers
> Clément



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-10 Thread Andreas Vajda (Jira) 


[ 
https://issues.apache.org/jira/browse/PYLUCENE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949036#comment-16949036
 ] 

Andreas Vajda commented on PYLUCENE-51:
---

This site is about bugs in PyLucene and JCC not Orekit.
Please, contact Petrus directly about Orekit issues.

JCC does not, did not, set __module__ on anything ever.
JCC did set module.__dir__ in the past until Python 3 grabbed __dir__ in PEP 
562.
It now sets module.__module_dir__ in Python 3.
In Python 2, it still sets module.__dir__.


> "AttributeError: __module__" when running doctest
> -
>
> Key: PYLUCENE-51
> URL: https://issues.apache.org/jira/browse/PYLUCENE-51
> Project: PyLucene
>  Issue Type: Bug
> Environment: Ubuntu 19.04, Python 3.7
>Reporter: Clément Jonglez
>Priority: Major
>
> Dear all,
> I am using the Orekit Python wrapper by [~petrush] . I am running into errors 
> & warnings when trying to run tests with doctest. When collecting tests, it 
> analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
> into the following error:
> {noformat}
> [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
>  for test in finder.find(module):
>  [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
>  extraglobs)
>  [...]/lib/python3.7/doctest.py:932: in find
>  self._find(tests, obj, name, module, source_lines, globs, {})
>  [...]/lib/python3.7/doctest.py:993: in _find
>  self._from_module(module, val)):
>  [...]/lib/python3.7/doctest.py:960: in _from_module
>  return module._name_ == object._module_
>  E AttributeError: _module_{noformat}
>  
> In doctest 
> ([https://github.com/python/cpython/blob/master/Lib/doctest.py#L959]), the
> {code:java}
> inspect.isclass(object) {code}
> condition at line 959 returns `True`, and therefore doctest tries to access 
> the object's __module__ attribute, which does not seem to exist.
> Besides, pytest prints a warning for each Java class being wrapped, also 
> because they have no __module__ attribute (this is one example of 1000+ 
> warnings):
> {noformat}
> [...]/lib/python3.7/importlib/bootstrap.py:219: DeprecationWarning: builtin 
> type ExtendedKalmanFilter has no __module_ attribute
>  return f(*args, **kwds){noformat}
> This phenomenon is new because 6 months ago I could run pytest & doctest 
> successfully with Orekit. I could not find which module contains the change 
> that broke stuff since then though.
> To reproduce the phenomenon, you can check out 
> [https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164]
>  I was trying to validate some poliastro features using the Orekit python 
> wrapper. So this code requires poliastro, it is available on conda-forge.
> Cheers
> Clément



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-10 Thread Jira 


 [ 
https://issues.apache.org/jira/browse/PYLUCENE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Clément Jonglez updated PYLUCENE-51:

Description: 
Dear all,

I am using the Orekit Python wrapper by [~petrush] . I am running into errors & 
warnings when trying to run tests with doctest. When collecting tests, it 
analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
into the following error:
{noformat}
[...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
 for test in finder.find(module):
 [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
 extraglobs)
 [...]/lib/python3.7/doctest.py:932: in find
 self._find(tests, obj, name, module, source_lines, globs, {})
 [...]/lib/python3.7/doctest.py:993: in _find
 self._from_module(module, val)):
 [...]/lib/python3.7/doctest.py:960: in _from_module
 return module._name_ == object._module_
 E AttributeError: _module_{noformat}
 

In doctest 
([https://github.com/python/cpython/blob/master/Lib/doctest.py#L959]), the
{code:java}
inspect.isclass(object) {code}
condition at line 959 returns `True`, and therefore doctest tries to access the 
object's __module__ attribute, which does not seem to exist.

Besides, pytest prints a warning for each Java class being wrapped, also 
because they have no __module__ attribute (this is one example of 1000+ 
warnings):
{noformat}
[...]/lib/python3.7/importlib/bootstrap.py:219: DeprecationWarning: builtin 
type ExtendedKalmanFilter has no __module_ attribute
 return f(*args, **kwds){noformat}
This phenomenon is new because 6 months ago I could run pytest & doctest 
successfully with Orekit. I could not find which module contains the change 
that broke stuff since then though.

To reproduce the phenomenon, you can check out 
[https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164]
 I was trying to validate some poliastro features using the Orekit python 
wrapper. So this code requires poliastro, it is available on conda-forge.

Cheers

Clément

  was:
Dear all,

I am using the Orekit Python wrapper by [~petrush] . I am running into errors & 
warnings when trying to run tests with doctest. When collecting tests, it 
analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
into the following error:


{noformat}
[...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
 for test in finder.find(module):
 [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
 extraglobs)
 [...]/lib/python3.7/doctest.py:932: in find
 self._find(tests, obj, name, module, source_lines, globs, {})
 [...]/lib/python3.7/doctest.py:993: in _find
 self._from_module(module, val)):
 [...]/lib/python3.7/doctest.py:960: in _from_module
 return module._name_ == object._module_
 E AttributeError: _module_{noformat}
 

In doctest 
([https://github.com/python/cpython/blob/master/Lib/doctest.py#L959]), the 
`inspect.isclass(object)` condition at line 959 returns `True`, and therefore 
doctest tries to access the object's `__module__` attribute, which does not 
seem to exist.

Besides, pytest prints a warning for each Java class being wrapped, also 
because they have no __module__ attribute (this is one example of 1000+ 
warnings):


{noformat}
[...]/lib/python3.7/importlib/bootstrap.py:219: DeprecationWarning: builtin 
type ExtendedKalmanFilter has no __module_ attribute
 return f(*args, **kwds){noformat}
This phenomenon is new because 6 months ago I could run pytest & doctest 
successfully with Orekit. I could not find which module contains the change 
that broke stuff since then though.

To reproduce the phenomenon, you can check out 
[https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164]
 I was trying to validate some poliastro features using the Orekit python 
wrapper. So this code requires poliastro, it is available on conda-forge.

Cheers

Clément


> "AttributeError: __module__" when running doctest
> -
>
> Key: PYLUCENE-51
> URL: https://issues.apache.org/jira/browse/PYLUCENE-51
> Project: PyLucene
>  Issue Type: Bug
> Environment: Ubuntu 19.04, Python 3.7
>Reporter: Clément Jonglez
>Priority: Major
>
> Dear all,
> I am using the Orekit Python wrapper by [~petrush] . I am running into errors 
> & warnings when trying to run tests with doctest. When collecting tests, it 
> analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
> into the following error:
> {noformat}
> [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
>  for test in finder.find(module):
>  [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
>  extraglobs)
>

[jira] [Created] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-10 Thread Jira 
Clément Jonglez created PYLUCENE-51:
---

 Summary: "AttributeError: __module__" when running doctest
 Key: PYLUCENE-51
 URL: https://issues.apache.org/jira/browse/PYLUCENE-51
 Project: PyLucene
  Issue Type: Bug
 Environment: Ubuntu 19.04, Python 3.7
Reporter: Clément Jonglez


Dear all,

I am using the Orekit Python wrapper by [~petrush] . I am running into errors & 
warnings when trying to run tests with doctest. When collecting tests, it 
analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
into the following error:
```
[...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
 for test in finder.find(module):
[...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
 extraglobs)
[...]/lib/python3.7/doctest.py:932: in find
 self._find(tests, obj, name, module, source_lines, globs, {})
[...]/lib/python3.7/doctest.py:993: in _find
 self._from_module(module, val)):
[...]/lib/python3.7/doctest.py:960: in _from_module
 return module.__name__ == object.__module__
E AttributeError: __module__
```

In doctest (https://github.com/python/cpython/blob/master/Lib/doctest.py#L959), 
the `inspect.isclass(object)` condition at line 959 returns `True`, and 
therefore doctest tries to access the object's `__module__` attribute, which 
does not seem to exist.

Besides, pytest prints a warning for each Java class being wrapped, also 
because they have no __module__ attribute (this is one example of 1000+ 
warnings):
```
[...]/lib/python3.7/importlib/_bootstrap.py:219: DeprecationWarning: builtin 
type ExtendedKalmanFilter has no __module__ attribute
 return f(*args, **kwds)
```

This phenomenon is new because 6 months ago I could run pytest & doctest 
successfully with Orekit. I could not find which module contains the change 
that broke stuff since then though.

To reproduce the phenomenon, you can check out 
https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164
I was trying to validate some poliastro features using the Orekit python 
wrapper. So this code requires poliastro, it is available on conda-forge.

Cheers

Clément



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: 8.3 release

2019-10-10 Thread Joel Bernstein 
I've plan on merging this bug fix as well:
https://issues.apache.org/jira/browse/SOLR-13829

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


On Thu, Oct 10, 2019 at 6:21 PM Gus Heck  wrote:

> I'll be merging SOLR-13760 tonight as well
>
>
> On Thu, Oct 10, 2019 at 5:57 PM Andrzej Białecki  wrote:
>
>> Hi Ishan,
>>
>> Me too, me too :) I’d like to merge a bug fix for SOLR-13828.
>>
>> On 9 Oct 2019, at 15:38, Ishan Chattopadhyaya 
>> wrote:
>>
>> +1, Dat! Please go ahead.
>>
>> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  wrote:
>>
>>> It’s marked as Minor in Jira, but after reading the description it
>>> sounds scary - IMHO it should be at least well investigated before 8.3 in
>>> order to determine whether it causes real damage (apart from looking scary
>>> and filling the logs).
>>>
>>> +1 from me.
>>>
>>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:
>>>
>>> Hi Ishan, guys
>>>
>>> I want to include the fix for
>>> https://issues.apache.org/jira/browse/SOLR-13293 in this release.
>>> Hoping that is ok!
>>>
>>> Thanks!
>>>
>>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:
>>>
 ASF Jenkins Jobs also reconfigured.

 I left the 8.2 Refguide job in the queue (I cloned it), not sure if
 that one is still needed. All other jobs are 8.3 now.

 Uwe

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

 > -Original Message-
 > From: Uwe Schindler 
 > Sent: Tuesday, October 8, 2019 4:49 PM
 > To: dev@lucene.apache.org
 > Subject: RE: 8.3 release
 >
 > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
 >
 > Uwe
 >
 > -
 > Uwe Schindler
 > Achterdiek 19, D-28357 Bremen
 > https://www.thetaphi.de
 > eMail: u...@thetaphi.de
 >
 > > -Original Message-
 > > From: Ishan Chattopadhyaya 
 > > Sent: Tuesday, October 8, 2019 4:32 PM
 > > To: Lucene Dev ; Uwe Schindler
 > > ; Steve Rowe 
 > > Subject: Re: 8.3 release
 > >
 > > I've cut the 8.3 branch. Please feel free to push in any bug fix.
 For
 > > any feature, please let me know to see how we can accommodate it
 > > safely.
 > > I'm planning to get myself familiarized with what I need to do for
 the
 > > ref guide release (simultaneously with the binary release). So, most
 > > likely, I'll be able to build artifacts in another week's time.
 > > @Uwe Schindler / @Steve Rowe  would it be possible to please create
 a
 > > Jenkins branch for 8.3?
 > > Thanks,
 > > Ishan
 > >
 > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
 > >  wrote:
 > > >
 > > > I'll cut the branch in 12-24 hours from now. If someone has
 anything
 > > > to put into branch_8x now, please feel free.
 > > > If someone has a non-bugfix issue that they want to push in to 8.3
 > > > after the branch cut, but you're sure it will not disrupt the
 > > > stability of the release, please let me know and we can discuss
 on a
 > > > case-by-case basis.
 > > >
 > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev 
 > > wrote:
 > > > >
 > > > > Excuse me. I have to recall this message regarding SOLR-13764.
 > > > >
 > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
 > >  wrote:
 > > > >>
 > > > >> Ishan, thanks for update.
 > > > >> May I propose to hold it for this week, beside of the severe
 issues you
 > > mentioned, I'd like to drop pretty neat JSON Query parser for
 Interval
 > > Queries https://issues.apache.org/jira/browse/SOLR-13764 this week.
 > > > >>
 > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
 > > :
 > > > >>>
 > > > >>> * Due to some unfinished and half merged work in SOLR-13661,
 we
 > are
 > > in
 > > > >>> a difficult position for a branch cutting today (as I had
 proposed).
 > > > >>> I have documented the options on how to deal with that
 immediately
 > > in
 > > > >>> that issue. I'll work to resolve the situation and cut a
 branch as
 > > > >>> soon as possible.
 > > > >>> * SOLR-13677 is also a blocker for release, but I can proceed
 with the
 > > > >>> branch cutting.
 > > > >>>
 > > > >>> I'll take a look at the ref guide's simultaneous release as
 we reach
 > > > >>> closer to building the artifacts.
 > > > >>> Thanks,
 > > > >>> Ishan
 > > > >>>
 > > > >>> On Wed, Sep 18, 2019 at 9:06 PM Cassandra Targett
 > >  wrote:
 > > > >>> >
 > > > >>> > As I’ve mentioned to some of you over the past couple of
 weeks, I
 > > want to propose that we don’t “release” the Ref Guide at all the
 way we
 > have
 > > been doing it.
 > > > >>> >
 > > > >>> > It deserves a separate thread, which since it’s come up a
 few times
 > > this week

Re: 8.3 release

2019-10-10 Thread Gus Heck 
I'll be merging SOLR-13760 tonight as well


On Thu, Oct 10, 2019 at 5:57 PM Andrzej Białecki  wrote:

> Hi Ishan,
>
> Me too, me too :) I’d like to merge a bug fix for SOLR-13828.
>
> On 9 Oct 2019, at 15:38, Ishan Chattopadhyaya 
> wrote:
>
> +1, Dat! Please go ahead.
>
> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  wrote:
>
>> It’s marked as Minor in Jira, but after reading the description it sounds
>> scary - IMHO it should be at least well investigated before 8.3 in order to
>> determine whether it causes real damage (apart from looking scary and
>> filling the logs).
>>
>> +1 from me.
>>
>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:
>>
>> Hi Ishan, guys
>>
>> I want to include the fix for
>> https://issues.apache.org/jira/browse/SOLR-13293 in this release. Hoping
>> that is ok!
>>
>> Thanks!
>>
>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:
>>
>>> ASF Jenkins Jobs also reconfigured.
>>>
>>> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that
>>> one is still needed. All other jobs are 8.3 now.
>>>
>>> Uwe
>>>
>>> -
>>> Uwe Schindler
>>> Achterdiek 19, D-28357 Bremen
>>> https://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>>
>>> > -Original Message-
>>> > From: Uwe Schindler 
>>> > Sent: Tuesday, October 8, 2019 4:49 PM
>>> > To: dev@lucene.apache.org
>>> > Subject: RE: 8.3 release
>>> >
>>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
>>> >
>>> > Uwe
>>> >
>>> > -
>>> > Uwe Schindler
>>> > Achterdiek 19, D-28357 Bremen
>>> > https://www.thetaphi.de
>>> > eMail: u...@thetaphi.de
>>> >
>>> > > -Original Message-
>>> > > From: Ishan Chattopadhyaya 
>>> > > Sent: Tuesday, October 8, 2019 4:32 PM
>>> > > To: Lucene Dev ; Uwe Schindler
>>> > > ; Steve Rowe 
>>> > > Subject: Re: 8.3 release
>>> > >
>>> > > I've cut the 8.3 branch. Please feel free to push in any bug fix. For
>>> > > any feature, please let me know to see how we can accommodate it
>>> > > safely.
>>> > > I'm planning to get myself familiarized with what I need to do for
>>> the
>>> > > ref guide release (simultaneously with the binary release). So, most
>>> > > likely, I'll be able to build artifacts in another week's time.
>>> > > @Uwe Schindler / @Steve Rowe  would it be possible to please create a
>>> > > Jenkins branch for 8.3?
>>> > > Thanks,
>>> > > Ishan
>>> > >
>>> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
>>> > >  wrote:
>>> > > >
>>> > > > I'll cut the branch in 12-24 hours from now. If someone has
>>> anything
>>> > > > to put into branch_8x now, please feel free.
>>> > > > If someone has a non-bugfix issue that they want to push in to 8.3
>>> > > > after the branch cut, but you're sure it will not disrupt the
>>> > > > stability of the release, please let me know and we can discuss on
>>> a
>>> > > > case-by-case basis.
>>> > > >
>>> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev 
>>> > > wrote:
>>> > > > >
>>> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
>>> > > > >
>>> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
>>> > >  wrote:
>>> > > > >>
>>> > > > >> Ishan, thanks for update.
>>> > > > >> May I propose to hold it for this week, beside of the severe
>>> issues you
>>> > > mentioned, I'd like to drop pretty neat JSON Query parser for
>>> Interval
>>> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 this week.
>>> > > > >>
>>> > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
>>> > > :
>>> > > > >>>
>>> > > > >>> * Due to some unfinished and half merged work in SOLR-13661, we
>>> > are
>>> > > in
>>> > > > >>> a difficult position for a branch cutting today (as I had
>>> proposed).
>>> > > > >>> I have documented the options on how to deal with that
>>> immediately
>>> > > in
>>> > > > >>> that issue. I'll work to resolve the situation and cut a
>>> branch as
>>> > > > >>> soon as possible.
>>> > > > >>> * SOLR-13677 is also a blocker for release, but I can proceed
>>> with the
>>> > > > >>> branch cutting.
>>> > > > >>>
>>> > > > >>> I'll take a look at the ref guide's simultaneous release as we
>>> reach
>>> > > > >>> closer to building the artifacts.
>>> > > > >>> Thanks,
>>> > > > >>> Ishan
>>> > > > >>>
>>> > > > >>> On Wed, Sep 18, 2019 at 9:06 PM Cassandra Targett
>>> > >  wrote:
>>> > > > >>> >
>>> > > > >>> > As I’ve mentioned to some of you over the past couple of
>>> weeks, I
>>> > > want to propose that we don’t “release” the Ref Guide at all the way
>>> we
>>> > have
>>> > > been doing it.
>>> > > > >>> >
>>> > > > >>> > It deserves a separate thread, which since it’s come up a
>>> few times
>>> > > this week I should start now, but in essence, my idea is to no
>>> longer treat
>>> > the
>>> > > PDF as a release artifact that requires a vote, and publish the HTML
>>> as our
>>> > > primary version of the Ref Guide in effectively the same way we
>>> publish the
>>> > > javadocs (at the same time as the binary artifacts).
>>> > > > >>> >
>>> > > > >>> >

Re: 8.3 release

2019-10-10 Thread Andrzej Białecki 
Hi Ishan,

Me too, me too :) I’d like to merge a bug fix for SOLR-13828.

> On 9 Oct 2019, at 15:38, Ishan Chattopadhyaya  
> wrote:
> 
> +1, Dat! Please go ahead.
> 
> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  > wrote:
> It’s marked as Minor in Jira, but after reading the description it sounds 
> scary - IMHO it should be at least well investigated before 8.3 in order to 
> determine whether it causes real damage (apart from looking scary and filling 
> the logs).
> 
> +1 from me.
> 
>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh > > wrote:
>> 
>> Hi Ishan, guys
>> 
>> I want to include the fix for 
>> https://issues.apache.org/jira/browse/SOLR-13293 
>>  in this release. Hoping 
>> that is ok!
>> 
>> Thanks!
>> 
>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler > > wrote:
>> ASF Jenkins Jobs also reconfigured.
>> 
>> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that one 
>> is still needed. All other jobs are 8.3 now.
>> 
>> Uwe
>> 
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de 
>> eMail: u...@thetaphi.de 
>> 
>> > -Original Message-
>> > From: Uwe Schindler mailto:u...@thetaphi.de>>
>> > Sent: Tuesday, October 8, 2019 4:49 PM
>> > To: dev@lucene.apache.org 
>> > Subject: RE: 8.3 release
>> > 
>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
>> > 
>> > Uwe
>> > 
>> > -
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de 
>> > eMail: u...@thetaphi.de 
>> > 
>> > > -Original Message-
>> > > From: Ishan Chattopadhyaya > > > >
>> > > Sent: Tuesday, October 8, 2019 4:32 PM
>> > > To: Lucene Dev mailto:dev@lucene.apache.org>>; 
>> > > Uwe Schindler
>> > > mailto:uschind...@apache.org>>; Steve Rowe 
>> > > mailto:sar...@gmail.com>>
>> > > Subject: Re: 8.3 release
>> > >
>> > > I've cut the 8.3 branch. Please feel free to push in any bug fix. For
>> > > any feature, please let me know to see how we can accommodate it
>> > > safely.
>> > > I'm planning to get myself familiarized with what I need to do for the
>> > > ref guide release (simultaneously with the binary release). So, most
>> > > likely, I'll be able to build artifacts in another week's time.
>> > > @Uwe Schindler / @Steve Rowe  would it be possible to please create a
>> > > Jenkins branch for 8.3?
>> > > Thanks,
>> > > Ishan
>> > >
>> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
>> > > mailto:ichattopadhy...@gmail.com>> wrote:
>> > > >
>> > > > I'll cut the branch in 12-24 hours from now. If someone has anything
>> > > > to put into branch_8x now, please feel free.
>> > > > If someone has a non-bugfix issue that they want to push in to 8.3
>> > > > after the branch cut, but you're sure it will not disrupt the
>> > > > stability of the release, please let me know and we can discuss on a
>> > > > case-by-case basis.
>> > > >
>> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev > > > > >
>> > > wrote:
>> > > > >
>> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
>> > > > >
>> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
>> > > mailto:gge...@gmail.com>> wrote:
>> > > > >>
>> > > > >> Ishan, thanks for update.
>> > > > >> May I propose to hold it for this week, beside of the severe issues 
>> > > > >> you
>> > > mentioned, I'd like to drop pretty neat JSON Query parser for Interval
>> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 
>> > >  this week.
>> > > > >>
>> > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
>> > > mailto:ichattopadhy...@gmail.com>>:
>> > > > >>>
>> > > > >>> * Due to some unfinished and half merged work in SOLR-13661, we
>> > are
>> > > in
>> > > > >>> a difficult position for a branch cutting today (as I had 
>> > > > >>> proposed).
>> > > > >>> I have documented the options on how to deal with that immediately
>> > > in
>> > > > >>> that issue. I'll work to resolve the situation and cut a branch as
>> > > > >>> soon as possible.
>> > > > >>> * SOLR-13677 is also a blocker for release, but I can proceed with 
>> > > > >>> the
>> > > > >>> branch cutting.
>> > > > >>>
>> > > > >>> I'll take a look at the ref guide's simultaneous release as we 
>> > > > >>> reach
>> > > > >>> closer to building the artifacts.
>> > > > >>> Thanks,
>> > > > >>> Ishan
>> > > > >>>
>> > > > >>> On Wed, Sep 18, 2019 at 9:06 PM Cassandra Targett
>> > > mailto:casstarg...@gmail.com>> wrote:
>> > > > >>> >
>> > > > >>> > As I’ve mentioned to some of you over the past couple of weeks, I
>> > > want to propose that we don’t “release” the Ref Guide at all the way we
>> > have
>> > > been doing it.

GitBox emails in issues@ list

2019-10-10 Thread Jan Høydahl 
GitBox emails on the issues@ list are not threaded per PullRequest.
It would be very beneficial if all GitBox mails for the same PR# be grouped in 
same thread for easier consumption.
I guess that would mean they have identical Email Subject, instead of today 
when the Subject varies per comment:

[GitHub] [lucene-solr] chatman commented on a change in pull request #929: 
SOLR-13821: Package Store for storing package artefacts

Anyone know if it is possible?

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


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

Re: 8.3 release

2019-10-10 Thread Ishan Chattopadhyaya 
+1, Ignacio. Please feel free to do the needful, I'll wait until this is
resolved.

+1, Jan. Sure, I think we should get it in!


On Thu, 10 Oct, 2019, 5:45 PM Đạt Cao Mạnh,  wrote:

> Hi Ishan,
>
> I pushed the fix to branch_8_3.
>
> On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl 
> wrote:
>
>> Ishan, I'd like to get https://issues.apache.org/jira/browse/SOLR-13665
>> included, since without it Solr won't work with SSL against Zookeeper.
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera :
>>
>> Hi Ishan,
>>
>> Thanks for taking care of the release. We have a blocker in Lucene (see
>> https://issues.apache.org/jira/browse/LUCENE-8920). I remember that was
>> an issue for the 8.2.0 release and it was reverted and naked as a blocker
>> for this release. Maybe we should completely reverted until we have a
>> better solution? let see what Mike thinks about it.
>>
>> Thanks,
>>
>> Ignacio
>>
>> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  wrote:
>>
>>> Hi,
>>>
>>> I also had a customer complaining about this. I have the feeling it also
>>> happens from time to time during inter node comm, which uses solrj, too.
>>>
>>> Uwe
>>>
>>> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com>:

 +1, Dat! Please go ahead.

 On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  wrote:

> It’s marked as Minor in Jira, but after reading the description it
> sounds scary - IMHO it should be at least well investigated before 8.3 in
> order to determine whether it causes real damage (apart from looking scary
> and filling the logs).
>
> +1 from me.
>
> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:
>
> Hi Ishan, guys
>
> I want to include the fix for
> https://issues.apache.org/jira/browse/SOLR-13293 in this release.
> Hoping that is ok!
>
> Thanks!
>
> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:
>
>> ASF Jenkins Jobs also reconfigured.
>>
>> I left the 8.2 Refguide job in the queue (I cloned it), not sure if
>> that one is still needed. All other jobs are 8.3 now.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Uwe Schindler 
>> > Sent: Tuesday, October 8, 2019 4:49 PM
>> > To: dev@lucene.apache.org
>> > Subject: RE: 8.3 release
>> >
>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
>> >
>> > Uwe
>> >
>> > -
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de
>> > eMail: u...@thetaphi.de
>> >
>> > > -Original Message-
>> > > From: Ishan Chattopadhyaya 
>> > > Sent: Tuesday, October 8, 2019 4:32 PM
>> > > To: Lucene Dev ; Uwe Schindler
>> > > ; Steve Rowe 
>> > > Subject: Re: 8.3 release
>> > >
>> > > I've cut the 8.3 branch. Please feel free to push in any bug fix.
>> For
>> > > any feature, please let me know to see how we can accommodate it
>> > > safely.
>> > > I'm planning to get myself familiarized with what I need to do
>> for the
>> > > ref guide release (simultaneously with the binary release). So,
>> most
>> > > likely, I'll be able to build artifacts in another week's time.
>> > > @Uwe Schindler / @Steve Rowe  would it be possible to please
>> create a
>> > > Jenkins branch for 8.3?
>> > > Thanks,
>> > > Ishan
>> > >
>> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
>> > >  wrote:
>> > > >
>> > > > I'll cut the branch in 12-24 hours from now. If someone has
>> anything
>> > > > to put into branch_8x now, please feel free.
>> > > > If someone has a non-bugfix issue that they want to push in to
>> 8.3
>> > > > after the branch cut, but you're sure it will not disrupt the
>> > > > stability of the release, please let me know and we can discuss
>> on a
>> > > > case-by-case basis.
>> > > >
>> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev <
>> m...@apache.org>
>> > > wrote:
>> > > > >
>> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
>> > > > >
>> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
>> > >  wrote:
>> > > > >>
>> > > > >> Ishan, thanks for update.
>> > > > >> May I propose to hold it for this week, beside of the severe
>> issues you
>> > > mentioned, I'd like to drop pretty neat JSON Query parser for
>> Interval
>> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 this
>> week.
>> > > > >>
>> > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
>> > > :
>> > > > >>>
>> > > > >>> * Due to some unfinished and

Re: Field.setStringValue

2019-10-10 Thread Andi Vajda 
It's fixed now in JCC's trunk.

Andi..

> On Oct 10, 2019, at 05:18, Marc Jeurissen  
> wrote:
> 
> Ok thank you Andi.
> I’ll use the sidepath with the bytes for the moment.
> Hope it will get solved soon though.
>  
>  
> Met vriendelijke groeten,
> Marc Jeurissen
> 
> 
> 
> Bibliotheek UAntwerpen
> Stadscampus – Ve35.303
> Venusstraat 35 – 2000 Antwerpen
> marc.jeuris...@uantwerpen.be
> T +32 3 265 49 71
>  
> 
>  
> From: Andi Vajda
> Sent: woensdag 9 oktober 2019 23:33
> To: Andi Vajda
> Cc: pylucene-dev@lucene.apache.org
> Subject: Re: Field.setStringValue
>  
>  
> On Wed, 9 Oct 2019, Andi Vajda wrote:
>  
> > 
> > On Wed, 9 Oct 2019, Marc Jeurissen wrote:
> > 
> >> Good day to you,
> >>
> >> I have the following issue when setting the value of a field, value
> >> containing a character > 160 (Pylucene 8.1.1, Python 3.7.2)
> >>
> >> ...
> >> (Pdb) field
> >>  >> indexOptions=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS>
> >> (Pdb) value = '«Volgende facturen werden verstuurd aan de financiële
> >> dienst.»'
> >> (Pdb) type(value)
> >> 
> >> (Pdb) field.setStringValue(value)
> >> (Pdb) field
> >>  >> stored,indexed,tokenized,omitNorms,indexOptions=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS >> facturen werden verstuurd aan de financiële dienst>>
> >>
> >> The field value has lost 2 characters.
> >>
> >> But when I encode value:
> >>
> >> (Pdb) value = value.encode('utf-8')
> >> (Pdb) value
> >> b'\xc2\xabVolgende facturen werden verstuurd aan de financi\xc3\xable
> >> dienst.\xc2\xbb'
> >>
> >> (Pdb) field.setStringValue(value)
> >> (Pdb) field
> >>  >> stored,indexed,tokenized,omitNorms,indexOptions=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS >> facturen werden verstuurd aan de financiële dienst.»>>
> >>
> >> The field value is correct.
> >>
> >> So what does field.setStringValue expect: a string (as says the Lucene
> >> documentation) or a byte sequence?
> > 
> > Indeed, there is a problem. I was able to reproduce it with just
> > StringBuffer, no lucene involved at all:
> > 
>  from lucene import initVM
>  initVM()
>  b=b'\xc2\xabVolgende facturen werden verstuurd aan de
>  financi\xc3\xabledienst.\xc2\xbb'
>  a=b.decode('utf-8')
>  from java.lang import StringBuffer
>  StringBuffer(b)
> >  > financiëledienst.»>
>  StringBuffer(a)
> > 
>  StringBuffer(a).length()
> > 59
>  StringBuffer(b).length()
> > 61
>  type(a)
> > 
>  type(b)
> > 
> > 
> > There must be a bug in the Python 'str' -> Java 'String' conversion code.
> > Any Java API such as field.setStringValue() that expects a 
> > java.lang.String()
> > can be passed a 'str' or 'bytes', JCC auto-converts as needed. This is very
> > likely where the bug is.
>  
> Digging a bit further, it doesn't seem to be a problem when using Python 2.
> I'm not implying this is a python bug, strings are just very different
> between python 2 and 3.
>  
> Andi..
>  
> > 
> > Andi..
> > 
> >>
> >> Thank you very much.
> >>
> >>
> >> Met vriendelijke groeten,
> >> Marc Jeurissen
> >>
> >> Bibliotheek UAntwerpen
> >> Stadscampus ? Ve35.303
> >> Venusstraat 35 ? 2000 Antwerpen
> >> marc.jeuris...@uantwerpen.be
> >> T +32 3 265 49 71
> >>
> >>
> >>
> > 
>

RE: Field.setStringValue

2019-10-10 Thread Marc Jeurissen 
Ok thank you Andi.
I’ll use the sidepath with the bytes for the moment.
Hope it will get solved soon though.


Met vriendelijke groeten,
Marc Jeurissen

Bibliotheek UAntwerpen
Stadscampus – Ve35.303
Venusstraat 35 – 2000 Antwerpen
marc.jeuris...@uantwerpen.be
T +32 3 265 49 71



From: Andi Vajda
Sent: woensdag 9 oktober 2019 23:33
To: Andi Vajda
Cc: pylucene-dev@lucene.apache.org
Subject: Re: Field.setStringValue


On Wed, 9 Oct 2019, Andi Vajda wrote:

>
> On Wed, 9 Oct 2019, Marc Jeurissen wrote:
>
>> Good day to you,
>> 
>> I have the following issue when setting the value of a field, value 
>> containing a character > 160 (Pylucene 8.1.1, Python 3.7.2)
>> 
>> ...
>> (Pdb) field
>> > indexOptions=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS>
>> (Pdb) value = '«Volgende facturen werden verstuurd aan de financiële 
>> dienst.»'
>> (Pdb) type(value)
>> 
>> (Pdb) field.setStringValue(value)
>> (Pdb) field
>> > stored,indexed,tokenized,omitNorms,indexOptions=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS>  
>> facturen werden verstuurd aan de financiële dienst>>
>> 
>> The field value has lost 2 characters.
>> 
>> But when I encode value:
>> 
>> (Pdb) value = value.encode('utf-8')
>> (Pdb) value
>> b'\xc2\xabVolgende facturen werden verstuurd aan de financi\xc3\xable 
>> dienst.\xc2\xbb'
>> 
>> (Pdb) field.setStringValue(value)
>> (Pdb) field
>> > stored,indexed,tokenized,omitNorms,indexOptions=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS>  
>> facturen werden verstuurd aan de financiële dienst.»>>
>> 
>> The field value is correct.
>> 
>> So what does field.setStringValue expect: a string (as says the Lucene 
>> documentation) or a byte sequence?
>
> Indeed, there is a problem. I was able to reproduce it with just 
> StringBuffer, no lucene involved at all:
>
 from lucene import initVM
 initVM()
 b=b'\xc2\xabVolgende facturen werden verstuurd aan de 
 financi\xc3\xabledienst.\xc2\xbb'
 a=b.decode('utf-8')
 from java.lang import StringBuffer
 StringBuffer(b)
> 
 StringBuffer(a)
> 
 StringBuffer(a).length()
> 59
 StringBuffer(b).length()
> 61
 type(a)
> 
 type(b)
> 
>
> There must be a bug in the Python 'str' -> Java 'String' conversion code.
> Any Java API such as field.setStringValue() that expects a java.lang.String() 
> can be passed a 'str' or 'bytes', JCC auto-converts as needed. This is very 
> likely where the bug is.

Digging a bit further, it doesn't seem to be a problem when using Python 2. 
I'm not implying this is a python bug, strings are just very different 
between python 2 and 3.

Andi..

>
> Andi..
>
>> 
>> Thank you very much.
>> 
>> 
>> Met vriendelijke groeten,
>> Marc Jeurissen
>> 
>> Bibliotheek UAntwerpen
>> Stadscampus ? Ve35.303
>> Venusstraat 35 ? 2000 Antwerpen
>> marc.jeuris...@uantwerpen.be
>> T +32 3 265 49 71
>> 
>> 
>> 
>

Re: 8.3 release

2019-10-10 Thread Đạt Cao Mạnh 
Hi Ishan,

I pushed the fix to branch_8_3.

On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl  wrote:

> Ishan, I'd like to get https://issues.apache.org/jira/browse/SOLR-13665
> included, since without it Solr won't work with SSL against Zookeeper.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera :
>
> Hi Ishan,
>
> Thanks for taking care of the release. We have a blocker in Lucene (see
> https://issues.apache.org/jira/browse/LUCENE-8920). I remember that was
> an issue for the 8.2.0 release and it was reverted and naked as a blocker
> for this release. Maybe we should completely reverted until we have a
> better solution? let see what Mike thinks about it.
>
> Thanks,
>
> Ignacio
>
> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  wrote:
>
>> Hi,
>>
>> I also had a customer complaining about this. I have the feeling it also
>> happens from time to time during inter node comm, which uses solrj, too.
>>
>> Uwe
>>
>> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>:
>>>
>>> +1, Dat! Please go ahead.
>>>
>>> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  wrote:
>>>
 It’s marked as Minor in Jira, but after reading the description it
 sounds scary - IMHO it should be at least well investigated before 8.3 in
 order to determine whether it causes real damage (apart from looking scary
 and filling the logs).

 +1 from me.

 On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:

 Hi Ishan, guys

 I want to include the fix for
 https://issues.apache.org/jira/browse/SOLR-13293 in this release.
 Hoping that is ok!

 Thanks!

 On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:

> ASF Jenkins Jobs also reconfigured.
>
> I left the 8.2 Refguide job in the queue (I cloned it), not sure if
> that one is still needed. All other jobs are 8.3 now.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Tuesday, October 8, 2019 4:49 PM
> > To: dev@lucene.apache.org
> > Subject: RE: 8.3 release
> >
> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Ishan Chattopadhyaya 
> > > Sent: Tuesday, October 8, 2019 4:32 PM
> > > To: Lucene Dev ; Uwe Schindler
> > > ; Steve Rowe 
> > > Subject: Re: 8.3 release
> > >
> > > I've cut the 8.3 branch. Please feel free to push in any bug fix.
> For
> > > any feature, please let me know to see how we can accommodate it
> > > safely.
> > > I'm planning to get myself familiarized with what I need to do for
> the
> > > ref guide release (simultaneously with the binary release). So,
> most
> > > likely, I'll be able to build artifacts in another week's time.
> > > @Uwe Schindler / @Steve Rowe  would it be possible to please
> create a
> > > Jenkins branch for 8.3?
> > > Thanks,
> > > Ishan
> > >
> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
> > >  wrote:
> > > >
> > > > I'll cut the branch in 12-24 hours from now. If someone has
> anything
> > > > to put into branch_8x now, please feel free.
> > > > If someone has a non-bugfix issue that they want to push in to
> 8.3
> > > > after the branch cut, but you're sure it will not disrupt the
> > > > stability of the release, please let me know and we can discuss
> on a
> > > > case-by-case basis.
> > > >
> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev  >
> > > wrote:
> > > > >
> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
> > > > >
> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
> > >  wrote:
> > > > >>
> > > > >> Ishan, thanks for update.
> > > > >> May I propose to hold it for this week, beside of the severe
> issues you
> > > mentioned, I'd like to drop pretty neat JSON Query parser for
> Interval
> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 this
> week.
> > > > >>
> > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
> > > :
> > > > >>>
> > > > >>> * Due to some unfinished and half merged work in SOLR-13661,
> we
> > are
> > > in
> > > > >>> a difficult position for a branch cutting today (as I had
> proposed).
> > > > >>> I have documented the options on how to deal with that
> immediately
> > > in
> > > > >>> that issue. I'll work to resolve the situation and cut a
> branch as
>

Re: 8.3 release

2019-10-10 Thread Jan Høydahl 
Ishan, I'd like to get https://issues.apache.org/jira/browse/SOLR-13665 
included, since without it Solr won't work with SSL against Zookeeper.

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

> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera :
> 
> Hi Ishan,
> 
> Thanks for taking care of the release. We have a blocker in Lucene (see 
> https://issues.apache.org/jira/browse/LUCENE-8920 
> ). I remember that was an 
> issue for the 8.2.0 release and it was reverted and naked as a blocker for 
> this release. Maybe we should completely reverted until we have a better 
> solution? let see what Mike thinks about it.
> 
> Thanks,
> 
> Ignacio
> 
> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  > wrote:
> Hi,
> 
> I also had a customer complaining about this. I have the feeling it also 
> happens from time to time during inter node comm, which uses solrj, too.
> 
> Uwe
> 
> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>>:
> +1, Dat! Please go ahead.
> 
> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  > wrote:
> It’s marked as Minor in Jira, but after reading the description it sounds 
> scary - IMHO it should be at least well investigated before 8.3 in order to 
> determine whether it causes real damage (apart from looking scary and filling 
> the logs).
> 
> +1 from me.
> 
>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh > > wrote:
>> 
>> Hi Ishan, guys
>> 
>> I want to include the fix for 
>> https://issues.apache.org/jira/browse/SOLR-13293 
>>  in this release. Hoping 
>> that is ok!
>> 
>> Thanks!
>> 
>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler > > wrote:
>> ASF Jenkins Jobs also reconfigured.
>> 
>> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that one 
>> is still needed. All other jobs are 8.3 now.
>> 
>> Uwe
>> 
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de 
>> eMail: u...@thetaphi.de 
>> 
>> > -Original Message-
>> > From: Uwe Schindler mailto:u...@thetaphi.de>>
>> > Sent: Tuesday, October 8, 2019 4:49 PM
>> > To: dev@lucene.apache.org 
>> > Subject: RE: 8.3 release
>> > 
>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
>> > 
>> > Uwe
>> > 
>> > -
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de 
>> > eMail: u...@thetaphi.de 
>> > 
>> > > -Original Message-
>> > > From: Ishan Chattopadhyaya > > > >
>> > > Sent: Tuesday, October 8, 2019 4:32 PM
>> > > To: Lucene Dev mailto:dev@lucene.apache.org>>; 
>> > > Uwe Schindler
>> > > mailto:uschind...@apache.org>>; Steve Rowe 
>> > > mailto:sar...@gmail.com>>
>> > > Subject: Re: 8.3 release
>> > >
>> > > I've cut the 8.3 branch. Please feel free to push in any bug fix. For
>> > > any feature, please let me know to see how we can accommodate it
>> > > safely.
>> > > I'm planning to get myself familiarized with what I need to do for the
>> > > ref guide release (simultaneously with the binary release). So, most
>> > > likely, I'll be able to build artifacts in another week's time.
>> > > @Uwe Schindler / @Steve Rowe  would it be possible to please create a
>> > > Jenkins branch for 8.3?
>> > > Thanks,
>> > > Ishan
>> > >
>> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
>> > > mailto:ichattopadhy...@gmail.com>> wrote:
>> > > >
>> > > > I'll cut the branch in 12-24 hours from now. If someone has anything
>> > > > to put into branch_8x now, please feel free.
>> > > > If someone has a non-bugfix issue that they want to push in to 8.3
>> > > > after the branch cut, but you're sure it will not disrupt the
>> > > > stability of the release, please let me know and we can discuss on a
>> > > > case-by-case basis.
>> > > >
>> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev > > > > >
>> > > wrote:
>> > > > >
>> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
>> > > > >
>> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
>> > > mailto:gge...@gmail.com>> wrote:
>> > > > >>
>> > > > >> Ishan, thanks for update.
>> > > > >> May I propose to hold it for this week, beside of the severe issues 
>> > > > >> you
>> > > mentioned, I'd like to drop pretty neat JSON Query parser for Interval
>> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 
>> > >  this week.
>> > > > >>
>> > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
>> > > mailto:ichattopadhy...@gmail.com>>:
>> > > > >>>
>> > > > >>> * Due to some unfinished and half merged work in SOLR-13661, we
>> > are
>> > > in

Re: 8.3 release

2019-10-10 Thread Ignacio Vera 
Hi Ishan,

Thanks for taking care of the release. We have a blocker in Lucene (see
https://issues.apache.org/jira/browse/LUCENE-8920). I remember that was an
issue for the 8.2.0 release and it was reverted and naked as a blocker for
this release. Maybe we should completely reverted until we have a better
solution? let see what Mike thinks about it.

Thanks,

Ignacio

On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  wrote:

> Hi,
>
> I also had a customer complaining about this. I have the feeling it also
> happens from time to time during inter node comm, which uses solrj, too.
>
> Uwe
>
> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com>:
>>
>> +1, Dat! Please go ahead.
>>
>> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  wrote:
>>
>>> It’s marked as Minor in Jira, but after reading the description it
>>> sounds scary - IMHO it should be at least well investigated before 8.3 in
>>> order to determine whether it causes real damage (apart from looking scary
>>> and filling the logs).
>>>
>>> +1 from me.
>>>
>>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:
>>>
>>> Hi Ishan, guys
>>>
>>> I want to include the fix for
>>> https://issues.apache.org/jira/browse/SOLR-13293 in this release.
>>> Hoping that is ok!
>>>
>>> Thanks!
>>>
>>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:
>>>
 ASF Jenkins Jobs also reconfigured.

 I left the 8.2 Refguide job in the queue (I cloned it), not sure if
 that one is still needed. All other jobs are 8.3 now.

 Uwe

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

 > -Original Message-
 > From: Uwe Schindler 
 > Sent: Tuesday, October 8, 2019 4:49 PM
 > To: dev@lucene.apache.org
 > Subject: RE: 8.3 release
 >
 > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
 >
 > Uwe
 >
 > -
 > Uwe Schindler
 > Achterdiek 19, D-28357 Bremen
 > https://www.thetaphi.de
 > eMail: u...@thetaphi.de
 >
 > > -Original Message-
 > > From: Ishan Chattopadhyaya 
 > > Sent: Tuesday, October 8, 2019 4:32 PM
 > > To: Lucene Dev ; Uwe Schindler
 > > ; Steve Rowe 
 > > Subject: Re: 8.3 release
 > >
 > > I've cut the 8.3 branch. Please feel free to push in any bug fix.
 For
 > > any feature, please let me know to see how we can accommodate it
 > > safely.
 > > I'm planning to get myself familiarized with what I need to do for
 the
 > > ref guide release (simultaneously with the binary release). So, most
 > > likely, I'll be able to build artifacts in another week's time.
 > > @Uwe Schindler / @Steve Rowe  would it be possible to please create
 a
 > > Jenkins branch for 8.3?
 > > Thanks,
 > > Ishan
 > >
 > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
 > >  wrote:
 > > >
 > > > I'll cut the branch in 12-24 hours from now. If someone has
 anything
 > > > to put into branch_8x now, please feel free.
 > > > If someone has a non-bugfix issue that they want to push in to 8.3
 > > > after the branch cut, but you're sure it will not disrupt the
 > > > stability of the release, please let me know and we can discuss
 on a
 > > > case-by-case basis.
 > > >
 > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev 
 > > wrote:
 > > > >
 > > > > Excuse me. I have to recall this message regarding SOLR-13764.
 > > > >
 > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
 > >  wrote:
 > > > >>
 > > > >> Ishan, thanks for update.
 > > > >> May I propose to hold it for this week, beside of the severe
 issues you
 > > mentioned, I'd like to drop pretty neat JSON Query parser for
 Interval
 > > Queries https://issues.apache.org/jira/browse/SOLR-13764 this week.
 > > > >>
 > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
 > > :
 > > > >>>
 > > > >>> * Due to some unfinished and half merged work in SOLR-13661,
 we
 > are
 > > in
 > > > >>> a difficult position for a branch cutting today (as I had
 proposed).
 > > > >>> I have documented the options on how to deal with that
 immediately
 > > in
 > > > >>> that issue. I'll work to resolve the situation and cut a
 branch as
 > > > >>> soon as possible.
 > > > >>> * SOLR-13677 is also a blocker for release, but I can proceed
 with the
 > > > >>> branch cutting.
 > > > >>>
 > > > >>> I'll take a look at the ref guide's simultaneous release as
 we reach
 > > > >>> closer to building the artifacts.
 > > > >>> Thanks,
 > > > >>> Ishan
 > > > >>>
 > > > >>> On Wed, Sep 18, 2019 at 9:06 PM Cassandra Targett
 > >  wrote:
 > > > >>> >
 > > > >>> > As I’ve mentioned to some of you over the past couple of
 weeks, I

Re: The Lucene Solr Gradle Build Game plan

2019-10-10 Thread Dawid Weiss 
Ping, ping. I wanted to finalize the build of solr ref guide since I
started it. Almost everything is working on the branch but I can't get
minor differences to work and I believe they're due to a different
jekyll version (than that mentioned in the docs).

Specifically, the invalid links are because of asciidoc sections like
this (in the processed resource-and-plugin-loading.adoc):

=== solr_home/lib

In bare bones html (pure asciidoctor) this gets emitted as:

solr_home/lib

but when compiled via jekyll this becomes:

solr_home/lib

which I can't really explain.

Cassandra what's the exact version of jekyll that runs the compilation
that is working for you?

D.

On Fri, Oct 4, 2019 at 11:42 AM Dawid Weiss  wrote:
>
> Seems like pygments is to blame for the python requirement... I didn't
> check but there seem to be ruby-only
> highlighters for jekyll as well:
>
> https://jekyll-windows.juthilo.com/3-syntax-highlighting/
>
> On Fri, Oct 4, 2019 at 11:39 AM Dawid Weiss  wrote:
> >
> > Hi Cassandra,
> >
> > Apologies this took so long -- I wasn't familiar with these
> > site-generation tools and the whole ecosystem is rather... fragile :)
> > After a few attempts at using gradle plugins I eventually leaned
> > towards using asciidoctor and jekyll explicitly (so that we know which
> > versions are being used and don't have to rely on dependencies).
> >
> > I got bare bone html checking working, PDF generation working and site
> > generation working although the final link check currently fail for me
> > with a bunch of errors. This works for me on Windows... on Linux I get
> > site-generation generate a strange error from within jekyll:
> >
> >   Conversion error: Jekyll::AsciiDoc::Converter encountered an error
> > while converting 'about-filters.adoc':
> > Bad file descriptor - /usr/bin/python2
> >
> > I could install python but I don't see why it'd need it. Perhaps there
> > is something in the docs that would avoid using python altogether but
> > I haven't had the time to look into it.
> >
> > Please feel free to check out the jira/SOLR-13452_gradle_7_refguide
> > branch and try to run:
> >
> > ./gradlew -p solr/solr-ref-guide buildPdf buildSite
> >
> > There is a lot of room for improvement -- from property substitution,
> > through how the "tools" are handled at the moment to task naming but I
> > left this for the future. The initial step would be probably to get
> > the site generation running on Linux/ Macs but I'd gladly hand it over
> > back to you -- I can help with Gradle but a the rest of those tools
> > are a mistery to me.
> >
> > Dawid
> >
> > On Fri, Sep 27, 2019 at 7:53 PM Dawid Weiss  wrote:
> > >
> > >
> > > No problem. I will get it to work entirely, but not before next week - I 
> > > am away for the weekend.
> > >
> > > Dawid
> > >
> > > On Fri, Sep 27, 2019, 16:17 Cassandra Targett  
> > > wrote:
> > >>
> > >> Thanks Dawid for working on this! I’ve been a bit swamped the last 
> > >> couple of days but will take a look today at what you’ve been able to do 
> > >> so far and see where we might need to go from here.
> > >>
> > >> Cassandra
> > >> On Sep 26, 2019, 7:25 AM -0500, Dawid Weiss , 
> > >> wrote:
> > >>
> > >> I agree. Although I also understand the concern of trying to merge the
> > >> changes while we're in the transition period... it'd be hell. I'd say
> > >> move as much stuff as possible with the current folder structure (and
> > >> ignore what cannot be ported easily) then switch as soon as possible
> > >> to gradle and hack the old cruft with a chainsaw...
> > >>
> > >> D.
> > >>
> > >> On Thu, Sep 26, 2019 at 2:13 PM Erick Erickson  
> > >> wrote:
> > >>
> > >>
> > >> Of course I’ll completely defer to Dawid and Mark (well and anybody else 
> > >> actually, you know, doing _work_), but just can’t resist chiming in ;).
> > >>
> > >> My vote would be to “do it the Gradle way”. Yes, it’s a PITA to learn 
> > >> new stuff and I won’t like it. Tough. I see no reason to carry a bunch 
> > >> of cruft around because “that the way we always did it”.
> > >>
> > >> If we lose functionality, that’s a different discussion, starting with 
> > >> “do we need that functionality". But jumping through hoops and having to 
> > >> maintain that awkwardness forever going forward just because we forced 
> > >> the Ant structure on Gradle strikes me as a poor trade off.
> > >>
> > >> That said, I’m not doing the work so I really have no vote. But don’t 
> > >> strain to do it the old way on my account ;)
> > >>
> > >> Erick
> > >>
> > >> P.S. Thanks Dawid for jumping in!
> > >>
> > >> On Sep 26, 2019, at 3:57 AM, Dawid Weiss  wrote:
> > >>
> > >> I pushed it in to Lucene repo (it's on Cassandra's refguide branch
> > >> anyway, so shouldn't interfere with anything else); seems like it's in
> > >> better shape than previous code anyway (those questions I asked about
> > >> the nature of the gradle port still hold though).
> > >>
> > >> I got as far as building initial