lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anshum Gupta <ans...@anshumgupta.net>
Subject Re: Release planning for 7.0
Date Tue, 27 Jun 2017 06:30:18 GMT
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 <anshum@anshumgupta.net>
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 <erik.hatcher@gmail.com>
> 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 <anshum@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 <dpgove@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 <dpgove@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 <
>>>> ichattopadhyaya@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 <sarowe@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey <apache@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Mime
View raw message