Being as close as we are to our code freeze/test week, I'd say that big, complex or otherwise risky changes probably won't collect too many +1 reviews at this point. If the OLTP improvement is small/concise (low risk), it could be considered for inclusion in 3.2.4.
On Wed, Jan 25, 2017 at 5:00 PM, Paul A. Jackson <[email protected]> wrote: > I have something that fixes OLTP. I haven't worked with OLAP and it looks > like the changes for this will be extensive, touching IteratorUtils and so > on. > > Would you be interested in a PR for just the OLTP part? > > > -----Original Message----- > From: Stephen Mallette [mailto:[email protected]] > Sent: Wednesday, January 25, 2017 3:58 PM > To: [email protected] > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6 > > in his case, it should go to tp32. > > On Wed, Jan 25, 2017 at 3:56 PM, Paul A. Jackson <[email protected]> > wrote: > > > For what branch should a pull request be submitted? > > > > > > -----Original Message----- > > From: Stephen Mallette [mailto:[email protected]] > > Sent: Wednesday, January 25, 2017 3:41 PM > > To: [email protected] > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6 > > > > I went with the most obvious implementation place for CloseableIterator. > > If you see other spots where you could make an argument that it would > > make sense to add it then feel free to offer a pull request and we can > > get it reviewed. I didn't look into your VertexStep suggestion too > > deeply, but a quick review seems to have me thinking that it would make > sense to do that. > > Basically anywhere that a step interacts with the structure API seems > > like it would be a candidate for CloseableIterator to be implemented > > as it is in GraphStep. > > > > On Wed, Jan 25, 2017 at 3:30 PM, Paul A. Jackson <[email protected]> > > wrote: > > > > > So, I modified my code to work with CloseableIterator. I was hoping > > > this would be honored in more places than it is. > > > > > > Where it does work is if the user of a traversal calls > > > traversal.close() all the steps will get closed, including the > > > typically > > first GraphStep. > > > GraphStep in turn checks whether the iterator that was provided by > > > iteratorSupplier implements CloseableIterator and if so, closes it, > > > and this is good. > > > > > > What I was hoping, in addition, though, was when > > > VertexStep.flatMap() (or anything else) calls Vertex.vertices() or > > > Vertex.edges() that before it finishes with the iterator it also > > > make the same check for CloseableIterator and call close(). > > > > > > Thoughts? > > > > > > -Paul > > > > > > -----Original Message----- > > > From: Paul A. Jackson [mailto:[email protected]] > > > Sent: Tuesday, January 24, 2017 3:01 PM > > > To: [email protected] > > > Subject: RE: [DISCUSS] Release 3.2.4 and 3.1.6 > > > > > > Great. I'll try it out. > > > > > > -Paul > > > > > > > > > -----Original Message----- > > > From: Stephen Mallette [mailto:[email protected]] > > > Sent: Tuesday, January 24, 2017 2:54 PM > > > To: [email protected] > > > Subject: Re: [DISCUSS] Release 3.2.4 and 3.1.6 > > > > > > no - it's in 3.2.4 and merged forward to 3.3.0: > > > > > > https://github.com/apache/tinkerpop/blob/e3889bf2401b42c3afbc85eabc2 > > > fb c ebf2588974/gremlin-core/src/main/java/org/apache/ > > > tinkerpop/gremlin/structure/util/CloseableIterator.java > > > > > > On Tue, Jan 24, 2017 at 2:52 PM, Paul A. Jackson > > > <[email protected]> > > > wrote: > > > > > > > Is CloseableIterator only in the 3.3 branch? > > > > > > > > -Paul > > > > > > > > > > > > -----Original Message----- > > > > From: Stephen Mallette [mailto:[email protected]] > > > > Sent: Monday, January 23, 2017 9:58 AM > > > > To: [email protected] > > > > Subject: [DISCUSS] Release 3.2.4 and 3.1.6 > > > > > > > > It's been a while since we've had a release (October 2016) and > > > > given the importance of the recent critical security fix from > > > > Groovy 2.4.8 I think it's worth getting some new versions out > > > > there. I'm not sure what everyone is working on or has concerns > > > > about, but after the PRs that are out there for tp32 get merged > > > > (especially https://github.com/apache/ > > > > tinkerpop/pull/541) > > > > I don't really have anything else critical for those versions. > > > > Please call out any issues that might be important for this > > > > release on this > > > thread. > > > > > > > > I don't think we should worry about doing a milestone release of > > > > 3.3.0 > > > yet. > > > > I'd like to see some more change go into that branch before we do > > > > that, but if others feel differently and would like to offer an > > > > argument I'd be open to the idea. > > > > > > > > I propose we focus on a release of 3.1.6 and 3.2.4 in two weeks > > > > time with the code freeze going into place at end of day friday of > > > > this week (January 27, 2017). If there are no objections in the > > > > next three days (Thursday, January 26, 2017, 10:00am), let's > > > > assume lazy consensus and move forward with that plan. > > > > > > > > Assuming we do move forward with a release, are there any > > > > volunteers for release manager? > > > > > > > > ________________________________ > > > > > > > > > > > > > > ________________________________ > > > > > > > > > ________________________________ > > > > > > > > > > ________________________________ > > > > > > ________________________________ > >
