Seems like perhaps we should create a Dockerized environment for testing the wheels. I opened
https://issues.apache.org/jira/browse/ARROW-3546 On Wed, Oct 17, 2018 at 2:38 PM Wes McKinney <wesmck...@gmail.com> wrote: > > 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
