Community Maintenance proposal: Haskell Party

I have been thinking about two related things when it comes to package maintenance, how can we:

  • Lessen the burden for maintainers to keep their packages up to date?
  • As a community adapt to breaking changes in the ecosystem quicker?

The Haskell Foundation Stability Working is discussing these topics and I have written a proposal that I think will be easy to implement and not conflict with any of our ongoing work.

The proposal can be found here: Introduce Haskell Party proposal by bergmark · Pull Request #12 · haskellfoundation/stability · GitHub

Any feedback is appreciated. Do you think this would be useful? Would you like to help out? Do you have any Haskell projects that would fit in here?

Feel free to post your comments here or on the issue tracker.

3 Likes

Thanks for drafting this! A series of questions:

  • what if a library is not on github (gitlab, darcsden, etc.)? Would this process accomodate those too?
  • Would the maintainers be work “per package”? Would there be “haskell party general” folks (handling relatively straightforward commits like dependency bumps etc.)?
  • would this include evaluating merge requests (stuff more complex than a simple dependency bump)?
  • how would HP handle maintainers inactivity?

I believe the idea is good and could help the ecosystem a lot.

2 Likes

Thanks for the feedback and questions!

I’m typing these replies in the way I currently imagine things working, so please let me know if you think I’m heading in the wrong direction.

what if a library is not on github (gitlab, darcsden, etc.)? Would this process accomodate those too?

I think it would be simpler to manage if everything was in the same place, and it is possible to copy repositories into the organization if it’s not available in another github account. But I imagine that we would want some index of the packages we manage and I don’t see any blockers from referencing alternative VCS hosting platforms. In the beginning it may make sense to focus just on github and if the HP takes off and there is demand, then we can evaluate other platforms to see how we could administer them in a similar fashion.

Would the maintainers be work “per package”? Would there be “haskell party general” folks (handling relatively straightforward commits like dependency bumps etc.)?

Maintainers would work per package. I think having these general maintainers would be good. This could start out as an informal process where such a volunteer can simply apply to help maintain some of the packages. I’m hoping that we could be very permissive in adding more maintainers to these projects, but that would be up to the maintainers of the project in question. I would like to avoid having only a few people do most of the work as that makes one person leaving a high risk.

This could also be an opt-in when joining: Do you want to allow Generals to make simple patches ala NMUs?

would this include evaluating merge requests (stuff more complex than a simple dependency bump)?

I think this is pretty hard to do. Even if I was granted access a proper maintainer of an existing library, I would be hesitant to do complex changes without taking the time to understand the project and the impact. I think this is best left for the maintainers.

how would HP handle maintainers inactivity?

I was vague on this, but I imagined there would be some periodical check-in to see if the maintainers are still around by checking github activity (are there simple PRs that go unmerged?) and perhaps asking if the listed maintainers still consider themselves active.

If the maintainers cannot be reached then we would do a callout for new maintainers.

It’s good that you bring this up because I think we need to specify how this will work in more detail before we launch. This process should be simpler and quicker than package takeovers, but I’m not sure how aggressive we should be.

2 Likes