Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

looking for maintainer(s) #42

Open
BurntSushi opened this issue Feb 11, 2019 · 20 comments
Open

looking for maintainer(s) #42

BurntSushi opened this issue Feb 11, 2019 · 20 comments

Comments

@BurntSushi
Copy link
Owner

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.

@nh2
Copy link

nh2 commented Feb 11, 2019

From #40 (comment)

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.

@mmzx
Copy link
Collaborator

mmzx commented Feb 11, 2019

I would be interested in taking part. Could you make recommendations on entry-points of the project?

@BurntSushi
Copy link
Owner Author

@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.

@mmzx
Copy link
Collaborator

mmzx commented Feb 11, 2019

Yep. I have just noticed actually it is not that much of code... 1 PR made already.

@BurntSushi
Copy link
Owner Author

@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?

@mmzx
Copy link
Collaborator

mmzx commented Feb 11, 2019

@BurntSushi indeed, I do have the capacity and willingness to take maintenance in this repository.

@BurntSushi
Copy link
Owner Author

@mmzx Awesome, thanks! I've added you as a collaborator. :)

@mmzx
Copy link
Collaborator

mmzx commented Feb 11, 2019

@BurntSushi Thanks! Started working on some basics...

@jasondeutsch
Copy link

jasondeutsch commented Feb 12, 2019

@BurntSushi Very interested in maintaining

@kahlil29
Copy link

@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 👍

@zhujinxuan
Copy link
Collaborator

Hi, I am interested in maintaining or contributing. I have some experiences of parser contaminator ixmatus/orgmode-parse#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
Copy link
Owner Author

Thanks! I've enabled Travis.

@zhujinxuan
Copy link
Collaborator

@BurntSushi Cool, I will submit a PR this weekend to make test and hlint running with every PR.

@zhujinxuan
Copy link
Collaborator

@BurntSushi Hi, can you add me as maintainer/collaborator?

Currently I am thinking about the following things in this repo:

  1. Use Attoparsec instead of parsec. Attoparsec is faster, and we can use Monad.fail instead of Either
  2. Some more modern haskell practice: Use hlint for some neater expression. Use package.yml to generate .cabal.
  3. Error message with position info
  4. For bin distribution, consider the docker
  5. Consider about exposing some module as lib

@BurntSushi
Copy link
Owner Author

BurntSushi commented Feb 14, 2019

@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.

@zhujinxuan
Copy link
Collaborator

@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.

@BurntSushi
Copy link
Owner Author

@zhujinxuan That link gives me a 404.

I think adding a WIP label or using draft pull requests should be sufficient.

@zhujinxuan
Copy link
Collaborator

@BurntSushi Draft pull request is great. I think I shall add PR template to ensure I will not forget WIP label everytime.

@aberezin
Copy link

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.

@mmzx
Copy link
Collaborator

mmzx commented May 17, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants