Hi Mark, Thanks a lot for your write-up! I understand and share your concerns: - The infrastructure around `scikit-image` _is_ quite complex, and there is a lot of room for improvement. I don't know if anyone from the core team has a written scheme of the infra, but it would help a lot in order to understand and rework the sub-optimal and, possibly, redundant parts. Currently, even besides the bullets from the release instructions, many thing are done manually (consider, for example, the amazing and enormous work done by Matthew Brett). If you're willing to step into improving the situation, I'd gladly support you; - For the release cycle, I'd, however, agree with you only partially. From my standpoint, having weekly/bi-weekly/montly releases (a) is too expensive in terms of workforce, (b) discounts the release value and significantly reduces their noticeability, and (c) doesn't really make a lot of sense. In my experience, every 4 weeks only a very little number of significant PRs are developed and merged. Having said that, I believe, a reasonable cycle would be something like 1 release / 2-3 months. Once we see a progression in the contribution activity, we can consider discussing further changes in the schedule. Thanks again for raising the issue, and keep up the great rhythm! :) Regards, Egor On Mon, 10 Sep 2018 at 10:04, François Boulogne <fboulogne@sciunto.org> wrote:

Hi Mark,

It's great that you point this out and you take the time to do it.

...

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.

When such a situation happens to me, I tend to combine virtualenv and pip install from git (pip install git+https://...). My comment is not here to ignore the issue you raise, just to point out a possible workaround. ;)

Best,

-- François Boulogne. http://www.sciunto.org GPG: 32D5F22F

_______________________________________________ scikit-image mailing list scikit-image@python.org https://mail.python.org/mailman/listinfo/scikit-image