Thinking about 0.16.1 patch release

[Wes McKinney <we...@gmail.com>]

It seems inevitable that a few annoying regressions will pop up as
0.16.0 becomes more widely deployed, e.g. ARROW-7841 was just reported
and patched. I created a 0.16.1 Fix Version in JIRA so that we can tag
issues that we may want to cherry pick into a maint-0.16.x branch. We
probably would want to wait a couple of weeks before cutting the patch
release, though.

Also, as a matter of easing release management for patch releases, I
wonder if it makes sense to focus RC verification efforts on the
binary artifacts (especially the Python wheels). Should we write down
a "reduced" set of tasks for release managers to track for patch
releases?

Thanks,
Wes

Re: Thinking about 0.16.1 patch release

[Neal Richardson <ne...@gmail.com>]

IIUC the difference in the verification script is that we construct the
wheel file name, download it, and install the file, rather than have pip
query a repo and download the latest:
https://github.com/apache/arrow/blob/master/dev/release/verify-release-candidate-wheels.bat#L69-L72

Verification failed first with a 404 on the wget, and then when the file
path was fixed to reflect the actual file name (the first time around, with
an extra m), python said that there was no package matching the ABI. If we
were testing pip installing from a repository, this would have failed as
soon as we started building wheels for py38.

Neal

On Fri, Feb 14, 2020 at 11:22 AM Krisztián Szűcs <sz...@gmail.com>
wrote:

> Actually we are verifying the wheels after building them, the manylinux
> wheels in fresh environments using docker.
> We should first investigate why didn't the windows wheel issue surface
> during its verification [1].
>
> [1]:
> https://github.com/apache/arrow/blob/master/dev/tasks/python-wheels/win-build.bat#L102
>
> On Fri, Feb 14, 2020 at 5:16 PM Neal Richardson
> <ne...@gmail.com> wrote:
> >
> > In terms of wheel verification, I added
> > https://issues.apache.org/jira/browse/ARROW-7853 to the 0.16.1 tag. It's
> > for CI using pip to install the wheels we build nightly. Obviously this
> is
> > not required for 0.16.1 but it would make the release verification
> simpler
> > because we would be running that logic every day and wouldn't have to
> wait
> > until release time to find issues.
> >
> > Neal
> >
> > On Fri, Feb 14, 2020 at 7:49 AM Wes McKinney <we...@gmail.com>
> wrote:
> >
> > > It seems inevitable that a few annoying regressions will pop up as
> > > 0.16.0 becomes more widely deployed, e.g. ARROW-7841 was just reported
> > > and patched. I created a 0.16.1 Fix Version in JIRA so that we can tag
> > > issues that we may want to cherry pick into a maint-0.16.x branch. We
> > > probably would want to wait a couple of weeks before cutting the patch
> > > release, though.
> > >
> > > Also, as a matter of easing release management for patch releases, I
> > > wonder if it makes sense to focus RC verification efforts on the
> > > binary artifacts (especially the Python wheels). Should we write down
> > > a "reduced" set of tasks for release managers to track for patch
> > > releases?
> > >
> > > Thanks,
> > > Wes
> > >
>

Re: Thinking about 0.16.1 patch release

[Krisztián Szűcs <sz...@gmail.com>]

Actually we are verifying the wheels after building them, the manylinux
wheels in fresh environments using docker.
We should first investigate why didn't the windows wheel issue surface
during its verification [1].

[1]: https://github.com/apache/arrow/blob/master/dev/tasks/python-wheels/win-build.bat#L102

On Fri, Feb 14, 2020 at 5:16 PM Neal Richardson
<ne...@gmail.com> wrote:
>
> In terms of wheel verification, I added
> https://issues.apache.org/jira/browse/ARROW-7853 to the 0.16.1 tag. It's
> for CI using pip to install the wheels we build nightly. Obviously this is
> not required for 0.16.1 but it would make the release verification simpler
> because we would be running that logic every day and wouldn't have to wait
> until release time to find issues.
>
> Neal
>
> On Fri, Feb 14, 2020 at 7:49 AM Wes McKinney <we...@gmail.com> wrote:
>
> > It seems inevitable that a few annoying regressions will pop up as
> > 0.16.0 becomes more widely deployed, e.g. ARROW-7841 was just reported
> > and patched. I created a 0.16.1 Fix Version in JIRA so that we can tag
> > issues that we may want to cherry pick into a maint-0.16.x branch. We
> > probably would want to wait a couple of weeks before cutting the patch
> > release, though.
> >
> > Also, as a matter of easing release management for patch releases, I
> > wonder if it makes sense to focus RC verification efforts on the
> > binary artifacts (especially the Python wheels). Should we write down
> > a "reduced" set of tasks for release managers to track for patch
> > releases?
> >
> > Thanks,
> > Wes
> >

Re: Thinking about 0.16.1 patch release

[Neal Richardson <ne...@gmail.com>]

In terms of wheel verification, I added
https://issues.apache.org/jira/browse/ARROW-7853 to the 0.16.1 tag. It's
for CI using pip to install the wheels we build nightly. Obviously this is
not required for 0.16.1 but it would make the release verification simpler
because we would be running that logic every day and wouldn't have to wait
until release time to find issues.

Neal

On Fri, Feb 14, 2020 at 7:49 AM Wes McKinney <we...@gmail.com> wrote:

> It seems inevitable that a few annoying regressions will pop up as
> 0.16.0 becomes more widely deployed, e.g. ARROW-7841 was just reported
> and patched. I created a 0.16.1 Fix Version in JIRA so that we can tag
> issues that we may want to cherry pick into a maint-0.16.x branch. We
> probably would want to wait a couple of weeks before cutting the patch
> release, though.
>
> Also, as a matter of easing release management for patch releases, I
> wonder if it makes sense to focus RC verification efforts on the
> binary artifacts (especially the Python wheels). Should we write down
> a "reduced" set of tasks for release managers to track for patch
> releases?
>
> Thanks,
> Wes
>