On Fri, Oct 9, 2020 at 2:49 AM Neal Richardson
<[email protected]> wrote:
>
> Hi folks,
> We're almost there.
> https://cwiki.apache.org/confluence/display/ARROW/Arrow+2.0.0+Release shows
> 11 open and 17 in progress issues for 2.0. No blockers, but there are still
> two nightly build failures ticketed (ARROW-10175 (pyarrow/hdfs),
> ARROW-10177 (gandiva xenial)) and perhaps others showing up in the most
> recent nightly build report.
>
> I suspect we will need most of tomorrow to resolve many of those issues.
> Given that, I doubt we'll have a first release candidate built and up for a
> vote tomorrow, but I'm hopeful that we'll be release-ready by the end of
> the day.
>
> Thoughts, everyone? Krisztián (who has bravely agreed to be the release
> manager again): what do you think?
I agree. It's likely that we're going to need this day to resolve the
remaining issues.
I'm ready to cut the release on the weekend as well.
>
> Neal
>
> On Wed, Oct 7, 2020 at 4:15 PM Krisztián Szűcs <[email protected]>
> wrote:
>
> > There is still some work left to make the packaging builds pass on the
> > PR. Considering how close we are to the release I find it risky to
> > include that change to 2.0. So I'm in favor of postponing it to 3.0.
> >
> >
> > On Wed, Oct 7, 2020 at 11:10 PM Micah Kornfield <[email protected]>
> > wrote:
> > >
> > > I agree with Antoine that we shouldn't be making changes to dependency
> > > versions so close to a release. This is consistent with other types of
> > > changes that could have a potentially large blast radius
> > >
> > > I don't have a strong opinion on what version we end up with though
> > (would
> > > need to do more research on compatibility guarantees)
> > >
> > > Micah
> > >
> > > On Wednesday, October 7, 2020, Neal Richardson <
> > [email protected]>
> > > wrote:
> > >
> > > > On Wed, Oct 7, 2020 at 1:11 PM Antoine Pitrou <[email protected]>
> > wrote:
> > > >
> > > > >
> > > > > Le 07/10/2020 à 21:55, Neal Richardson a écrit :
> > > > > > * The only version that is a requirement is
> > > > > >
> > > > >
> > > >
> > https://github.com/apache/arrow/pull/8325/files#diff-2420b0c5b6bdad921f1d538f92d64b59R2516
> > > > > ,
> > > > > > and so that's the one we're concerned about increasing. If we can
> > keep
> > > > it
> > > > > > low with an #ifdef, great. That said, I have no idea how slow
> > people
> > > > are
> > > > > to
> > > > > > update gRPC, or even what constitutes "old", so I can't say how
> > much
> > > > > extra
> > > > > > complication it is worth to support old versions.
> > > > >
> > > > > Well, the gRPC version provided by Ubuntu 20.04 is 1.16.1.
> > > > >
> > > >
> > > > According to
> > > >
> > > >
> > https://github.com/apache/arrow/blob/master/cpp/cmake_modules/ThirdpartyToolchain.cmake#L2509
> > > > ,
> > > > we already require 1.17, which is newer than that. And we've required
> > that
> > > > for the last year:
> > > >
> > > >
> > https://github.com/apache/arrow/commit/a70cf783364b140cab172e1851b563295c46e333
> > > >
> > > >
> > > > >
> > > > > > * However, provided that the bundled build_grpc cmake macro works
> > > > (surely
> > > > > > we test that somewhere right?), if someone has
> > > > > ARROW_DEPENDENCY_SOURCE=AUTO
> > > > > > *and* they have old gRPC on their system, instead of a build
> > failure
> > > > > > they'll just get a slower build with the bundled grpc included.
> > That's
> > > > > not
> > > > > > a bad experience, and if the user doesn't like it, presumably they
> > can
> > > > > > upgrade system gRPC and rebuild.
> > > > >
> > > > > How do you upgrade system gRPC without potentially breaking other
> > > > > packages that rely on it? If it's a system library, it's generally
> > > > > recommended to follow system-dictated lifecycles.
> > > > >
> > > > > I am not saying that we should ensure compatibility with antiquated
> > > > > versions of gRPC, but being incompatible with the version provided by
> > > > > Ubuntu 20.04 (a 6-month old distribution) may be exaggerated.
> > > > >
> > > > > Regards
> > > > >
> > > > > Antoine.
> > > > >
> > > >
> >
