[scikit-image] A request for more frequent releases

Egor Panfilov egor.v.panfilov at gmail.com
Tue Sep 11 16:16:29 EDT 2018


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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/scikit-image
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20180911/df06b871/attachment.html>


More information about the scikit-image mailing list