Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Anshum Gupta [mailto:ans...@anshumgupta.net]
>> *Sent:* Monday, August 21, 2017 3:31 AM
>> *To:* de
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Anshum Gupta [mailto:ans...@anshumgupta.net]
> *Sent:* Monday, August 21, 2017 3:31 AM
> *To:* dev@lucene.apache.org
> *Subject:*
, D-28357 Bremen
http://www.thetaphi.de <http://www.thetaphi.de/>
eMail: u...@thetaphi.de
From: Anshum Gupta [mailto:ans...@anshumgupta.net]
Sent: Monday, August 21, 2017 3:31 AM
To: dev@lucene.apache.org
Subject: Re: 7.0 Release Update
Let's not commit more stuff to 7.0, unless
, D-28357 Bremen
http://www.thetaphi.de <http://www.thetaphi.de/>
eMail: u...@thetaphi.de
From: Anshum Gupta [mailto:ans...@anshumgupta.net]
Sent: Monday, August 21, 2017 3:31 AM
To: dev@lucene.apache.org
Subject: Re: 7.0 Release Update
Let's not commit more stuff to 7.0, unless
There is a bug ishan has opened
SOLR-11268: AtomicUpdateProcessor complains missing UpdateLog
I have already talked to Anshum about it
On Mon, Aug 21, 2017 at 11:00 AM, Anshum Gupta wrote:
> Let's not commit more stuff to 7.0, unless it's a blocker as it gets hard to
> track.
> At this time, th
Let's not commit more stuff to 7.0, unless it's a blocker as it gets hard
to track.
At this time, the only commits that would be going in to 7.0 are the ones
that Varun spoke to me about back porting.
Once that is done, I'll cut an RC (most likely tomorrow). In the meanwhile,
I'll work on the relea
I've added SOLR-11183 to the release branch. Please let me know if someone
has any concerns.
Thanks,
Ishan
On Sun, Aug 20, 2017 at 5:55 PM, Yonik Seeley wrote:
> I opened https://issues.apache.org/jira/browse/SOLR-11262
> I don't know if it has implications for 7.0 or not.
>
> From the issue:
>
I opened https://issues.apache.org/jira/browse/SOLR-11262
I don't know if it has implications for 7.0 or not.
>From the issue:
"""This means that any code using PushWriter (via MapWriter or
IteratorWriter) will be broken if one tries to use XML response
format. This may easily go unnoticed if one
sorry for the last minute notice. I need to fix the folowing as well.
It may take a few hours
https://issues.apache.org/jira/browse/SOLR-11239
On Tue, Aug 15, 2017 at 6:41 AM, Andrzej Białecki
wrote:
> Then, if I may be so bold, I’d like to slip in SOLR-11235, which is a simple
> AlreadyClosedExc
Then, if I may be so bold, I’d like to slip in SOLR-11235, which is a simple
AlreadyClosedException prevention fix. Patch is ready, tests are passing.
> On 14 Aug 2017, at 19:17, Anshum Gupta wrote:
>
> Thanks Ab.
>
> I'll cut an RC on Wednesday, so that both, I get the time, and also that the
Thanks Ab.
I'll cut an RC on Wednesday, so that both, I get the time, and also that
the tests get some time on Jenkins.
Anshum
On Mon, Aug 14, 2017 at 5:29 AM Andrzej Białecki <
andrzej.biale...@lucidworks.com> wrote:
> Hi,
>
> I’ve committed the fix for SOLR-11221 to branch_7_0 (and branch_7x
Hi,
I’ve committed the fix for SOLR-11221 to branch_7_0 (and branch_7x and master).
> On 12 Aug 2017, at 02:20, Andrzej Białecki
> wrote:
>
> Hi Anshum,
>
> The patch for SOLR-11221 is ready, with one caveat - it required larger
> changes than I thought, so there’s a sizeable chunk of new co
Thanks Ab,
Let's get this in, and give it a couple of days on Jenkins (or get a
BeastIt report from Mark).
I'm +1 on releasing with this, and actually wouldn't want to release
without the fix.
Anshum
On Fri, Aug 11, 2017 at 5:20 PM Andrzej Białecki <
andrzej.biale...@lucidworks.com> wrote:
> H
Hi Anshum,
The patch for SOLR-11221 is ready, with one caveat - it required larger changes
than I thought, so there’s a sizeable chunk of new code that is not so well
tested… I added a test that used to fail without this change, and manual
testing confirms that metrics are now correctly reporte
bq. Thanks for the report Mark!
I hope to start doing this for all the releases and keep that info around a
while so that we can make a simple comparison release to release on top of
like a regularly weekly report.
- Mark
On Fri, Aug 11, 2017 at 1:59 PM Anshum Gupta wrote:
> Thanks for the rep
Thanks for the report Mark!
and yes, I'll wait until the JMX issue is fixed.
Anshum
On Fri, Aug 11, 2017 at 9:49 AM Mark Miller wrote:
> Yeah, let's not release a major version with JMX monitoring broken.
>
> Here is a 30 run test report for the 7.0 branch:
> http://apache-solr-7-0.bitballoon.
I'll do a report for Lucene as well before long by the way. Have not made a
config for it just yet.
- Mark
On Fri, Aug 11, 2017 at 12:49 PM Mark Miller wrote:
> Yeah, let's not release a major version with JMX monitoring broken.
>
> Here is a 30 run test report for the 7.0 branch:
> http://apac
Yeah, let's not release a major version with JMX monitoring broken.
Here is a 30 run test report for the 7.0 branch:
http://apache-solr-7-0.bitballoon.com/20170811
- Mark
On Thu, Aug 10, 2017 at 4:02 PM Tomas Fernandez Lobbe
wrote:
> Lets fix it before releasing. I’d hate to release with a kno
Lets fix it before releasing. I’d hate to release with a known critical bug.
> On Aug 10, 2017, at 12:54 PM, Anshum Gupta wrote:
>
> Hi Ab,
>
> How quickly are we talking about? If you suggest, we could wait, depending
> upon the impact, and the time required to fix it.
>
> Anshum
>
> On Thu
Hi Ab,
How quickly are we talking about? If you suggest, we could wait, depending
upon the impact, and the time required to fix it.
Anshum
On Thu, Aug 10, 2017 at 12:28 PM Andrzej Białecki <
andrzej.biale...@lucidworks.com> wrote:
> I just discovered SOLR-11221, which basically breaks JMX monit
I just discovered SOLR-11221, which basically breaks JMX monitoring. We could
either release with “known issues” and then quickly do 7.0.1, or wait until
it’s fixed.
> On 10 Aug 2017, at 18:55, Mark Miller wrote:
>
> I'll generate a test report for the 7.0 branch tonight so we can evaluate
>
I'll generate a test report for the 7.0 branch tonight so we can evaluate
that for an rc as well.
- Mark
On Mon, Aug 7, 2017 at 1:32 PM Anshum Gupta wrote:
> Good news!
>
> I don't see any 'blockers' for 7.0 anymore, which means, after giving
> Jenkins a couple of days, I'll cut out an RC. I in
Good news!
I don't see any 'blockers' for 7.0 anymore, which means, after giving
Jenkins a couple of days, I'll cut out an RC. I intend to do this on
Wednesday/Thursday, unless a blocker comes up, which I hope shouldn't be
the case.
Anshum
On Tue, Jul 25, 2017 at 4:02 PM Steve Rowe wrote:
> I
Thanks Steve, seems like we're really close. I'll be cutting an RC a couple
of days after the last blocker gets resolved, just to give Jenkins some
time.
Anshum
On Fri, Aug 4, 2017 at 5:44 PM Steve Rowe wrote:
> Oh, SOLR-11183 is also a Blocker, I just put 7.0 as fixVersion so that it
> will sh
Oh, SOLR-11183 is also a Blocker, I just put 7.0 as fixVersion so that it will
show up on the 7.0 Blockers JIRA query.
--
Steve
www.lucidworks.com
> On Aug 4, 2017, at 8:28 PM, Steve Rowe wrote:
>
> I’ve finished up addressing blockers. The only remaining one is SOLR-10939:
> JoinQParser giv
I’ve finished up addressing blockers. The only remaining one is SOLR-10939:
JoinQParser gives incorrect results with numeric PointsFields, which Yonik is
working on.
--
Steve
www.lucidworks.com
> On Jul 25, 2017, at 7:02 PM, Steve Rowe wrote:
>
> I worked through the list of issues with the
I worked through the list of issues with the "numeric-tries-to-points” label
and marked those as 7.0 Blocker that seemed reasonable, on the assumption that
we should at a minimum give clear error messages for points non-compatibility.
If others don’t agree with the Blocker assessments I’ve made,
I will *try* to get to it, but can't confirm. If someone else has a spare
cycle and can take it up before I get to it, please do.
-Anshum
On Tue, Jul 25, 2017 at 10:44 AM Cassandra Targett
wrote:
> I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
> fields as deprecated) is
I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
fields as deprecated) is SOLR-11023, which Hoss was working on. As he
noted last night, he is off for vacation for the next 2 weeks. Is
anyone else available to work on it so 7.0 isn't stalled for 2+ more
weeks?
Now would also b
: So, my overall point is that if A) we agree that we want to deprecate
: Trie* numeric fields, and B) we want to hold up the 7.0 release until
: that's done, it's more than just updating the example schemas if we
: want to ensure a quality app for users. We still need to fix the tests
: and also
On Tue, Jul 11, 2017 at 2:35 PM, Anshum Gupta wrote:
> Thanks for wording it in a much better manner Cassandra.
>
> The 2 points from my discussion with Hoss/Steve yesterday, are just about
> that. Changing the examples is just a part of what’s needed to *confidently*
> deprecate the Trie/Legacy N
Thanks for wording it in a much better manner Cassandra.
The 2 points from my discussion with Hoss/Steve yesterday, are just about that.
Changing the examples is just a part of what’s needed to *confidently*
deprecate the Trie/Legacy Numeric fields.
I intend to start helping out with the test,
It's more than just SOLR-10760, actually. SOLR-10760 is just about
updating the example schemas. No problem, easy to do, we could commit
it today. But I think focusing on that issue obscures the larger
situation.
If we care about having a quality application, though, we need to
address the other p
Here’s an update for 7.0 release.
We are (rightfully) waiting for SOLR-10760 to be completed so that we could
deprecate all Trie/LegacyNumeric based fields in 7.0. I discussed this with
Hoss, and Steve Rowe, and here are the 2 things that Hoss highlighted that were
not directly related for 7.0,
Thanks Steve.
On Mon, Jul 10, 2017 at 10:35 AM, Anshum Gupta wrote:
> Thanks Steve, and Cassandra.
>
> On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe wrote:
>>
>>
>> > On Jul 10, 2017, at 11:04 AM, Cassandra Targett
>> > wrote:
>> >
>> > We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - St
Thanks Steve, and Cassandra.
On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe wrote:
>
> > On Jul 10, 2017, at 11:04 AM, Cassandra Targett
> wrote:
> >
> > We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
> > maybe you could help with that?
>
> I created 7.x & 7.0 ref guide jobs
> On Jul 10, 2017, at 11:04 AM, Cassandra Targett wrote:
>
> We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
> maybe you could help with that?
I created 7.x & 7.0 ref guide jobs by cloning the master job.
> On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler wrote:
>>
>> I en
7.0.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Tuesday, July 4, 2017 12:32 AM
>
uesday, July 4, 2017 12:32 AM
To: dev@lucene.apache.org
Subject: Re: 7.0 Release Update
I can do both, if Steve is not faster than I am.
Uwe
Am 4. Juli 2017 00:10:16 MESZ schrieb Anshum Gupta mailto:ans...@anshumgupta.net> >:
Thanks Uwe!
Can you clarify if Jenkins = Policeman / Ap
Anshum:
I'm unclear about whether we should set a 6.7 label (no release
planned at this point, although one wouldn't surprise me). Is there
any use in setting one just to have a marker in place?
Thanks,
Erick
On Mon, Jul 3, 2017 at 3:32 PM, Uwe Schindler wrote:
> I can do both, if Steve is not
I can do both, if Steve is not faster than I am.
Uwe
Am 4. Juli 2017 00:10:16 MESZ schrieb Anshum Gupta :
>Thanks Uwe!
>
>Can you clarify if Jenkins = Policeman / Apache or both ?
>
>On Mon, Jul 3, 2017 at 3:03 PM Uwe Schindler wrote:
>
>> Thanks Anshum,
>>
>> I will setup the Jenkins jobs tomor
Thanks Uwe!
Can you clarify if Jenkins = Policeman / Apache or both ?
On Mon, Jul 3, 2017 at 3:03 PM Uwe Schindler wrote:
> Thanks Anshum,
>
> I will setup the Jenkins jobs tomorrow!
>
> Uwe
>
>
> Am 3. Juli 2017 21:22:46 MESZ schrieb Anshum Gupta :
>>
>> The following branches have been create
Thanks Anshum,
I will setup the Jenkins jobs tomorrow!
Uwe
Am 3. Juli 2017 21:22:46 MESZ schrieb Anshum Gupta :
>The following branches have been created off master, prior to bumping
>up of the version:
>* branch_7x
>* branch_7_0
>
>The versioon on master has been bumped to 8, and all tests pass
The following branches have been created off master, prior to bumping up of the
version:
* branch_7x
* branch_7_0
The versioon on master has been bumped to 8, and all tests pass.
Thanks to everyone (specially Adrien, and Uwe) :) for helping out with the
back-compat stuff and being patient.
-An
44 matches
Mail list logo