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