Mailman 3 September 2018 - scikit-image

Re: [scikit-image] A request for more frequent releases
by Thomas Caswell Sept. 11, 2018

Sept. 11, 2018

Sorry for drive by comments. Matplotlib uses cloudflare as a https proxy + caching. Jouni K Seppänen sorted out how to re-direct nightly.matplotlib.org to the rackspace wheelhouse. I think monthly releases of a big project is probably too fast (and yearly to too slow). New versions also contain new bugs >:) Tom On Tue, Sep 11, 2018 at 6:08 PM Mark Harfouche <mark.harfouche(a)gmail.com> wrote: > Hi Egor, Stephan, > > 1. I definitely commend Matthew Brett on his work. My suggestion would be > move his infrastructure to run on every PR rather than getting rid of his > infrastructure. > 2. (a) Too expensive in terms of workforce: > > This is definitely true with the current infrastructure. Simplifying this > is non-trivial and would need to be a focused effort. > This discussion aims to find a path toward that goal. > I thank everybody for their input and suggestions, and most importantly, > for taking the time to respond to this email. > > (b) discounts the release value > Fast releases are probably immensely valuable to the people that raised > the underlying issues. > > Taking an example from a different library: > A one line fix in OpenCV I submitted this week makes it possible for me to > pass arrays directly to PIL > https://github.com/opencv/opencv/pull/12465 > With the current release cycle of OpenCV, it may be at least 1 month (and > up to 6!) until I see that fix propagate across different computers. > Now I either have to recompile OpenCV myself (which is difficult) or just > not use the feature I need. > scikit-image is easier to compile (or get from the wheelhouse) but those > are all still additional barriers that you have to communicate with your > collaborators. > > (c) reduces their noticeability > People tend to notice only the features they need. I my projects, I don't > always have a ">=" for all dependencies because I can often "just use any > version that comes from pypi/conda-forge/anaconda". > Sometimes even enabling the `conda-forge` channel is difficult for > beginners. > > (d) very little number of PRs per release > Once again, even a single PR can be of immense value (eg. float32s passing > through unchanged in `img_as_float`-- I wouldn't know how to change that > functionality via monkey patching :/ ) > > Stephan, > > Daily wheel builds are fine, unfortunately, I have a dependency in my > pipeline on opencv, and as such I am stuck on conda. > I think you were working on getting a shorter url for the wheel house, I > think that is great! > > Regarding experimenting. I think this definitely needs to be included in > the discussion. Thanks for bringing it up. > > I think I'll try to summarize your other points in focused issues on > github as Juan suggested. > > Mark > > On Tue, Sep 11, 2018 at 4:47 PM Stefan van der Walt <stefanv(a)berkeley.edu> > wrote: > >> On Tue, 11 Sep 2018 23:16:29 +0300, Egor Panfilov wrote: >> > - 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. >> >> In an ideal world, we would be ready to punch out a release at a day's >> notice, but would probably only release every three months or so. A >> release is not merely a tagging of the current master, but also a >> statement about the readiness of the code it contains. E.g., we are >> more lenient about merging experimental features early on in the release >> cycle, and sometimes modify or even remove APIs that we feel are not >> mature enough. >> >> Mark, I wonder if some of your issues can be addressed by daily wheel >> builds (which we already have)? Then you can point pip to our Rackspace >> wheels container, and install from there. >> >> The 32-bit issues mentioned were long known, because Matthew builds for >> that platform daily, and reported the failures a long time ago. It has >> not been fixed because no one has taken the time to investigate >> thoroughly (perhaps not that many developers care about 64-bit?). >> >> I fully support attempts to reduce the burden of turning `master` into a >> release. >> >> One such a proposed change was versioneer, but I recall from Mark's >> previous PR (https://github.com/scikit-image/scikit-image/issues/3144) >> that it introduced quite a bit of complexity for little gain. I'm not >> sure why the current versioning is considered troublesome; it is stored >> in `skimage/__init__.py`, and is reused everywhere else. >> >> W.r.t. listing new features for a release, Nathaniel's suggestion of >> Towncrier looks sensible, and helps to avoid conflicts. On the other >> hand, the more tools we use, the higher the overhead to contributing. >> So, is it really a big problem to update the relevant text files? If >> that process is not documented clearly enough, that is something we can >> address right now. >> >> W.r.t. adding the wheel building machinery into the skimage source repo, >> I'm not sure I see how that would be useful, or why that would be a good >> fit. >> >> W.r.t. backports to 0.14.x—since we no longer support 2.7 on master, >> this really is the only way to give 2.7 users access to new features. >> When a backport is easy to do, what motivation do we have for witholding >> it? >> >> Thanks for your thoughts! >> Stéfan >> _______________________________________________ >> scikit-image mailing list >> scikit-image(a)python.org >> https://mail.python.org/mailman/listinfo/scikit-image >> > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image >

1 0

Re: [scikit-image] A request for more frequent releases
by Stefan van der Walt Sept. 11, 2018

Sept. 11, 2018

On Tue, 11 Sep 2018 23:16:29 +0300, Egor Panfilov wrote: > - 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. In an ideal world, we would be ready to punch out a release at a day's notice, but would probably only release every three months or so. A release is not merely a tagging of the current master, but also a statement about the readiness of the code it contains. E.g., we are more lenient about merging experimental features early on in the release cycle, and sometimes modify or even remove APIs that we feel are not mature enough. Mark, I wonder if some of your issues can be addressed by daily wheel builds (which we already have)? Then you can point pip to our Rackspace wheels container, and install from there. The 32-bit issues mentioned were long known, because Matthew builds for that platform daily, and reported the failures a long time ago. It has not been fixed because no one has taken the time to investigate thoroughly (perhaps not that many developers care about 64-bit?). I fully support attempts to reduce the burden of turning `master` into a release. One such a proposed change was versioneer, but I recall from Mark's previous PR (https://github.com/scikit-image/scikit-image/issues/3144) that it introduced quite a bit of complexity for little gain. I'm not sure why the current versioning is considered troublesome; it is stored in `skimage/__init__.py`, and is reused everywhere else. W.r.t. listing new features for a release, Nathaniel's suggestion of Towncrier looks sensible, and helps to avoid conflicts. On the other hand, the more tools we use, the higher the overhead to contributing. So, is it really a big problem to update the relevant text files? If that process is not documented clearly enough, that is something we can address right now. W.r.t. adding the wheel building machinery into the skimage source repo, I'm not sure I see how that would be useful, or why that would be a good fit. W.r.t. backports to 0.14.x—since we no longer support 2.7 on master, this really is the only way to give 2.7 users access to new features. When a backport is easy to do, what motivation do we have for witholding it? Thanks for your thoughts! Stéfan

2 1

Re: [scikit-image] A request for more frequent releases
by François Boulogne Sept. 11, 2018

Sept. 11, 2018

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

2 1

Advanced Scientific Programming in Python summer school (20 - 27 Jan 2019, Canberra Australia) - applications open!
by Genevieve Buckley Sept. 10, 2018

Sept. 10, 2018

Calling all Asia Pacific scientific programmers: Applications are now open for the 2nd Advanced Scientific Programming in Python Asia-Pacific summer school. The course will be held at the Australian National University, Canberra, from Sunday 20th to Sunday 27th January 2019. Registration is free, and we have a limited number of travel scholarships available. *See https://scipy-school.org <https://scipy-school.org/> for more information and to apply. Applications close 7th October 2018 at 23:59pm Anywhere on Earth <https://www.timeanddate.com/time/zones/aoe>.* Juan ran the first Asia Pacific fork of this school in January 2018. I actually went to that and found it really practical and useful - it's definitely made me a stronger programmer. There's also a twitter account @scipyschool <https://twitter.com/scipyschool> - Genevieve

1 0

Re: [scikit-image] A request for more frequent releases
by Juan Nunez-Iglesias Sept. 9, 2018

Sept. 9, 2018

On Mon, Sep 10, 2018, at 4:52 AM, Mark Harfouche wrote: > I don't know if you are still using "projects" on github to track > these meta issues.> > I think this one seems quite appropriate. > > https://github.com/scikit-image/scikit-image/projects Agreed, no, we are not using projects at this moment. (At least I'm not.) Probably that should change. As a stopgap, you could create individual issues for these and then create a tick-box issue tracking them. But you're right that projects is the right approach. > I would like to an other discussion point: > 8. Rethinking how often we backport to 0.14.X. Can you elaborate? Do you want to increase or decrease the frequency of this? Juan.

1 0

Re: [scikit-image] A request for more frequent releases
by Mark Harfouche Sept. 9, 2018

Sept. 9, 2018

I don't know if you are still using "projects" on github to track these meta issues. I think this one seems quite appropriate. https://github.com/scikit-image/scikit-image/projects I think we have identified a pain points that need to be addressed and discussed: 1. Streamline the wheel building process. 2. Streamline building docs 3. Better testing 32bit linux (this seems quite important at least for the ARM community) 4. Streamline the release notes. 5. Streamline the versioning. 6. Streamline the contribution notes generation. 7. Choosing the frequency of the releases. I would like to an other discussion point: 8. Rethinking how often we backport to 0.14.X. On Sun, Sep 9, 2018 at 3:55 AM Juan Nunez-Iglesias <jni(a)fastmail.com> wrote: > Mark, > > > I posted it here as it seems that these organizational changes are > discussed more on here than on github. > > Yes, the mailing list is definitely a good place for discussions, and I > did not mean to suggest that you posted it to the wrong place! But, once we > have a concensus on something needing to be done, which I think we do here, > GitHub is the place. As to the roadmap issue, the reason I suggested it is > that a major part of the roadmap is to improve the contribution experience > for everyone. The points you raise in that regard, that someone might be > demotivated to contribute because their contributions take forever to make > it into a release, are thus very relevant to the roadmap. > > > A monthly release cycle is fine, but as is, I think it is too much work > to expect from people "donating" their time. > > Note that I am not suggesting monthly with the current release process, > I'm suggesting monthly with a new and improved process. =) > > Nathaniel, > > > There are tools like 'towncrier' to avoid merge conflicts in the release > notes. > > > That avoids merge conflicts in the release notes, because every > > release only has one change :-) > > This seems too frequent for me. =) > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image >

1 0

Re: [scikit-image] A request for more frequent releases
by Juan Nunez-Iglesias Sept. 9, 2018

Sept. 9, 2018

Mark, > I posted it here as it seems that these organizational changes are > discussed more on here than on github. Yes, the mailing list is definitely a good place for discussions, and I did not mean to suggest that you posted it to the wrong place! But, once we have a concensus on something needing to be done, which I think we do here, GitHub is the place. As to the roadmap issue, the reason I suggested it is that a major part of the roadmap is to improve the contribution experience for everyone. The points you raise in that regard, that someone might be demotivated to contribute because their contributions take forever to make it into a release, are thus very relevant to the roadmap. > A monthly release cycle is fine, but as is, I think it is too much > work to expect from people "donating" their time. Note that I am not suggesting monthly with the current release process, I'm suggesting monthly with a new and improved process. =) Nathaniel, > There are tools like 'towncrier' to avoid merge conflicts in the > release notes. > That avoids merge conflicts in the release notes, because every > release only has one change :-) This seems too frequent for me. =)

1 0

Re: [scikit-image] A request for more frequent releases
by Nathaniel Smith Sept. 9, 2018

Sept. 9, 2018

On Sat, Sep 8, 2018 at 9:52 PM, Mark Harfouche <mark.harfouche(a)gmail.com> wrote: > 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. There are tools like 'towncrier' to avoid merge conflicts in the release notes. If you want to be a bit more ambitious, there's also: https://hypothesis.works/articles/continuous-releases/ That avoids merge conflicts in the release notes, because every release only has one change :-) -n -- Nathaniel J. Smith -- https://vorpus.org

1 0

Re: [scikit-image] A request for more frequent releases
by Mark Harfouche Sept. 9, 2018

Sept. 9, 2018

Hi Juan, Thank you for the quick reply. The amount of work to overhaul the release infrastructure is definitely non trivial. I totally agree. That is why it isn't worth doing Changing the build infrastructure and the release infrastructure needs to be done carefully (as I have learned a few times asking others to install empty packages of mine :S). That said, I think we can approach your "tag to release" idea, especially with the amount of resources available for OSS on Github. You are totally, rebasing is really an advanced feature and quite difficult. I've had trouble explaining it to many of my team mates. Lets keep discussing ideas for the changelog. I definitely think we can improve on the current state of "go through the old PRs". A monthly release cycle is fine, but as is, I think it is too much work to expect from people "donating" their time. That said, I'm not the one cutting the releases. I know the build infrastructure is complex, but this isn't something that was ever easy to understand. Bots aren't easy to understand either. This is because PyPi wants to target the oldest linux it can, and not because scikit-image is much harder to compile than other python projects. As it stands, we were surprised by failures on 32 bit linux when 0.14 came around. This should have been caught and marked as `xfail` a long time ago. By having the wheel infrastructure built into the every day process, we should be much more confident that we could release 0.15 "tomorrow" without fear that something would break on one of our supported architectures. And yes, I mean .15 since I've been living on master for the last few months, though I've slowly been reverting to 0.14 + monkey patching (which I really don't like). I posted it here as it seems that these organizational changes are discussed more on here than on github. Mark On Sun, Sep 9, 2018 at 1:58 AM Juan Nunez-Iglesias <jni(a)fastmail.com> wrote: > Hi Mark! > > Coincidentally I'm cutting 0.14.1 right now! > > Actually Stéfan already suggested this a while back. It hasn't happened > not because of any actual opposition to the idea, but because all of the > automation work you suggest is not trivial. I'd also like to bring up > François's point that our build machinery is already quite complex, and it > can be somewhat of an impediment to newcomers. > > On the other hand, I actually believe that we can *both* simplify the > build machinery *and* get rolling releases, but this is not an afternoon's > fix. > > The only part of your proposal that I find objectionable is calling > constant rebases a feature. Rebasing is an extremely unfriendly workflow > for beginners. > > My proposed amendment to your proposal is that we move to a monthly cycle, > and create a "release bot" that creates a PR on the 1st of each month with > the contribs.py output. Someone can modify the PR to tweak the output where > needed, merge, and tag. > > Lastly, I think this would be a good comment to add to our roadmap RFC: > https://github.com/scikit-image/scikit-image/issues/3263 > > Juan. > > > On Sun, Sep 9, 2018, at 2:52 PM, Mark Harfouche wrote: > > 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 > > > *_______________________________________________* > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image > > > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image >

1 0

Re: [scikit-image] A request for more frequent releases
by Juan Nunez-Iglesias Sept. 9, 2018

Sept. 9, 2018

Hi Mark! Coincidentally I'm cutting 0.14.1 right now! Actually Stéfan already suggested this a while back. It hasn't happened not because of any actual opposition to the idea, but because all of the automation work you suggest is not trivial. I'd also like to bring up François's point that our build machinery is already quite complex, and it can be somewhat of an impediment to newcomers. On the other hand, I actually believe that we can *both* simplify the build machinery *and* get rolling releases, but this is not an afternoon's fix. The only part of your proposal that I find objectionable is calling constant rebases a feature. Rebasing is an extremely unfriendly workflow for beginners. My proposed amendment to your proposal is that we move to a monthly cycle, and create a "release bot" that creates a PR on the 1st of each month with the contribs.py output. Someone can modify the PR to tweak the output where needed, merge, and tag. Lastly, I think this would be a good comment to add to our roadmap RFC:https://github.com/scikit-image/scikit-image/issues/3263 Juan. On Sun, Sep 9, 2018, at 2:52 PM, Mark Harfouche wrote: > 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 > > > _________________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

1 0