Should we archive this project?

[krassowski]

Should we archive JupyterLab Desktop? Making regular new releases there is imperative from the security perspective (it is shipping a whole browser, with all its zero days), and it is also pretty high labour as the releases actually needs to be manually tested on MacOS, Windows, and Linux. I was helping with testing on Linux but currently neither have access to MacOS, nor availability to test all three in my free time. @mbektas did the most thorough testing back in the day and was managing the releases, so could possibly share some notes and thoughts there.

We previously discussed this on triage meetings when triaging issues in this repo, and last week on jupyter frontends meeting.

[jtpio]

It would be sad to have to archive the repo, because JupyterLab Desktop is a valuable piece in the Jupyter Frontends offering, and it was really received when first announced.

But the security risks and maintenance burden mentioned above are indeed likely enough to justify archiving the repo. Or at least for now.

Ideally, some folks would be able to pick up development instead, and maybe jupyter-governance/jupyter-foundation-governing-board#1 will help with this hopefully.

[mbektas]

I used to maintain this app in my personal time and unfortunately not finding that much free time to contribute anymore. I would suggest Jupyter org to consider investing in this app using the new funds (jupyter-governance/jupyter-foundation-governing-board#1), instead of sunsetting. Here are some of my thoughts on why we should keep this app:

1. I am guessing there are 100K+ active users of this product that would be disappointed to lose it. (see these stats)
2. This app lowers the barrier of entry to Jupyter eco-system (one click installation) and adds new features to JupyterLab web app (i.e. ability to work with different configurations in different directories, opening notebooks by double click and more).
3. Sunsetting this tool would lead more users to other notebook apps such as VS Code.
4. I expect the security risk surface area to be much smaller than assumed. Because the app's browser is only loading JupyterLab application and its extensions, in comparison to random websites a person browses on a regular browser.

[kburchfiel]

I have had a great experience overall with JupyterLab Desktop; it has been my main means of viewing Juptyer Notebooks for quite some time now. I had originally switched to the desktop program because I found that it was able to handle large notebooks that appeared to cause VS Code to crash. I'll understand if there's simply not enough time to maintain this project, but I hope that there would be a way to keep it running. Please know that I am very grateful for all the work you have put into it--it has not been in vain!

[krassowski]

I expect the security risk surface area to be much smaller than assumed. Because the app's browser is only loading JupyterLab application and its extensions, in comparison to random websites a person browses on a regular browser.

If a user is sent a Jupyter notebook, it may contain an iframe pointing to an arbitrary page. It may also contain arbitrary JS code. Yes, iframes/svg/js ought to be disabled for untrusted notebooks (so it will require user interaction beyond opening the notebook). But even consider most common widget applications which will just happily load code from CDN, some even without checking integrity...

[Carreau]

It would be sad to have to archive the repo

Archiving is (mostly) cosmetic, it is easy to unarchive.
It mostly signal to users that issues won't be looked at (and prevent opening new issues, etc).

I find it preferable to archive with a clear message, it is possible to unarchive, and where to request this, that have seemingly dead repo where users repeating issues wondering what the status is.

[afshin]

Thanks for opening this issue and discussion. We spoke about this at the Jupyter EC call on Tuesday and also at the Jupyter Frontends & Accessibility call on Wednesday. Here are some of the takeaways:

• One outcome of the Frontends and Accessibility call was that we had some amount of consensus that we'd like to keep releasing, supporting, and maintaining JupyterLab Desktop.
• We recognized that we didn't have enough resources to do this maintenance as things are currently. The triage team handles incoming issues insofar as they don't go ignored, but we aren't doing the other things maintenance requires of us.
• We wanted to ask @mbektas and @krassowski for a rough estimate of how much work is involved in maintenance, e.g., how much work is involved as follow up to each JupyterLab version that is published?
• If our suspicion that the number of hours required is affordable is accurate, we could use estimates like this as a basis to put together a funding proposal as the Jupyter Frontends subproject and ask the Jupyter Foundation to fund our maintenance plan.
• We also discussed that we'd need a plan to help other contributors overcome whatever hurdles are involved in working with this code base, since we recognize that building and working on JupyterLab Desktop may itself be intimidating to someone who hasn't built native apps before.

There are a group of us who are both in the Jupyter Foundation governing board and in the Frontends and/or Accessibility Councils, and we would like to offer our help to put together a proposal. If someone is willing to be the shepherd for this process, please comment here!

[krassowski]

I do not have a very good idea, @mbektas will have better estimates as the person who did the heavy lifting around releases, but I can highlight that there are two kinds of things that need to be done

1. upgrading the bundled JupyterLab version; this is typically easy, it requires:
   • verifying that the lab extensions injected by JupyterLab Desktop do not need updates and still work
2. upgrading Electron version to pickup security fixes
   • for patch releases typically straightforward
   • for major releases, these are frequent (every other month, https://www.electronjs.org/docs/latest/tutorial/electron-timelines) and often include breaking changes https://www.electronjs.org/docs/latest/breaking-changes. For example, in the past it required almost a complete rewrite of big parts of the code (separation of main and renderer process, IPC). We are currently on Electron 27, latest is 36, latest still supported is 33. We could get away with doing major upgrades once every ~6-8 months as there is about 4 releases supported at a time.

Then for each release we should ideally:

• test across OSes to confirm the installers work E2E and that the app works
• make sure the packaging works fine and propagates to the stores (currently snap store on Ubuntu and winget on Windows); the requirements of the stores change with time (e.g. around sandboxing exemptions) so this can add a burden post tagging the release

If I had to guess I would expect (1) for a minor lab release to take half a day for each release on happy path and up to two days if things go wrong; for a patch release of lab, this might be just a few hours. For (2) the time required will vary depending on what breaking changes are included.

[mbektas]

thanks @afshin, I like the plan.

@krassowski your estimate of the work involved for releasing new versions is looking good to me. Most of the steps are already automated and releases should be light lift. Some notes:

• Snap releases require a manual action to promote from candidate to GA (one click action on snapcraft.io)
• winget releases require a manual action in GitHub Actions (could possibly be fully automated)

Also heads up on some one time work expected:

• Apple certificates for publishing macOS version needs to be updated (due to migration from NumFocus to Linux Foundation)
• Secrets for GitHub actions need to be updated for release (very low effort), they expired as we didn't release for a long time
• Electron version and GitHub action workflows might need updates, again due to long duration from last release

[Ahri-man]

This is the best desktop app for Sagemath. Don't stop developing it.