Erick, sure. If you think it'd take longer, could you mark that as a blocker so I hold back moving ahead with the release process?
-Anshum On Mon, Jun 26, 2017 at 11:28 PM Anshum Gupta <[email protected]> wrote: > Hi Alan, > > Sorry for the delay in replying but go ahead and commit this. I'm still > trying to work through the 8.0 version bump test failures. If you don't > make it by the time I push the branches, kindly commit to all the branches, > else I'll make sure that your commit makes it to all of those. > > -Anshum > > On Mon, Jun 26, 2017 at 3:21 AM Erik Hatcher <[email protected]> > wrote: > >> I will get https://issues.apache.org/jira/browse/SOLR-10874 into 7.0 and >> branch 6x in the next few days - I’ll merge to whatever branches are needed >> at the time. >> >> Erik >> >> On Jun 19, 2017, at 10:45 AM, Anshum Gupta <[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 >> >> 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 <[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]> 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 < >>>> [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]> wrote: >>>>> >>>>>> >>>>>> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey <[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 >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>> >>> >>
