wiredfool commented 8 years ago

Sigh. I don't think we're at a stable 3.0, let alone a 3.1.

aclark4life commented 8 years ago

@wiredfool Huh? What's wrong? You can always punt and release 3.0.1 on Jan 1 and 3.1.0 in 3 months (thanks for opening a ticket, @radarhere; just popped in to check on this)

wiredfool commented 8 years ago

The IFD/Exif stuff mostly. The 0/0 issue is still hanging around due to lack of time and feedback, and I thought that there were still some other related bits outstanding.

aclark4life commented 8 years ago

Who's doing this release: @wiredfool, @aclark4life or any new volunteers?

hugovk commented 8 years ago

It wouldn't be wise for me to attempt to make a first release on 1st January :) Also not sure I have all the relevant permissions.

wiredfool commented 8 years ago

@hugovk Planning for a Finnish hangover?

I can run the release but I probably won't have time to whip a bunch of PRs into shape. If we've got potentially destabilizing changes, I'd like to merge them post 3.1 and give them some time to mellow in master before a release.

hugovk commented 8 years ago

Yep :)

techtonik commented 8 years ago

1293 is a regression that is not fixed yet.

wiredfool commented 8 years ago

Tests are passing on raspian, which hasn't been tested in 6 months or more.

wiredfool commented 8 years ago

We're getting lingering failures on Travis (https://travis-ci.org/python-pillow/Pillow/builds/99075647) which appear to be related to #767, where somewhere we're messing up the multithreaded implementation of OpenJPEG.

I'm not calling this a blocking bug for 3 reasons:

We've lived with it for a long time
It's not a core format
I don't have time to rewrite it without threading.

I'd still really like to get this fixed, but it's a big job. (or perhaps, it's a small job for someone who can find the one little thing that's wrong with the threading.)

wiredfool commented 8 years ago

I'd like to do an RC on 12/30. I want to get #1531 in, and maybe #1493 and #1593, depending on getting tests put together (and understanding what is really happening in #1593). After the RC, I'd like to keep it to fixing showstoppers and documentation.

I don't see anything else on the horizon that's likely to make it into the final. Speak up if you feel otherwise. @hugovk @radarhere @aclark4life

aclark4life commented 8 years ago

@wiredfool Sounds good to me; thanks & happy holidays to the @python-pillow/pillow-team !

hugovk commented 8 years ago

:+1:

techtonik commented 8 years ago

Because of #1293 I can not save screenshots.

techtonik commented 8 years ago

Otherwise it is awesome.

wiredfool commented 8 years ago

@techtonik If you've got a pull request, I'd be happy to look at it. Windows support is always a bit behind since none of the core devs develop on it on a day to day basis, and it's the significantly different platform.

radarhere commented 8 years ago

The plan for this release sounds good. Thanks to all for their part in it!

wiredfool commented 8 years ago

I'm also thinking that a quick fix to #1597 is in order as well. Probably whitelisting tags that are handled by libtiff.

wiredfool commented 8 years ago

Any thoughts on #1477 / #1619?

wiredfool commented 8 years ago

Ok.

Quick fix for #1597 is done, it prevents segfaults, but it doesn't lead to correct images. I'd really like to get the time to fix that one properly, but no segfaults is a decent first step.
I'm going to pass on #1493 for now, I think it's better served by #1622.
1531 appears done. Needs review.
Passing on #1593 for now due to time crunch.

If someone wants to eyeball my contributions soonish, I'll cut an RC tonight.

hugovk commented 8 years ago

Thanks, #1622 and #1531 merged.

wiredfool commented 8 years ago

Upon further review of #1619, it only restores gps exif to the 2.9 format.

I'm feeling like exif handling is a blocking issue at this point.

Pre 3.0, people had a working, if notationally experimental and private interface to get exif data. With 3.0, we wound up changing it without providing a fallback v1 interface like the rest of the tiff stuff. Now we've rolled back support on gpsexif, but not the rest of it.

It's likely now that people have either patched around it or they've pinned at 2.9. If we go to 3.1 with the current interface, we're just going to solidify the condition.

I'd really like to provide a richer interface, especially for writing. But given that we don't have that now, it's not a blocking issue.

hugovk commented 8 years ago

Fine by me if you're like to postpone the release a bit.

aclark4life commented 8 years ago

I'm generally against postponing major releases, except under extreme circumstances e.g. "major public outcry". I suspect we could solidify mistakes now and fix later, and no one would notice or care; but we'd need more feedback to know for sure.

However if you're saying you don't feel comfortable releasing 3.1.0 right now, I'm open to discussing alternatives (maybe we postpone 1 month?)

wiredfool commented 8 years ago

I'm thinking a slip rather than postponement. I think I've found the commit that caused the biggest regression, and it shouldn't be a big deal to fix it up.

On the other hand, I'm trying to deal with neighbors and a backup generator for a well, from 8 timezones away. It's gone from contentious to stupid alarmingly quickly.

wiredfool commented 8 years ago

Ok, Updates to the exif support and the libtiff metadata tests are now in awaiting travis and review.

aclark4life commented 8 years ago

\o/

wiredfool commented 8 years ago

Ok, Release candidate is up. Commence smoke test.

Pinging @cgohlke

wiredfool commented 8 years ago

First upload of the .tar.gz to pypi failed with a 500, and left an incomplete file with a bad checksum. I had to upload the zip manually, and then delete the failed file and rename the .tar.gz to get a corrected upload.

I'm not impressed.

aclark4life commented 8 years ago

I wouldn't bother uploading the RC to PyPI… but that's just me.

wiredfool commented 8 years ago

If we're going to get anyone testing it on windows, it's got to go somewhere.

wiredfool commented 8 years ago

We've broken our readme on Pypi: https://pypi.python.org/pypi?name=Pillow&version=3.1.0.rc1&:action=display

Pillow
======

Python Imaging Library (Fork)
-----------------------------

Pillow is the friendly PIL fork by `Alex Clark and Contributors <https: github.com="" python-pillow="" pillow="" graphs="" contributors="">`_. PIL is the Python Imaging Library by Fredrik Lundh and Contributors.

.. image:: https://zenodo.org/badge/17549/python-pillow/Pillow.svg
:target: https://zenodo.org/badge/latestdoi/17549/python-pillow/Pillow

.. image:: https://readthedocs.org/projects/pillow/badge/?version=latest
:target: http://pillow.readthedocs.org/?badge=latest
:alt: Documentation Status

aclark4life commented 8 years ago

Sorry, fixed in 10d5c7df6d49922a3741c3709450afb0b6e64317 !

wiredfool commented 8 years ago

Thanks, that looks better.

wiredfool commented 8 years ago

I've left a message in some of the various threads about exif on github that we have an RC with changes.

Hopefully we get successful feedback from it.

wiredfool commented 8 years ago

I'm about ready to demote Jpeg2k from supported to experimental, since it's deadlocking pretty consistently on travis now. (in each of the last 3 runs on master, all of the same code, and on several different pythons)

wiredfool commented 8 years ago

And another 500 uploading the macosx binaries. I don't know if it's pypi being awkward or something I'm doing...

aclark4life commented 8 years ago

Dunno, you can try pinging @dstufft

cgohlke commented 8 years ago

I get one test error on Python 2.6 for Windows:

--------------------------------------------------------------------
PIL SETUP SUMMARY
--------------------------------------------------------------------
version      Pillow 3.1.0.rc1
platform     win32 2.6.6 (r266:84297, Aug 24 2010, 18:13:38)
             [MSC v.1500 64 bit (AMD64)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- OPENJPEG (JPEG2000) support available (2.1)
--- ZLIB (PNG/ZIP) support available
--- LIBTIFF support available
--- FREETYPE2 support available
--- LITTLECMS2 support available
--- WEBP support available
--- WEBPMUX support available
--------------------------------------------------------------------
To check the build, run the selftest.py script.

--------------------------------------------------------------------
Pillow 3.1.0.rc1 TEST SUMMARY
--------------------------------------------------------------------
Python modules loaded from D:\Build\Pillow\Pillow-git\PIL
Binary modules loaded from D:\Build\Pillow\Pillow-git\PIL
--------------------------------------------------------------------
--- PIL CORE support ok
--- TKINTER support ok
--- FREETYPE2 support ok
--- LITTLECMS2 support ok
--- WEBP support ok
--- JPEG support ok
--- OPENJPEG (JPEG2000) support ok
--- ZLIB (PNG/ZIP) support ok
--- LIBTIFF support ok
--------------------------------------------------------------------
<snip>
======================================================================
ERROR: TestImageWinPointers.test_pointer
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Build\Pillow\Pillow-git\Tests\test_imagewin_pointers.py", line 102, in test_pointer
    bitmap = serialize_dib(hdr, pixels)
  File "D:\Build\Pillow\Pillow-git\Tests\test_imagewin_pointers.py", line 75, in serialize_dib
    return bytearray(buf)
ValueError: byte must be in range(0, 256)

----------------------------------------------------------------------
Ran 687 tests in 110.609s

FAILED (SKIP=18, errors=1)

Otherwise all builds and tests pass on Windows.

wiredfool commented 8 years ago

I'm seeing an additional failure on 26x64:

======================================================================
FAIL: TestImageGetIm.test_sanity
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\erics\Documents\GitHub\Pillow\Tests\test_image_getim.py", line 13, in test_sanity
    self.assertIsInstance(im.im.id, int)
AssertionError: 8796024766016L is not an instance of <type 'int'>

wiredfool commented 8 years ago

1633 should fix those two test errors. I'm letting the tests run before merging, but it's more for not breaking other pythons as actually expecting anything useful from appveyor on this front.

wiredfool commented 8 years ago

Got one bit of LGTM feedback on the exif. If nothing more blows up, I'm planning on tagging and pushing the release In the morning.

aclark4life commented 8 years ago

Great news, thanks!

wiredfool commented 8 years ago

Ok, tagged and released 3.1.0 final.

@cgohlke Our windows docs don't mention .exes, but they do mention eggs, but I'm not sure where the windows ecosystem is wrt installers. I'm kind of willing to let Python 3.2 go, It's 5 years old with three newer more compatible successors. I'd say drop it and if there are major complaints we can revisit.

wiredfool commented 8 years ago

OSX binaries are up.

totaam commented 8 years ago

+1 for dropping Python 3.2 Many thanks for all the excellent work done on Pillow. It is absolutely essential for us.

FYI: we build Fedora and CentOS RPM for most releases. Usually first in the beta repository (as is the case just now for 3.1.0): http://xpra.org/beta/ And eventually in the "stable" repo (usually shortly after since we've not experienced regressions with Pillow. And long may it continue!): http://xpra.org/dists/ Just thought I would mention it in case it is useful for someone. The specfiles are based on the Fedora ones.

wiredfool commented 8 years ago

Thank you @cgohlke! Uploading now...

aclark4life commented 8 years ago

Thanks @wiredfool @cgohlke @python-pillow/pillow-team for 3.1.0!

python-pillow / Pillow

Release 3.1.0 on January 1, 2016 #1563

1293 is a regression that is not fixed yet.

1531 appears done. Needs review.

1633 should fix those two test errors. I'm letting the tests run before merging, but it's more for not breaking other pythons as actually expecting anything useful from appveyor on this front.