Active maintainer

[konsumlamm]

There currently seems to be no active maintainer for this library. The last activity by @lspitzner was in November 2020, more than half a year ago. This is not meant as an attack, you probably have good reasons for not being active here, but I'd like to request that someone decently active gets appointed co-maintainer (ideally also with access to the Hackage package), so that this package can move forward (for example, there is no GHC 9 support currently, see #40).

@treeowl seems to be interested in this project (see #26) and is one of the containers maintainers, so I think he would be a great co-maintainer. If noone else is available, I'd also be willing to take over maintainership for this package. However, while I think I understand most of it (I understand how binomial heaps work), I'm not confident with the whole code base.

[mitchellwrosen]

I would (also) be happy to help maintain this package at a superficial level - dependency bounds bumps and generally keeping the build green. Let me know if you want that kind of assistance @konsumlamm

[treeowl]

I'd be happy to participate in maintenance.

[konsumlamm]

I would (also) be happy to help maintain this package at a superficial level - dependency bounds bumps and generally keeping the build green. Let me know if you want that kind of assistance @konsumlamm

I'd appreciate that!

I'd be happy to participate in maintenance.

Nice!

[lspitzner]

Sorry for being silent so long. I am not dead, just don't have much time atm. I'll look at the pure-maintenance PRs in the next days as well as add some new active maintainers.

[lspitzner]

I have merged the purely-maintenance PRs and released a new version, I hope this resolves the immediate annoyance to downstream package maintainers.

When I took on maintainership, my plan was to act as a co-maintainer and just do the required things to keep things going with ghc-releases. I'd like to integrate people's ideas of making bigger changes to the project, like the two open PRs that we currently have (#14 and #26). Unfortunately doing that - thinking about a better interface and if restructuring it all is worth it, reading the paper behind the changes of the worst-case bounds - costs more time than I can currently contribute. So I see some options: 1) Maintenance only: No big changes get merged, stable interface (lowest risk to the rest of the ecosystem) 2) Be permissive, just check that no obvious bugs get introduced, but trust that people act responsibly (new ideas, but risks breakages) 3) Add maintainers, and decide as a group 4) Pass on (active) maintainership to a single person (single cook, and clear responsibility).

I realize that the current state of affairs is effectively 1) but not properly communicated. Adding more co-maintainers is perfectly fine, but it does not resolve the question of what direction we want, and is best for the community. I think this package can be improved, and @treeowl's (current and future) PRs certainly deserve to be merged. But who is theoretically responsible for saying "no" to a PR?

All that said, I think we don't need to decide on the exact titles here. My plan is to just bring you all on-board and give you the permission to this repository on github and on hackage. @treeowl if you want to apply more changes, please go ahead; perhaps ask for some feedback from other maintainers but take into account we are all just a bunch of co-maintainers :)

Or shorter: "I will give you power, please act responsibly" :)

I'll need the hackage user-names of the new (co)maintainers, can you please send them over?

[konsumlamm]

Fwiw, my favorite option is 3). A simple rule would be that a PR needs at least N approvals to get merged (where N is for example 2 or 3).

My Hackage user name is konsumlamm.

[treeowl]

Three approvals to merge is massive overkill. One approval by a maintainer other than the one submitting the PR is definitely enough. My Hackage user name is dfeuer.

[lspitzner]

Added both of you to hackage, and you should be invited here as well.

[lspitzner]

@treeowl you might have the most in-depth knowledge of the algorithm. For PRs like #26 I don't think multiple reviews from co-maintainers who just want to keep this package compatible with ghc would help, and I'd really like to not create a new hurdle to improvements to the package, so I don't want a strict rule. Maybe leave it up for a week to let others look for obvious bugs, but otherwise feel free to continue on your own.

But when rewriting the interface of the library, it might be better to get more than a single approval :)

[treeowl]

@lspitzner FWIW, I really don't like having significant Hackage package repositories owned by individual GitHub accounts. If the owner goes away (voluntarily or otherwise), then the GitHub issue tracker and PR queue are orphaned, and it's not very nice. If, however, the repo is owned by a GitHub "organization", then said organization can have multiple owners, providing a substantial level of redundancy.

[thielema]

On Mon, 6 Dec 2021, David Feuer wrote: @lspitzner FWIW, I really don't like having significant Hackage package repositories owned by individual GitHub accounts. If the owner goes away (voluntarily or otherwise), then the GitHub issue tracker and PR queue are orphaned, and it's not very nice. If, however, the repo is owned by a GitHub "organization", then said organization can have multiple owners, providing a substantial level of redundancy.

In GitHub you can fork a repo. It seems more important to me to have multiple maintainers per package on Hackage, because you cannot fork there.

[treeowl]

@thielema , it's ultimately less important there, because a few months of not responding or a reported death will let the Hackage trustees reassign the package. Even a few weeks in an urgent case will get them to let someone else upload a new version.