# 2018.10.30 Hangout

**URL:** <https://discourse.slicer.org/t/2018-10-30-hangout/4588>\
**Category:** Weekly meetings\
**Created:** [October 30, 2018, 10:39am UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588 "2018-10-30T10:39:36Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [October 30, 2018, 10:39am UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/1 "2018-10-30T10:39:36Z")

</div>

Hi,

We will be having our weekly hangout today, at 10:00 AM EST.

On the agenda:

- review [Slicer 4.10 release notes](https://docs.google.com/document/d/1InbNscw4UPZxqMa2iiStQx0uq8bwvlcAx6wrgTPCpv8/edit)
- discuss further approaches to host and maintain user documentation

Anyone is welcome to join to ask questions at [https://bit.ly/slicer-googlemeet-hosted-by-kitware](https://bit.ly/slicer-googlemeet-hosted-by-kitware)

Thanks !  
Sam

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [October 30, 2018, 11:30am UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/2 "2018-10-30T11:30:09Z")

</div>

Hi Sam, Jc & all -

I’ll be at the [Qt conference](https://www.qtworldsummit.com/2018/boston/? __hstc=152220518.486ae67c1a81ebb446bcb4cd4eb0f907.1535027635636.1536322041797.1539006038224.3&__ hssc=152220518.1.1540898902505&__hsfp=3707452877&hsCtaTracking=28946892-97e4-423b-b292-f152c13d3751%7Ca69b5868-80f0-48f4-9872-e36e20e04f4d) today so I’ll miss today’s hangout. Great work on the 4.10 release!

-Steve

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [October 30, 2018, 1:03pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/3 "2018-10-30T13:03:54Z")

</div>

Ditto on the good work finalizing the release!

In addition to talking about future documentation methods, if you have time on the agenda, maybe you and others can revisit the discussion about a potential transition to Github issue tracking as well. This period after a release is probably a good time to revisit this topic. I posted a [comment](https://discourse.slicer.org/t/update-of-slicer-issue-tracker/437/8?u=jamesobutler) yesterday based on my recent experience using Mantis.

Thanks!

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [October 30, 2018, 3:16pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/4 "2018-10-30T15:16:12Z")

</div>

Meeting notes:

- @smrolfe joined us and asked question related to [Markups Module enhancements - #2 by danagood](https://discourse.slicer.org/t/markups-module-enhancements/4335/2)

- documentation

- Transition to GitHub

> [@jamesobutler](#):
>
> about a potential transition to Github issue tracking as well

- Transition Issue tracker:
  - after transitioning to GitHub (see above), new issues will be added to GitHub and user will be cased to do so.
  - existing issue would be manually “transferred” to GitHub on a case-by-case.
  - we would not spend time migrating existing issues.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 2, 2018, 4:29pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/5 "2018-11-02T16:29:32Z")

</div>

Regarding using git-lfs for documentation:

I’ve done some tests - see details here: [Should we use Git LFS to manage data?](https://discourse.slicer.org/t/should-we-use-git-lfs-to-manage-data/2448/13?u=lassoan)

In summary: git-lfs is not fully supported by GitHub web interface (for example, cannot upload git-lfs file trough web interface) and still not very robust (may break due to user errors, symlinks, merges, changing of git attributes, etc.).

**Short term:** I think we should not start using git-lfs now. Instead, we can store large documentation files (mainly screenshot files) as regular files. If we keep image sizes small then the repository size will remain manageable.

**Long term:** If we find that repository has become too large (not very likely to happen within a couple of years) then we can decide to move existing files to git-lfs or other solution that will be a state-of-the-art then. There is already a git-lfs command that can convert existing files to git-lfs files, so we could easily migrate any time we decide to do so.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [November 2, 2018, 5:30pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/6 "2018-11-02T17:30:36Z")

</div>

Thanks for the detailed report, very insightful

> If we keep image sizes small

What should be threshold ?

This script could be helpful to answer: [Shell script listing the N largest file found in the history of a git-versioned project · GitHub](https://gist.github.com/jcfr/4348af13d2c8931daeab4ff9ab73e14b)

And here is the output from that same script from few months ago: [List of the 350 largest files committed into Slicer Git history based of Slicer/Slicer@27109 mapping to r27109 from 2018-03-26 · GitHub](https://gist.github.com/jcfr/93fe51974d9db8ef55a6d3172c1de68d)

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 2, 2018, 5:47pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/7 "2018-11-02T17:47:44Z")

</div>

> [@jcfr](#):
>
> What should be threshold ?

Instead of setting a size threshold, we should probably specify recommended image size, file format, and compression setting, which produces optimal images for online documentation. I guess an images would end up being a few hundred KB.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [November 2, 2018, 9:28pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/8 "2018-11-02T21:28:31Z")

</div>

> [@lassoan](#):
>
> Instead of setting a size threshold, we should probably specify recommended image size, file format, and compression setting, which produces optimal images for online documentation.

That is a great idea.

That said I still think having a test running that would fail if un-compressible data files are above X kb (e.g 250kb) would still be complementary.

It looks there are online services to compress images ([online compress image at DuckDuckGo](https://duckduckgo.com/?q=online+compress+image)), we could re command one that support copy/paste of images and allow to set its parameter from a URL.

Or host a javascript based one on a webpage we control.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 2, 2018, 10:01pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/9 "2018-11-02T22:01:44Z")

</div>

Precommit hook with a file size limit would help in reducing chance of accidentally committing large files. Ultimately, it would be quality-checked manually when the pull request is merged.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [November 2, 2018, 10:18pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/10 "2018-11-02T22:18:43Z")

</div>

> [@lassoan](#):
>
> Precommit hook

Since I anticipate the documentation will be updated directly on GitHub in some case, I think in addition of the pre-commit hook, we should also have a pull-request check is still relevant.

The good news, is that with GitHub apps … these are now quite easy to setup. See [https://probot.github.io/apps/](https://probot.github.io/apps/) , [https://probot.github.io/docs/](https://probot.github.io/docs/) and [GitHub - gr2m/github-app-example](https://github.com/gr2m/github-app-example)

(no more need to host our own app on heroky like we do for the doxygen hooks, [GitHub - Slicer/github-circleci-trigger: A simple GitHub post-receive web hook handler able to trigger a CircleCI build.](https://github.com/Slicer/github-circleci-trigger))