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 <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
<mailto: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
<mailto: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
<mailto: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
<mailto: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 <http://www.flax.co.uk>
>
>
> On 19 Jun 2017, at 15:45, Anshum Gupta <ans...@anshumgupta.net
> <mailto: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
> <mailto: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
>> <mailto: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 <mailto: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
>>>> <mailto:sar...@gmail.com> > wrote:
>>>>>
>>>>>
>>>>> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey <apa...@elyograg.org
>>>>> > <mailto: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 <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>
