This has gotten fairly delayed. 0.9 seems to be a moving target at this point. I believe there's at least one issue related to Unordered Output which needs to be resolved. I think we should get that in, and then create an RC with whatever has gone in by 06/30. The blocker jira does not list anything at the moment.
On Sun, Jun 4, 2017 at 6:47 PM, Siddharth Seth <[email protected]> wrote: > Jon, Thanks for getting back. > > For the three jiras mentioned. > TEZ-3617. Wonder if there is a way to do this without having to change the > dependency to 2.7.2? > 3605. Will try reviewing the patch this week, unless someone else gets to > it first. > TEZ-3274. I tend to agree that this would be better suited to go in early > in a release cycle. Shouldn't block a 0.9 release anyway. > > On Fri, Jun 2, 2017 at 1:07 PM, Jonathan Eagles <[email protected]> wrote: > >> Hey Sid, thanks for a callout of jiras for 0.9 release. There are a couple >> of jiras I felt are worthy of considering. None are blocking in that >> sense, >> but all are in patch available. As always, I can wait another release >> cycle >> if the community is eager for a release sooner rather than later. >> >> https://issues.apache.org/jira/browse/TEZ-3617 >> - This jira itself is relating only to a test failure on certain >> architectures. The reason I call this one out is that is bumps the YARN >> dependency from 2.7.0 to 2.7.2. A first 0.9 release gives expectations of >> minimum requirements. Again we can live with this one for a while, but now >> might be a chance to put this in. >> https://issues.apache.org/jira/browse/TEZ-3605 >> - This jira is a follow on to the Tez Shuffle Handler. This avoids the >> fetching of empty partitions while doing composite fetch. This gives the >> fetcher better decision making in the empty fetch case and avoids flooding >> the log file with warnings as well as some performance benefits. >> https://issues.apache.org/jira/browse/TEZ-3274 >> - This jira provides considerable utilization reduction for certain >> category of jobs. The change in the root input vertex manager behavior may >> be better suited earlier rather than later in a release cycle. >> >> Regards, >> jeagles >> > >
