scikit-image

Download

scikit-image@python.org

September 2018

8 participants
12 discussions

A request for more frequent releases
by Mark Harfouche 09 Sep '18

09 Sep '18

Hi All, I would like to request that scikit-image work toward a much more frequent release cycle. Let me give some anecdotal reasons why this might be a good idea. As a new contributor, scikit-image has given me a few things: 1. It has taught me a lot about some best practices with respect to software development. 2. It has given me "free" reviews of software and features I would like to implement with respect to image processing. 3. It has taught me a lot about releasing software in a systematic manner. 4. Once code that I depend on is included in scikit-image, it likely gets tests and maintained much better than code I would write on my own. Lately, two good examples have been Python 3.7 and numpy 1.15 compatibility. Of course, now that I know a little more about collaborative software development, I try to give back. Unfortunately, as you all know, contributing doesn't come for free. With the long time lag between releases, writing code or bug fixes for scikit-image means that I have to replicate them for my own projects. My current workaround has converged to having a subdirectory `upstream/skimage` where I hold a few bug fixes that I have come to rely on from the `master` branch of `scikit-image`. Not only is that costly, but refactoring my code after scikit-image will get a release will also be costly. As such, I now have a disincentive to submit patches, bug reports, speedups to scikit-image. Having my own `upstream/skimage` directory means that I will likely diverge from scikit-image's best practices when I implement my own functions. This is going to make it harder and harder to find time to contribute back to scikit-image as the complexity of my projects grows. Not contributing to scikit-image will come at some cost to me, but I would like to emphasize that I am likely not the only one that is probably facing these dilemmas. This means that whatever code I or others like me develop, be it for speeding up warping, or image registration on cuda (to name two features I am working on), will likely not make it to scikit-image if the cost of contributing stays high. Currently, asking for a 2-week release cycle is guaranteed to be rejected. The Release guidelines are 125 lines long (if we ignore the Debian and conda-forge instructions). https://github.com/scikit-image/scikit-image/blob/master/RELEASE.txt - Many files need to be renamed. This can be done on an automated script. - Docs need to be rebuilt and uploaded. We can work to do this with travis deploy, or readthedocs - Release notes need to be manually scanned. We can ask for this to be done in each PR. - Updating __version__ is a pain. I really suggest we work toward using versioneer and tags instead of branches for releases. - Building wheels is done in separate repo. I really suggest we merge scikit-image-wheels into scikit-image itself and build wheels on every PR. - conda-forge now has automated scripts that will bump the version number. This should be moved out as these instructions are stale and available on the feedstock itself. - Debian can release however often they like. Asking for release notes to be updated in PRs will cause conflicts in PRs. I think this is a feature, not a bug. Many times tests are failing because of typos in small changes in the code. Asking for an updated rebase will help us ensure real time code correctness. I am more than glad to help work on any of the points I mentioned above and any others you find necessary. I know this will take work, but I think having much more frequent releases, timed releases, will help ensure that people can rely on their contributions making it to PyPi or conda-forge so that they can ask others to rely on them. Thank you very much for considering this, Mark

1 0

Re: [scikit-image] Error during env setup
by Juan Nunez-Iglesias 03 Sep '18

03 Sep '18

On Thu, Aug 30, 2018, at 6:43 AM, Mark Harfouche wrote: > We should definitely document that! Or fix: I'm pretty sure this didn't use to be the case a long time ago. There must be a way to ensure `pip install` rebuilds if and only if it is needed, make-like.

1 0