Hey Anshum, I’d like to get LUCENE-7737 and LUCENE-7723 in before 7 goes out, do you want me to hold off committing until you’ve got the branches cut?
Alan Woodward www.flax.co.uk > On 25 Jun 2017, at 18:51, Anshum Gupta <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> 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 > <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 > <https://issues.apache.org/jira/browse/SOLR-10951> > > > I’d prefer to fix https://issues.apache.org/jira/browse/SOLR-10951 > <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 <http://www.thetaphi.de/> > eMail: [email protected] <mailto:[email protected]> > > > From: Anshum Gupta [mailto:[email protected] > <mailto:[email protected]>] > Sent: Saturday, June 24, 2017 10:52 PM > > > To: [email protected] <mailto:[email protected]> > 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > > I’d like to get https://issues.apache.org/jira/browse/LUCENE-7877 > > <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 <http://www.flax.co.uk/> > > > > > > On 19 Jun 2017, at 15:45, Anshum Gupta <[email protected] > > <mailto:[email protected]>> 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 > > > > <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 > > > > <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-6630> > > https://issues.apache.org/jira/browse/SOLR-10887 > > <https://issues.apache.org/jira/browse/SOLR-10887> > > https://issues.apache.org/jira/browse/SOLR-10803 > > <https://issues.apache.org/jira/browse/SOLR-10803> > > https://issues.apache.org/jira/browse/SOLR-10756 > > <https://issues.apache.org/jira/browse/SOLR-10756> > > https://issues.apache.org/jira/browse/SOLR-10710 > > <https://issues.apache.org/jira/browse/SOLR-10710> > > https://issues.apache.org/jira/browse/SOLR-9321 > > <https://issues.apache.org/jira/browse/SOLR-9321> > > https://issues.apache.org/jira/browse/SOLR-8256 > > <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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > >> <mailto:[email protected]>> 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 > >>> <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 > >>> <[email protected] <mailto:[email protected]>> 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 <[email protected] > >>>> <mailto:[email protected]>> wrote: > >>>>> > >>>>> > >>>>> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey <[email protected] > >>>>> > <mailto:[email protected]>> 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 <http://www.lucidworks.com/> > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> <mailto:[email protected]> > >>>>> For additional commands, e-mail: [email protected] > >>>>> <mailto:[email protected]> > >>>>> > >>>> > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > >
