osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making a bugfix 0.11.1 release


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 <wesmckinn@xxxxxxxxx> 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 <wesmckinn@xxxxxxxxx> 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