Hi Anshum, I'd like to have SOLR-10282 in for 7.0. It is a low impact new feature that helps admins to enable Kerberos more easily using the bin/solr script. I should be able to have it dev-complete by end of Friday. Let me know if you have any objections. Thanks, Ishan
On Thu, Jun 29, 2017 at 1:00 AM, Anshum Gupta <ans...@anshumgupta.net> wrote: > Hi Christine, > > With my current progress, which is much slower that how I'd have liked it > to be, I think there is still a day before the branches are cut. How far > out do you think you are with this? > > -Anshum > > > On Wed, Jun 28, 2017 at 9:59 AM Uwe Schindler <u...@thetaphi.de> wrote: > >> Hi Anshum, >> >> >> >> I have a häckidihickhäck workaround for the Hadoop Solr 9 issue. It is >> already committed to master and 6.x branch, so the issue is fixed: >> https://issues.apache.org/jira/browse/SOLR-10966 >> >> >> >> I lowered the Hadoop-Update (https://issues.apache.org/ >> jira/browse/SOLR-10951) issue to “Major” level, so it is no longer >> blocker. >> >> >> >> Nevertheless, we should fix the startup scripts for Java 9 in master >> before release of Solr 7, because currently the shell scripts fail (on >> certain platforms). And Java 9 is coming soon, so we should really have >> support because the speed improvements are a main reason to move to Java 9 >> with your Solr servers. >> >> >> >> Uwe >> >> >> >> ----- >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> http://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> >> *From:* Anshum Gupta [mailto:ans...@anshumgupta.net] >> *Sent:* Sunday, June 25, 2017 7:52 PM >> >> >> *To:* dev@lucene.apache.org >> *Subject:* Re: Release planning for 7.0 >> >> >> >> Hi Uwe, >> >> >> >> +1 on getting SOLR-10951 >> <https://issues.apache.org/jira/browse/SOLR-10951> in before the release >> but I assume you weren't hinting at holding back the branch creation :). >> >> >> >> I am not well versed with that stuff so it would certainly be optimal for >> someone else to look at that. >> >> >> >> -Anshum >> >> On Sun, Jun 25, 2017 at 9:58 AM Uwe Schindler <u...@thetaphi.de> wrote: >> >> Hi, >> >> >> >> currently we have the following problem: >> >> - The first Java 9 release candidate came out. This one now uses the >> final version format. The string returned by ${java.version} is now plain >> simple “9” – bummer for one single 3rd party library! >> - This breaks one of the most basic Hadoop classes, so anything in >> Solr that refers somehow to Hadoop breaks. Of course this is HDFS - but >> also authentication! We should support Java 9, so we should really fix >> this >> ASAP! >> >> >> >> From now on all tests running with Java 9 fail on Jenkins until we fix >> the following: >> >> - Get an Update from Hadoop Guys (2.7.4), with just the stupid check >> removed (the completely useless version checking code snipped already >> makes >> its round through twitter): https://issues.apache.org/ >> jira/browse/HADOOP-14586 >> - Or we update at least master/7.0 to latest Hadoop version, which >> has the bug already fixed. Unfortunately this does not work, as there is a >> bug in the Hadoop MiniDFSCluster that hangs on test shutdown. I have no >> idea how to fix. See https://issues.apache.org/jira/browse/SOLR-10951 >> >> >> >> I’d prefer to fix https://issues.apache.org/jira/browse/SOLR-10951 for >> master before release, so I set it as blocker. I am hoping for hely by Mark >> Miller. If the hadoop people have a simple bugfix release for the earlier >> version, we may also be able to fix branch_6x and branch_6_6 (but I >> disabled them on Jenkins anyways). >> >> >> >> Uwe >> >> >> >> ----- >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> http://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> >> *From:* Anshum Gupta [mailto:ans...@anshumgupta.net] >> *Sent:* Saturday, June 24, 2017 10:52 PM >> >> >> *To:* dev@lucene.apache.org >> *Subject:* Re: Release planning for 7.0 >> >> >> >> I'll create the 7x, and 7.0 branches *tomorrow*. >> >> >> >> Ishan, do you mean you would be able to close it by Tuesday? You would >> have to commit to both 7.0, and 7.x, in addition to master, but I think >> that should be ok. >> >> >> >> We also have SOLR-10803 open at this moment and we'd need to come to a >> decision on that as well in order to move forward with 7.0. >> >> >> >> P.S: If there are any objections to this plan, kindly let me know. >> >> >> >> -Anshum >> >> >> >> On Fri, Jun 23, 2017 at 5:03 AM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >> Hi Anshum, >> >> >> >> > I will send out an email a day before cutting the branch, as well as >> once the branch is in place. >> >> I'm right now on travel, and unable to finish SOLR-10574 until Monday >> (possibly Tuesday). >> >> Regards, >> >> Ishan >> >> >> >> On Tue, Jun 20, 2017 at 5:08 PM, Anshum Gupta <ans...@anshumgupta.net> >> wrote: >> >> From my understanding, there's not really a 'plan' but some intention to >> release a 6.7 at some time if enough people need it, right? In that case I >> wouldn't hold back anything for a 6x line release and cut the 7x, and 7.0 >> branches around, but not before the coming weekend. I will send out an >> email a day before cutting the branch, as well as once the branch is in >> place. >> >> >> >> If anyone has any objections to that, do let me know. >> >> >> >> Once that happens, we'd have a feature freeze on the 7.0 branch but we >> can take our time to iron out the bugs. >> >> >> >> @Alan: Thanks for informing. I'll make sure that LUCENE-7877 is committed >> before I cut the branch. I have added the right fixVersion to the issue. >> >> >> >> -Anshum >> >> >> >> >> >> >> >> On Mon, Jun 19, 2017 at 8:33 AM Erick Erickson <erickerick...@gmail.com> >> wrote: >> >> Anshum: >> >> I'm one of the people that expect a 6.7 release, but it's more along >> the lines of setting expectations than having features I really want >> to get in to the 6x code line. We nearly always have "just a few >> things" that someone would like to put in, and/or a bug fix or two >> that surfaces. >> >> I expect people to back-port stuff they consider easy/beneficial to >> 6.x for "a while" as 7.0 solidifies, at their discretion of course. >> Think of my position as giving people a target for tidying up 6.x >> rather than a concrete plan ;). Just seems to always happen. >> >> And if there is no 6.7, that's OK too. Additions to master-2 usually >> pretty swiftly stop as the hassle of merging any change into 3 code >> lines causes people to pick what goes into master-2 more carefully ;) >> >> Erick >> >> On Mon, Jun 19, 2017 at 8:03 AM, Alan Woodward <a...@flax.co.uk> wrote: >> > I’d like to get https://issues.apache.org/jira/browse/LUCENE-7877 in >> for 7.0 >> > - should be able to commit in the next couple of days. >> > >> > Alan Woodward >> > www.flax.co.uk >> > >> > >> > On 19 Jun 2017, at 15:45, Anshum Gupta <ans...@anshumgupta.net> wrote: >> > >> > Hi everyone, >> > >> > Here's the update about 7.0 release: >> > >> > There are still unresolved blockers for 7.0. >> > Solr (12): >> > https://issues.apache.org/jira/browse/SOLR-6630?jql= >> project%20%3D%20Solr%20AND%20fixVersion%20%3D%20% >> 22master%20(7.0)%22%20and%20resolution%20%3D% >> 20Unresolved%20and%20priority%20%3D%20Blocker >> > >> > Lucene (None): >> > https://issues.apache.org/jira/issues/?jql=project%20% >> 3D%20%22Lucene%20-%20Core%22%20AND%20fixVersion%20%3D%20% >> 22master%20(7.0)%22%20AND%20resolution%20%3D% >> 20Unresolved%20AND%20priority%20%3D%20Blocker >> > >> > Here are the ones that are unassigned: >> > https://issues.apache.org/jira/browse/SOLR-6630 >> > https://issues.apache.org/jira/browse/SOLR-10887 >> > https://issues.apache.org/jira/browse/SOLR-10803 >> > https://issues.apache.org/jira/browse/SOLR-10756 >> > https://issues.apache.org/jira/browse/SOLR-10710 >> > https://issues.apache.org/jira/browse/SOLR-9321 >> > https://issues.apache.org/jira/browse/SOLR-8256 >> > >> > The ones that are already assigned, I'd request you to update the JIRA >> so we >> > can track it better. >> > >> > In addition, I am about to create another one as I wasn’t able to extend >> > SolrClient easily without a code duplication on master. >> > >> > This brings us to - 'when can we cut the branch'. I can create the >> branch >> > this week and we can continue to work on these as long as none of these >> are >> > 'new features' but I'd be happy to hear what everyone has to say. >> > >> > I know there were suggestions around a 6.7 release, does anyone who's >> > interested in leading that have a timeline or an idea around what >> features >> > did you want in that release? If yes, I’d really want to wait until at >> least >> > the branch for 6.7 is cur for the purpose of easy back-compat >> management and >> > guarantee. >> > >> > Also, sorry for being on radio silence for the last few days. I’d been >> > traveling but now I’m back :). >> > >> > -Anshum Gupta >> > >> > On Sun, Jun 18, 2017 at 8:57 AM Dennis Gove <dpg...@gmail.com> wrote: >> >> >> >> I've committed the most critical changes I wanted to make. Please don't >> >> hold up on a v7 release on my part. >> >> >> >> Thanks! >> >> >> >> Dennis >> >> >> >> On Tue, Jun 13, 2017 at 9:27 AM, Dennis Gove <dpg...@gmail.com> wrote: >> >>> >> >>> Hi, >> >>> >> >>> I also have some cleanup I'd like to do prior to a cut of 7. There are >> >>> some new stream evaluators that I'm finding don't flow with the >> general >> >>> flavor of evaluators. I'm using >> >>> https://issues.apache.org/jira/browse/SOLR-10882 for the cleanup, >> but I do >> >>> intend to be complete by June 16th. >> >>> >> >>> Thanks, >> >>> Dennis >> >>> >> >>> >> >>> On Sat, Jun 10, 2017 at 11:21 AM, Ishan Chattopadhyaya >> >>> <ichattopadhy...@gmail.com> wrote: >> >>>> >> >>>> Hi Anshum, >> >>>> I would like to request you to consider delaying the branch cutting >> by a >> >>>> bit till we finalize the SOLR-10574 discussions and make the changes. >> >>>> Alternatively, we could backport the changes to that branch after >> you cut >> >>>> the branch now. >> >>>> Regards, >> >>>> Ishan >> >>>> >> >>>> On Sat, Jun 3, 2017 at 1:02 AM, Steve Rowe <sar...@gmail.com> wrote: >> >>>>> >> >>>>> >> >>>>> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey <apa...@elyograg.org> >> wrote: >> >>>>> > >> >>>>> > On 6/2/2017 10:23 AM, Steve Rowe wrote: >> >>>>> > >> >>>>> >> I see zero benefits from cutting branch_7x now. Shawn, can you >> >>>>> >> describe why you think we should do this? >> >>>>> >> >> >>>>> >> My interpretation of your argument is that you’re in favor of >> >>>>> >> delaying cutting branch_7_0 until feature freeze - which BTW is >> the status >> >>>>> >> quo - but I don’t get why that argues for cutting branch_7x now. >> >>>>> > >> >>>>> > I think I read something in the message I replied to that wasn't >> >>>>> > actually stated. I hate it when I don't read things closely >> enough. >> >>>>> > >> >>>>> > I meant to address the idea of making both branch_7x and >> branch_7_0 >> >>>>> > at >> >>>>> > the same time, whenever the branching happens. Somehow I came up >> >>>>> > with >> >>>>> > the idea that the gist of the discussion included making the >> branches >> >>>>> > now, which I can see is not the case. >> >>>>> > >> >>>>> > My point, which I think applies equally to branch_7x, is to wait >> as >> >>>>> > long >> >>>>> > as practical before creating a branch, so that there is as little >> >>>>> > backporting as we can manage, particularly minimizing the amount >> of >> >>>>> > time >> >>>>> > that we have more than two branches being actively changed. >> >>>>> >> >>>>> +1 >> >>>>> >> >>>>> -- >> >>>>> Steve >> >>>>> www.lucidworks.com >> >>>>> >> >>>>> >> >>>>> ------------------------------------------------------------ >> --------- >> >>>>> 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 >> >> >> >>
