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

Package memory needs attention #419

Open
erikd opened this issue Oct 9, 2024 · 10 comments
Open

Package memory needs attention #419

erikd opened this issue Oct 9, 2024 · 10 comments

Comments

@erikd
Copy link

erikd commented Oct 9, 2024

The package memory has its Git repo marked as "archived".

I have forked the repo and am willing to take over maintainership.

@andreasabel
Copy link
Contributor

We need to summon a stronger wizard for this.

ATTN: @gbaz

@ysangkok
Copy link

Since Vincent refuses to hand over Hackage packages, I think there is no way around allocating a new name?

This is what was done with x509, it is now available in LTS-23 as crypton-x509 and Kazu Yamamoto is maintaining it.

Why is memory any different?

More discussion at (this also includes a message from Nicolas di Prima, the other Hackage maintainer for memory):

@erikd
Copy link
Author

erikd commented Dec 10, 2024

I am still pretty certain than someone in the Hackage Trustees has the power to do this without requiring the package to be forked. From personal experience, I can tell you that replacing cryptonite with crypton in a large codebase (Cardano) is a HUGE pain in the neck.

It would be much better to this package reassigned than to fork it..

I have sent an email to the Hackage Trustees mailing list.

@andreasabel
Copy link
Contributor

The Hackage admins can do this, and the current list of admins is:

From this list, I have only seen Gershom being responsive and active for the Haskell community as a whole (so I wonder whether this group needs some reformation to stay agile...).

@erikd
Copy link
Author

erikd commented Dec 11, 2024

On the Hackage Trustees mailing list Gershom stated that this situation is one that the Trustees guidelines never envisioned. The Trustees will need to come to a decision on how to deal with situations like this and extend the policies.

@bmillwood
Copy link

huh, I definitely assumed I had been replaced as an admin some time ago... I have been absent from the community for a long time but I'm somewhat on board with getting more involved again. Might need to rejoin some mailing lists.

@phadej
Copy link
Member

phadej commented Dec 11, 2024

On the Hackage Trustees mailing list Gershom stated that this situation is one that the Trustees guidelines never envisioned.

Package takeovers are handled by Hackage Admins, not Trustees. Don't mix these groups.

@bmillwood
Copy link

I've had a closer look at this particular issue, and:

  • I believe I'm not on the [email protected] mailing list, so I've e-mailed them about that.
  • I think Vincent's viewpoint is pretty reasonable here, so I'm disinclined to eagerly overrule him.
  • I think the package takeover process does not explicitly handle the case where you can contact the maintainer, and they explicitly don't want a takeover. It seems to me like forking is the recommended remedy there. I'm aware it's painful (I've run into it myself: make use_crypton default true (or automatic?) ocheron/cryptostore#13) but the alternatives also seem somewhat painful to me.

In any case I won't take any action until hackage-admin@ get back to me, since I'm not clear anyone knew I was still an admin, so I want to double-check people are comfortable with that first.

@hesselink
Copy link

I've also been an admin for a long time, but am not longer involved in the Haskell community much. As such I'm also hesitant to make any call on this issue, although I'm happy to help out where there is consensus if other admins are absent.

@bmillwood
Copy link

bmillwood commented Jan 3, 2025

I posted on Discourse about this: https://discourse.haskell.org/t/policy-regarding-taking-over-hackage-packages/11121

My plan is to support a fork and not a takeover, but we'll see if anyone persuades me otherwise.

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

6 participants