ocaml-community
Move notty to ocaml-community
Propose to move a project to ocaml-community
Project name: notty
Initial author(s): David Kaloper Meršinjak (@pqwy)
Current URL:
- https://github.com/pqwy/notty
- https://github.com/ocaml-dune/notty
License: ISC License
Description: Declarative terminal graphics for OCaml
Do the current maintainer(s) agree with the move: The current maintainer has not updated the project in the past 3 years, and has not responded to public or private contact attempts in the past month. See https://github.com/pqwy/notty/issues/53.
New maintainer: I volunteer as a maintainer. Possible interested persons include Dune maintainers. cc @shonfeder @punchagan @Leonidas-from-XIV @Alizter @favonia
One community fork has already happened under the Dune umbrella. Dune developers have expressed privately that they may not have the necessary bandwidth to review patches to notty that are not affecting Dune itself. I propose we adopt notty as it currently is under the Dune fork (it has only a few compatibility and feature patches above upstream), merge the few pending patches, and release on opam.
If you are volunteering as maintainer, I don't see any issue with it.
One thing that was explained is the potential importance of the package for the community at large?
It's my understanding that notty is (one of?) the go-to library for text user interfaces (TUI) in OCaml. Upstream is missing Windows support, and Dune devs and I independently wrote patches to support it. Dune devs have added more features to support colors and terminal features, and new OCaml versions. Notty is notably being used in:
- bechamel_notty, a simple tool to generate a CLI output with notty which shows results from bechamel's benchmarks (as core_bench);
- hardcaml_waveterm, a terminal based digital waveform viewer for Hardcaml;
- Ascend, a simple, yet fun terminal RPG;
- docfd, TUI multiline fuzzy document finder;
- meio, Monitor Eio programs.
- it is also a dependency of Lwd/Nottui.
Looking at the dependencies I'm also cc-ing @darrenldl @let-def @m-laniakea to let them know of the possible change of maintenance, and ask whether they could be interested in co-maintenance.
I'm also interesting about the maintainance of this package due to my usage for, as you said, bechamel but also some personal projects with miou and unikernels in general :+1:
I'm happy to help maintain. Further support for its importance in the community may be gathered from https://github.com/search?q=language%3Aocaml+notty&type=code
That sounds pretty healthy. Let's wait a little bit to see if there are other opinions. Otherwise we should proceed with the move.
I am the dune dev in question and I support supporting this package independently if the original author is no longer available.
Tagging @faldor20 as they also use notty in jj_tui and also maintains a nottui fork with picos support (if I recall correctly).
Well this all sounds pretty healthy and needed to me. I'm cool with making the move since nobody has objected so far and a lot of support was expressed.
Shall we try to move the https://github.com/ocaml-dune/notty repo here? That would be the best way to ensure continuity for this who are using it already I imagine?
I think all people are not totally in-sync with what dune's people did. It will be better to take pqwy/notty and redo PRs done into ocaml-dune/notty but with a consensus.
I agree. ocaml-dune/notty is dune's own vendored copy of the original notty repo so any patches there are not "official". These can be upstreamed if needed at a later date, but it should be orthogonal to the work on notty itself.
Cool. I have created a fork of the original repository and added @MisterDA as admin. I'll let y'all do the rest, let me know if there's anything else we can do.
I suggest porting the patches over relatively soon, updating the upstream URL and doing a release, so OPAM will point to this new repo.
I don't think it's a good idea to be so hasty doing a release or even creating the repository here. One month isn't a very long time to wait for an answer from someone who might be unavailable. How many pings did you send? When? Where? @pqwy's last sign of life on github is January. This is not a very long time ago.
I would hate to see this move be viewed as a hostile takeover if @pqwy comes back a month for now only to find all this was decided in less than 24 hours.
I feel like in the absence of feedback, if people were willing to move forward, it would've been more productive to make a fork instead, similar to what happened with nocrypto vs. mirage-crypto.
We certainly don't want anything like a hostile takeover. If publishing a fork is a gentler way of helping the community move forward using improvements on the library, I'm happy to help with that instead.
That said, I don't think we are being extremely hasty in broaching the subject, even if this particular issue may have advanced too quickly.
Here's is some context.
These PRs are all open and pending without any reply:
- From Sep. 2022: https://github.com/pqwy/notty/pull/41
- From Apr. 2023: https://github.com/pqwy/notty/pull/46
- From Apr. 2024: https://github.com/pqwy/notty/pull/50
- From Jan. 2025: https://github.com/pqwy/notty/pull/52
These PRs were opened and closed by the authors, presumably (and surely, in 1 case), because they received no response:
- Oct. 2022: https://github.com/pqwy/notty/pull/42
- Dec. 2022: https://github.com/pqwy/notty/pull/44
- Sep. 2023: https://github.com/pqwy/notty/pull/47
You can look at the issues for similar signs. However, pqwy did cut a release on opam in 2022!
Given that we haven't allowed many months for the question of moving this to the community to marinate, perhaps it is better we publish the package on opam as notty-community or something?
Being able or willing to update your software is a different issue than giving up ownership of said software. Many (usually older) software have similar issues around maintenance and the OCaml ecosystem doesn't make exception.
perhaps it is better we publish the package on opam as
notty-communityor something?
Do you mean with a new library name or with the same name? I don't think it's a good idea if the library name doesn't change as well. Having the same name would mean a split-the-world situation where both libraries wouldn't be able to be installed in the same switch and thus packages depending on one or the other would conflict with each other too.
Being able or willing to update your software is a different issue than giving up ownership of said software.
AFAIU, there is no question here of ownership and neither dispossession nor "giving up ownership" is being proposed. I wonder if clarifying this point will help address some of your concerns?
Instead, what I understand to be proposed here is only a question of maintenance. As per https://github.com/ocaml-community/meta
Unmaintained packages that are of significant interest can be adopted by ocaml-community. Maintenance will then be performed collaboratively by the community. ... At minimum, maintenance consists of updating software to keep it working over time, as well as maintaining the corresponding OPAM package. It also includes adding needed features, refactoring code, adding and improving documentation, improving the style of the code, adding tests, etc.
Based on this criteria, "being able or willing to update software" is required to maintain software, and I believe the context presented here makes it pretty clear that notty has been unmaintained for about 2 years. (As an aside, I'd like to reiterate that this does not imply any fault or shortcoming of pqwy's).
There are (at least) three questions posed in this discussion so far:
- Given that notty is not actively maintained, should there be a community effort to maintain the code base?
- Should this community effort result in updates to the
nottypackage in the opam-repository, withe the change of source location that this would require? - If we answer (2) in the negative, and we instead add a new package, should the library be renamed?
I think there is a general consensus around (1), but perhaps you cold clarify whether (1) is also something you are concerned about, @kit-ty-kate?
(2) and (3) are obviously related, in that they depend on (1) and are incompatible alternatives. But I wonder if they are in scope for this thread?
(2) seems like a question that pertains to opam governance and policy, and in fact I think this may be an open question? I don't see any clear guidance potential changes of source archives related to changes in maintenance https://github.com/ocaml/opam-repository/tree/master/governance/policies . I am not sure where is the best place to have this discussion: should we open an issue on https://github.com/ocaml/opam-repository ?
(3) is a question that seems to pertain to the development and publication of the community-maintained package itself. AFAIU, neither the opam-repository nor the ocaml-community have any policies about how libraries are named. So perhaps this is something that should be discussed in an issue on https://github.com/ocaml-community/notty ?
Thoughts?
Hi all! I understand @kit-ty-kate concern here.
The open source license for the software does allow modification and distribution of the modified code:
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
so, the author has already granted this.
However, what matters most is transparency and friendliness w.r.t. the original author and their hard, original work.
At the very least, the community repository is a good place to reconcile the work that has been done porting the code to the latest build systems and compilers.
Beyond that, it would clearly be courteous to give @pqwy some time before we publish anything in the opam repository that could take over their work.
We should also have clear intent to do our due diligence and make every effort to contact the original author. Their email is in the git commits. Have we tried to email them already? Followed-up?
I would suggest that we document that here as well.
what matters most is transparency and friendliness w.r.t. the original author and their hard, original work.
I agree that this is of prime importance! I hope nothing done so far as been counter to this aim :)
I don't know that an email has gone out, but that sounds like a good idea and we can send that out in due time.
I think an email should be sent now so as to give the original author as much time as possible to get a chance to respond..
I didn't go over the entire discussion right now, but in my view Notty is being maintained. In particular, I'm an avid user of the library (or rather, of my own version which is perpetually about 20 commits ahead of the master).
My fundamental position is that tending to pull requests, or really Github activity of any sort whatsoever, is not a measure of project's health. It's a measure of engagement on this one particular social network which also provides git hosting. For context: I never see notifications when someone pings me, and I do use Github on most days.
I can respond more in depth when I catch time to read up on what happened here, but I would appreciate kindly refraining from hostile forks in the meantime.
No hostility of any sort is intended! I'm sorry if there was an appearance otherwise.
My fundamental position is that tending to pull requests, or really Github activity of any sort whatsoever, is not a measure of project's health. It's a measure of engagement on this one particular social network which also provides git hosting.
I am very sympathetic to this view. In retrospect, it was an oversight that I failed to send an email much earlier: sorry about that.
That said, given the opam metadata and the previous history of activity, I had assumed that the GitHub repo was the expected place for bug reports and collaborating on contributions -- I hope this is an understandable mistake given the context. I take this as a good reminder to think outside the GitHub bubble.
I am looking forward to collaborating on figuring out how best to move forward. Please let us know if you would prefer to do this by email or some other medium.
Hey, I got a ping here, and thought I'd mention, as one of the larger projects I've seen using notty I assumed it was unmaintained and was going to upload and publish my fork at some point that ads quite a few features needed for jj_tui.
@pqwy I understand you're not particularly interested in github PRs, but are you interested in accepting contribution of any form? If not, I feel that the ocaml-community making a non-hostile, but open to community contributions, fork, would be quite reasonable.
I'd say interacting with the terminal is a pretty foundational functionality, and for the health of the larger ocaml ecosystem, I'd personally like that package to be maintained and open to improvements.
On a personal note: Thanks a lot for making notty! During my extension of it, I've come to appreciate it as an excellent piece of engineering. You've managed to get an amazing amount of functionality out of less than 1k lines of code.
I'd like to share a note here to say that I sent a followup email on March 24th to @pqwy asking how/if we could do anything to support getting some of the fixes proposed upstreamed. I said I was happy to collaborate off of GitHub, and in any way desired. I have received no reply.
At what point does it become appropriate for us to make a very friendly fork which we can publish to opam, for the good of the wider community? The current state, afaiu, is that people are just maintaining their own forks, and we are losing out on collaboration and shared work.
Revisiting this after another 3 months. @faldor20 were you able to get any reply via this our other channels?
Should we perhaps consider moving forward with a community package at this point? It could let us try to reconcile https://github.com/ocaml-dune/notty with what @faldor20 has been working on.
@kit-ty-kate and/or @toots, how would you advise moving forward here?
I was wondering if it would make sense to create a notty-community fork as a version of notty which accepts community patches?
Nope, no reply. I am definitely in favour of releasing a notty community package