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 <andrzej.biale...@lucidworks.com> > 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 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 reported after core > reloads. > > We could postpone this fix to 7.0.1 if there are objections, but I think it > should go in to 7.0 - without the fix JMX reporting is surely broken, with > the fix it’s only a possibility ;) > > >> On 11 Aug 2017, at 19:59, Anshum Gupta <ans...@anshumgupta.net >> <mailto:ans...@anshumgupta.net>> wrote: >> >> 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 <markrmil...@gmail.com >> <mailto:markrmil...@gmail.com>> 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.com/20170811 >> <http://apache-solr-7-0.bitballoon.com/20170811> >> >> - Mark >> >> On Thu, Aug 10, 2017 at 4:02 PM Tomas Fernandez Lobbe <tflo...@apple.com >> <mailto:tflo...@apple.com>> wrote: >> 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 <ans...@anshumgupta.net >>> <mailto:ans...@anshumgupta.net>> 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, Aug 10, 2017 at 12:28 PM Andrzej Białecki >>> <andrzej.biale...@lucidworks.com <mailto:andrzej.biale...@lucidworks.com>> >>> wrote: >>> 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 <markrmil...@gmail.com >>>> <mailto:markrmil...@gmail.com>> wrote: >>>> >>>> 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 <ans...@anshumgupta.net >>>> <mailto:ans...@anshumgupta.net>> 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 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 <sar...@gmail.com >>>> <mailto:sar...@gmail.com>> wrote: >>>> 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’m willing >>>> to discuss on the issues. >>>> >>>> I plan on starting to work on the remaining 7.0 blockers now. I would >>>> welcome assistance in clearing them up. >>>> >>>> Here’s a JIRA query to see just the remaining 7.0 blockers, of which there >>>> are currently 12: >>>> >>>> <https://issues.apache.org/jira/issues/?jql=project+in+(SOLR,LUCENE)+AND+fixVersion=7.0+AND+priority=Blocker+AND+resolution=Unresolved >>>> >>>> <https://issues.apache.org/jira/issues/?jql=project+in+(SOLR,LUCENE)+AND+fixVersion=7.0+AND+priority=Blocker+AND+resolution=Unresolved>> >>>> >>>> -- >>>> Steve >>>> www.lucidworks.com <http://www.lucidworks.com/> >>>> >>>> > On Jul 25, 2017, at 2:41 PM, Anshum Gupta <ans...@anshumgupta.net >>>> > <mailto:ans...@anshumgupta.net>> wrote: >>>> > >>>> > 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 >>>> > <casstarg...@gmail.com <mailto:casstarg...@gmail.com>> wrote: >>>> > 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 be a good time to look over any other bugs with >>>> > PointFields and make a case if any should be considered blockers for >>>> > 7.0. I think they all share a label: >>>> > https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points >>>> > >>>> > <https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points> >>>> > >>>> > On Tue, Jul 11, 2017 at 4:59 PM, Chris Hostetter >>>> > <hossman_luc...@fucit.org <mailto:hossman_luc...@fucit.org>> wrote: >>>> > > >>>> > > : 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 fix bugs that are going to be really painful for users. And >>>> > > : to get all that done soon, we definitely need some more volunteers. >>>> > > >>>> > > I've beefed up the description of SOLR-10807 with tips on how people >>>> > > can >>>> > > help out... >>>> > > >>>> > > https://issues.apache.org/jira/browse/SOLR-10807 >>>> > > <https://issues.apache.org/jira/browse/SOLR-10807> >>>> > > >>>> > > >>>> > > >>>> > > -Hoss >>>> > > http://www.lucidworks.com/ <http://www.lucidworks.com/> >>>> > > >>>> > > --------------------------------------------------------------------- >>>> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> > > <mailto:dev-unsubscr...@lucene.apache.org> >>>> > > For additional commands, e-mail: dev-h...@lucene.apache.org >>>> > > <mailto:dev-h...@lucene.apache.org> >>>> > > >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> > <mailto:dev-unsubscr...@lucene.apache.org> >>>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>>> > <mailto:dev-h...@lucene.apache.org> >>>> > >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> <mailto:dev-unsubscr...@lucene.apache.org> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> <mailto:dev-h...@lucene.apache.org> >>>> >>>> -- >>>> - Mark >>>> about.me/markrmiller <http://about.me/markrmiller> >> >> -- >> - Mark >> about.me/markrmiller <http://about.me/markrmiller>
