hi folks, Since the Python wheels are being installed 10,000 times per day or more, I don't think we should allow them to be broken for much longer.
What additional patches need to be done before an RC can be cut? Since I'm concerned about the broken patches undermining the project's reputation, I can adjust my priorities to start a release vote later today or first thing tomorrow morning. Seems like https://issues.apache.org/jira/browse/ARROW-3535 might be the last item, and I can prepare a maintenance branch with the cherry-picked fixes Was there a determination as to why our CI systems did not catch the blocker ARROW-3514? Thanks, Wes On Tue, Oct 16, 2018 at 9:32 PM Wes McKinney <wesmck...@gmail.com> wrote: > > hi folks, > > As a result of ARROW-3514, we need to release new Python packages > quite urgently since major functionality (Parquet writing on many > Linux platforms) is broken out of the box > > https://github.com/apache/arrow/commit/66d9a30a26e1659d9e992037339515e59a6ae518 > > We have a couple options: > > * Release from master > * Release 0.11.0 + minimum patches to include the ARROW-3514 fix and > any follow up patches to fix packaging > > There is the option to "not" release but it could cause confusion for > people because PyPI does not allow replacing wheels; a new version > number has to be created. > > What would folks like to do? Who can help with the RM duties? Since a > 72 hour vote is a _should_ rather than _must_, we could reasonably > close the release vote in < 72 hours and push out packages faster if > it is scope limited to the zlib bug fix > > Thanks, > Wes
