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
>
>
>
>
