BurntSushi
looking for maintainer(s)
This package has been fairly unmaintained for a long time, but there is a steady stream of interest in it. I doubt I'll ever get back into this project specifically, so I'd be happy to see it live on in the hands of someone else.
My thinking is that I could add interested parties as contributors to this repo. If things go well for a ~year, then I'd be happy to just transfer ownership of the repo itself.
From https://github.com/BurntSushi/erd/issues/40#issuecomment-462365015
I'd then link it for you on Haskell reddit and mailing lists unless you want to do that.
I've done this, Reddit and the Haskell-Cafe mailing list.
I would be interested in taking part. Could you make recommendations on entry-points of the project?
@mmzx I haven't looked at the code in about five years myself. So I'm probably pretty useless. If I were to start somewhere, I'd look into the issue tracker and see about fixing the various build issues people have had. And potentially migrate to Stack (or support in addition to Cabal). Otherwise, there isn't that much code. Tokei reports ~500 SLOC.
Yep. I have just noticed actually it is not that much of code... 1 PR made already.
@mmzx To clarify, I'm not looking for contributions, but rather, maintainers. I don't have the bandwidth to do PR review. Is taking over maintenance something you'd like to do?
@BurntSushi indeed, I do have the capacity and willingness to take maintenance in this repository.
@BurntSushi Interested in collaborating/maintaining/contributing to this repo, though I haven't the first clue what it's all about. I'm quite okay with Haskell though, So I think some reading through should get me up to speed 👍
Hi, I am interested in maintaining or contributing. I have some experiences of parser contaminator https://github.com/ixmatus/orgmode-parse/pull/42 and have some experience in solving kata with haskell (2kyu in codewars, https://www.codewars.com/users/zhujinxuan/stats)
Can you add the travis to this repo? It seems only the repo owner (not the maintainer) can grant permission for travis.
Thank you, Jinxuan Zhu
@BurntSushi Cool, I will submit a PR this weekend to make test and hlint running with every PR.
@BurntSushi Hi, can you add me as maintainer/collaborator?
Currently I am thinking about the following things in this repo:
- Use Attoparsec instead of parsec. Attoparsec is faster, and we can use Monad.fail instead of Either
- Some more modern haskell practice: Use hlint for some neater expression. Use package.yml to generate .cabal.
- Error message with position info
- For bin distribution, consider the docker
- Consider about exposing some module as lib
@zhujinxuan I've added you as a collaborator.
Points 2 and 3 sound fine to me, although, I'm not sure generating a cabal file from some other layer of abstraction is a good idea. But I'll defer to you all.
For point (1), I'd advise against major architectural changes for performance reasons unless you have good evidence that performance is actually a concern that is negatively impacting the user experience. I strongly suspect this is not, and will likely never be, the case for erd. Unless parsec is unmaintained (I've not been involved in the Haskell ecosystem for a long time), I would think it should be fine to stick with it. My hope is that major architectural changes will be done via a consensus through you and the other collaborators (@mmzx). If you do decide on major architectural changes, it would probably be good to try to setup some kind of integration test suite first, although, I grant that is likely difficult. At least some tests on the parser would be good and possible though, I think.
For point 4, I think it would be better if we just shipped static executables. Although, GraphViz is a wild card here that might benefit from Docker. My advice is to keep things simple.
For point 5, I'd strongly urge you to gather at least 1 (preferably 2) concrete actual use cases before doing this, and then develop the library to target those use cases. Please do not turn it into a library just because it's possible. Maintaining a library with a well documented in API in addition to a command line application is quite a bit more work than just maintaining a command line application.
@BurntSushi Hi, would you like to add WIP plugin (https://github.com/settings/installations/208485) into this github project? WIP plugin helps to prevent careless merge when there is a "work in process" label in the PR. It is only a plugin on github, and will not affect the code.
@zhujinxuan That link gives me a 404.
I think adding a WIP label or using draft pull requests should be sufficient.
@BurntSushi Draft pull request is great. I think I shall add PR template to ensure I will not forget WIP label everytime.
Did any maintainers show up? Im not a Haskel person but tried to build this on mac M3 with several different ghc and several llvms and couldn't get it to build.
Yep, me for instance.
Your M3 related issue is ghc related probably; first that should be resolved on your system. Also, you could use a docker container as noted in the readme or here: https://github.com/BurntSushi/erd/issues/107#issuecomment-2059949469
On Fri, May 17, 2024 at 20:17, Alan Berezin @.***(mailto:On Fri, May 17, 2024 at 20:17, Alan Berezin < wrote:
Did any maintainers show up? Im not a Haskel person but tried to build this on mac M3 with several different ghc and several llvms and couldn't get it to build.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>