JupyterHub and BinderHub Team Meeting

  • Date: Thursday 21st January 2021

  • Time: 5 PM UTC

  • GitHub issue: https://github.com/jupyterhub/team-compass/issues/364

  • Calendar for future meetings: https://jupyterhub-team-compass.readthedocs.io/en/latest/meetings.html

By participating in this meeting, you are agreeing to abide by and uphold the Code of Conduct. Please take a second to read through it! :pray:

Welcome to the Team Meeting

Hello!

If you are joining the team video meeting, sign in below so we know who was here. Roll call:

  • Min / Simula / @minrk

  • Mridul / GESIS / @MridulS

  • Nick / Turing / @nbarlowATI

  • Sarah / Turing / @sgibson91

  • Ivana / Simula / @IvanaH8

  • Hassan / KAUST / @Hassan-Alzahrani

  • Wayne / Upstate Med University/ @fomightez

  • Tim / Binder / @betatim

  • Simon / University of Dundee / @manics

  • Rollin / NERSC / @rcthomas

  • Carol / Jupyter and Noteable / @willingc

  • Isabela / Quansight Labs / @isabela-pf

  • Erik / Sundell open source / @consideratio

Quick updates

60 second updates on things you have been up to, questions you have, or developments you think people should know about. Please add yourself, and if you do not have an update to share, you can pass.

  • Happy new year everyone! 🎉

Reports and celebrations

This is a place to make announcements (without a need for discussion). This is also a great place to give shout-outs to contributors! We’ll read through these at the beginning of the meeting.

  • KubeSpawner has user namespace support! Thanks @athornton! https://github.com/jupyterhub/kubespawner/pull/458

Agenda items

Let’s collect all potential agenda items here before the start of the meeting. We will then attempt to create a coherent agenda that fits in the 60m meeting slot. If there are similar items try and group them together.

  • Erik (15 min): progression of compromises associated with low maintainer capacity

    • Consider a massive open source project. It can have a strict set of practices for any changes (enhancement proposals, multiple approvals, pre-releases, extensive test coverage, changelogs, etc). Smaller projects couldn’t sustain such practices though. My point of discussion regards what practices we look to sustain for various repos in the JupyterHub github organization.

    • Feedback on how I’ve acted:

      • I’ve self merged PRs about CI system, obvious bugfixes, etc.

      • I’ve tried to make it as easy as possible for PR reviews

      • I’ve made time delayed self-reviews of PRs so they are in as good shape as possible

      • I’ve self-merged carefully considered PRs and opted put in additional attention post-merge to ensure it didn’t cause trouble.

    • What and when can we compromise on various practices?

    • Carol: Time sensitive: go ahead, self-merge. Will it break functionality? Don’t self-merge. Maintainers, use your best judgment. Don’t want to create a situation where ~20 PRs have been merged whenever you touch the repo.

    • org status report tools (developed by Carol)? Talk to Tania and Isabela at Quansight to automate something for us?

    • https://jupyter.kibble.dev/

    • Tim: PR review sounds like journal review - mostly it’s not like that in our org. It should be a check, but also keep people up-to-date so PR creator is not the only one who knows how it works. Does the fact that we have loads of open issues/PRs open matter?

    • Simon: Maybe long open lists does matter? Looks bad, looks like things has been ignored

    • Sarah: Advocate to the community that it’s ok to take over PRs? Pull Request of the month?

    • Min: As number of issues/PRs grows, it becomes difficult for maintainers to keep track of where their focus should be

    • Zach: dedicated meeting/time to check over these things

    • Tim: The size of the PR is almost always uncorrelated to the ease of review

  • Tim (10min): new federation member

    • have two fairly beefy machines but would need us to deploy our own k8s clusters on bare metal.

    • https://github.com/jupyterhub/mybinder.org-deploy/issues/1772

    • This is now 4 machines!!

    • If Hassan and his team can provide the Kubernetes deployment, this is an easy yes for us to take on. Mridul can provide advice on on-prem deployments of k8s.

    • Feeling is that it is worth trying to make this happen.

  • Min (5min): Minesweeper for in-cluster-deployed detection

  • Mridul (5min): Participation in Google Summer of Code? JupyterHub/BinderHub?

  • Nick and Piero (10 mins (Piero might not be able to join before 5:30 GMT)): Custom Jupyterhub spawner for Azure Machine Learning

    • As part of the Turing’s “Pangeo-on-Azure” project, we have been working with a team at the Met Office Informatics Lab to develop a spawner that provisions Azure Machine Learning Compute Instances on behalf of users, with JupyterLab servers running on them.

    • https://github.com/informatics-lab/aml-jupyterhub

    • Some problems:

Not Discussed

This meeting overran - sorry! :grimacing: I have moved the below point to an issue: https://github.com/jupyterhub/team-compass/issues/368

  • Min (2min): Attach meeting time to timezone that observes daylight savings? (an hour later in winter). I get the sense that the earlier time isn’t great for folks, and we don’t have to use UTC for everything.

    • :+1: tim, erik

    • :-1:

    • Sarah: Does this mean 9am/6pm in winter, 8am/5pm in summer?