Fork `basement`? As `baseplate`?

Learn
21

Hostile takeover of a package isn’t an implementation issue, it’s a policy issue. The current policy is “no”, and I wouldn’t want the Hackage admins to change that or make exceptions without a larger discussion with higher visibility than here. Thinkpieces on the the effect of one policy decision or the other on package maintainers, both as authors and as consumers. Making a change without such level of visibility in the name of expedience risks losing the trust of the community, as multiple other software package repositories have discovered.

To be clear, I’m not trying to shut discussion down. basement vs basement2 might well be the cause celebre that sparks off a larger discussion that leads to a change in policy. I just think it’s unreasonable to expect a different decision from the Hackage admins without that larger discussion.

Personally, I see it as inevitable that eventually some packages, however core to the ecosystem they may be, will occasionally reach end-of-life. Maybe the maintainer declines to make further releases. Maybe the source is found to be stolen from a non-public project. Maybe it’s too much work to maintain even if volunteers are available.

So if that’s a scenario you’re worried about, the question of “how can we make it easy for people who depended on a dead package to migrate to a different one” is a tooling question, and sounds like a great way to make a difference.

22

That’s a good point that I had not considered: it is not really possible to make a drop-in replacement. Edit: unless you count backpack because that was made to fix issues like this, but it’s practically unusable :confused:

Perhaps a compromise would be to appoint a trustee to make minimal patch-level changes to keep it buildable on newer GHC versions.

I was also made aware of a similar situation going on with the these package, where the maintainer does not want Hackage trustees to change a version bound on base with a revision: Relax these upper bound on base for GHC 9.14.1/base-4.22.0.0 · Issue #211 · haskellari/these · GitHub. It is a different case because the maintainer does want to continue maintaining the package, but they don’t have time to update to new base/GHC versions within two months.

24

It does, Uploading packages and package candidates | Hackage says

In particular, we expect as a consequence of the license that:

  • we have the right to distribute certain derivatives and format conversions, including but not limited to:
    • modified versions of package metadata

and also

By default, uploaded packages are curated which means that both maintainers and hackage trustees may revise their metadata (particularly involving version bounds) to guide build tools in producing install-plans.

25

Yet the cited source goes on to say:

Package uploaders may choose to exclude individual package uploads from curation, by setting the x-curation: field of the package’s cabal file to uncurated. Packages which are uncurated have no expectations on them regarding versioning policy. Trustees or maintainers may adopt uncurated packages into the curated layer through metadata revisions.

If I read it correctly may opt out of curation (although the text is half-baked about this, because this opt-out can apparently still be overruled).

Still, without the option to disown a maintainer curation can really just happen in agreement on all sides, because a maintainer upset about unwanted curation could just snap and vandalize the package by new uploads.

As mentioned by @arybczak , Hackage is toothless against bad acting, and I wonder whether this is a sustainable state of affairs. Currently, one individual holding a widespread dependency can effectively hold the whole ecosystem hostage.

jaror 27

We can talk about bad behavior in the abstract, but I think wanting to vet a successor maintainer of a package you wrote is more than reasonable. And it is also understandable that some people lack time to do this vetting. To me, the current situation is entirely explainable without assuming bad faith. So if you want to discuss bad actors in the abstract, please open a new topic and remember to criticize ideas, not people.

7 Likes
28

I think the issue is Vincent both doesn’t want to do that vetting and doesn’t want to have some Haskell “trusted authority” do it for him (partially because he thinks said authorities shouldn’t exist in the abstract?)

29

Package overlays allow drop in replacement. One sets up a local repository which is just a directory or a full online one (in the style of head.hackage head.hackage) and that overrides the namespace. This is not a longterm solution, since in the longterm one must migrate from the bad package, but it is a suitable interim stop-gap.

To reiterate the main points - hackage policy and the general package infrastructure is setup to both zealously respect maintainer rights (regardless of the “faith” in which they act) and also to make solutions possible through technical means when issues arise that require overriding hackage’s “source of truth”.

30

My impression is that for the rest of the community, the situation is not very different from a breaking GHC update, or the text 2.0 update. When there is a fork or a major version bump, and the changes have to trickle down the ecosystem.

I personally resonate with arguments both in favour of keeping the name, or forking. I believe if someone finds that a fork that changes the architecture of the package substantially would work better, then a new name is in order, otherwise it isn’t strictly necessary and a major version bump will suffice.

31

I don’t think it’s a maintainer right to publish to hackage, it’s a privilege gifted in kind by the hackage trustees.

Furthermore because basement has 25 direct and 4046 indirect dependencies it’s a lot of inconveniencing.
I think dependency impact should be taken into account.

Cryptonite had 257 direct dependencies, crypton has 99. so we churned roughly 157 packages by not revoking the privilege in that case. (although crypton has more inderect dependencies, which is interesting, people are still building!).

32

To clarify, hackage trustees are volunteers who help with aspects of Hackage work. They do handle takeover requests or set policy, though they do advise. Administrators set policy, accountable to haskell.org which ultimately controls the hardware.

It is true there is no “right” to publish on hackage. But once a valid package is published, the maintainers do have protections over how it is managed, which have been traditionally referred to as “rights.” As others have noted, the social impact of abrogating these commonly-understood rights has led to enormous controversy and loss of trust in other package ecosystems. To encourage use of hackage and trust in it, and generally a healthy climate in the ecosystem of Haskell contributors, I believe it is important we bend over backwards to ensure maintainers feel they have control over their packages, even while allowing delimited actions such as metadata updates (which have already been controversial enough).

The point of rights is you respect them even when its not always pleasant or the easiest path. Otherwise they are not rights, but just pious sentiments.

33

The point of rights is you respect them even when its not always pleasant or the easiest path. Otherwise they are not rights, but just pious sentiments.

Hackage is a public space, a registry. Publishing access is not only a privilege, but an entitlement. The maintainers are entitled to post their packages on Hackage wrt the common goal of having an easier time developing with Haskell (emp. original):

Because each package added to the main package index has a cost of operation and maintenance associated to it, your package should strive to provide value for the community by being intended to be useful to others

And if the maintainer becomes maintain-not, it is reasonable to expect that the entitlements to the common resources associated with the package are rescinded. That’s how the efforts of all the downstream developers are protected. Otherwise we can just go home and use git URLs instead of Hackage-registered package names (please don’t).
The absentee will keep their copyrighted code in their private repos, and even the pre-takeover versions on Hackage. So no rights are being trampled here.

34

With great power, comes great responsibility.

Indeed, we must not be blinded by the paradox of tolerance - we must remember we do this for the community, and individuals who have removed themselves from the community are no longer entitled to the community’s resources. The hackage namespace (and hosting servers and so on) belongs to the community, and individuals outside the community are still free to define their own namespaces. We are not erasing anyone’s work, we are reallocating a community address and scarce resource.

35

This is the logical slippage. By the current hackage rules and longstanding social understanding, which are the rules and understanding under which basement was originally uploaded, the criteria of “intended to be useful” are applied roughly contemporaneous to the period of upload, not any sort of ongoing commitment beyond then.

We can’t rules-lawyer our way to a claim that this is not the case. There remains the question of if we want these rules (I think they have served us well) or if we want to weaken them (which puts us on a slippery slope and risks burning community trust). And even if the rules were changed, is it in any way fair to change them retroactively? That also stands to burn trust.

36

If this is the case, then we do need rules for what to do when a packages “ceases to be useful” ie because it does not build and there is no maintainer, otherwise we are effectively being asked to should that burden for eternity for no purpose other than inherited “honor”. I wasn’t here when basement or memory was uploaded - rather, I sort of arrived amidst the implosion of the author’s leaving, so from my perspective things have already fallen apart, and I am being asked to respect the flaming wreckage of someone who decided that a kamikaze strike on the haskell ecosystem was the proper way to exit the community. I have spent considerable effort trying to patch that hole, as have others, and it is they who’s opinions I respect.

This discussion isn’t us actually falling down a slippery slope, it is a discussion of what to do if and when things start to fall again, and of where to place the guardrails so that they don’t. I am not advocating taking over packages willy-nilly because they are unmaintained, but the current specific case of an author who has quite deliberately left and is not coming back, is certainly worth discussing. That is not the same thing as ie a difficult-to-work-with-but-participating author with high standards, or someone who has health problems and is absent not of their own choice (as I occasionally have to deal with).

I think the expectation that a package be buildable according to some limiting criteria / span of most recent versions, to be an acceptable requirement for continuing to include a package in the registry, otherwise the registry itself becomes more of a historical document.

37

As I said, I think it is feasible we could try to establish new criteria, although we would have the problem of if existing packages should be grandfathered in. I have mainly been trying to explain, from the perspective of a hackage administrator who was around when all this policy was set, why it was set this way, and why current policy compels us to let things be.

That said, new criteria do immediately present the “slippery slope” problem. Suppose we say that any package that is “abandoned” can be taken over. Now what constitutes abandoned? Six months? Two years? Not building with X versions of GHC? What if a maintainer just keeps uploading new revisions, but neglects what people want? What if they take the package in a direction everyone hates? What if they keep it building but refuse to patch security bugs? If we set rules, they can be bent or negotiated around, and if we give generous discretion, then its possible to get in a situation where many people unhappy with how others maintain their packages are constantly filing takeover requests.

The basic advantage of the current situation is that it is a clear and simple policy. And the primary problem we face with the current situation is not resolved by taking over basement. It is a poor package that is part of an ecosystem of packages written by an egomaniac who did not ever write them with sufficient attention to safety and security, and who refused and rejected offers for help from others, as well as reports he didn’t care about. It is also a quirky and weirdly designed package. Taking it over and keeping it building in the minimal way just kicks the can down the road.

I massively appreciate the effort to move away from the busted cryptonite ecosystem, but that effort would not, in my estimation, be helped by taking over one namespace of one package. The “band-aid” solution requires some co-ordination, but as people have noted, not terribly more than the crypon fork already has taken (if that).

The longstanding tradition throughout almost all of the free software world has been that when one forks a dead project, they change the name. Hackage is not unique in this, it is following practices that have worked, if not brilliantly, then at least adequately, for going on 40 years. And history has shown that when people deviate from these practices, it leads to a threat of loss of trust and collapse of community.

38

I appreciate the weighty perspective, and I do not think we are misaligned :slight_smile: I am willing to slug out the difficult questions if you are.

I think that this is the weakest constraint - not building within a certain number of recent major versions. This is how some other languages handle it*, and allows for a truly-abandoned package to fall out of scope naturally.

* If they even include it implicitly at all; many esp older languages just outright do not assume that any packages from a previous major version are viable / included.

Hypothetically, after 2 major versions; if on major version n, the package was never built for n-1, AND was not buildable on the last minor version of n-2 (eg it was abandoned during n-2), we can release the name for reuse in major version n, effectively giving users at least one major version to reclaim their package’s registry name, and dying off when their package doesn’t build - and that can be part of the criteria (that if it still builds in a new major version it gets to keep its name, because sometimes lack of maintenance is indicative of stability, not abandonment).

I think it is understandable or even expected that in an up-to-date registry a package name by default refers to the most recent occupant.

They are being active in the maintenance of their project; they still retain total rights over how to structure and update it, regardless of users wishes. In these cases, the traditional ‘fork with new name’ is the appropriate venture, specifically because there is a need to differentiate the improved fork because the original still exists (that it is proceeding down an undesirable path is the impetus for forking).

That is a completely separate case from ‘this package is abandoned and taking up space and we want to reclaim the name for something else that builds on up-to-date systems’ - I’m just emphasizing the different subjects of forking a project, vs reclaiming a name. They are not necessarily coincident.

:heart: it is a labor of love

Oh I do agree - to be clear, I think the fork-renaming to crypton was the right thing to do, and I have no intent on forking OR reviving memory but rather am more concerned with the recycling of names - even though I myself am already consigned to taking a different name eg mem or memalloc, because according to my own proposed rules even if instituted it would be GHC 10 or 11 at the earliest before the name were up for recycling. I just don’t want to see this issue befall others.

I think it is sensible that when we use the term foo in a context, we expect that it refers to a package that builds for that contemporary version of eg GHC and hackage. Eg when using 9.x, I expect discussions to be centered around packages that build on 9.x and any references to former or obsolete versions to be called out as such. It is far easier to call out older versions as old, than it is to continually preface current conversation that I am using foo-2026 - and date-based versioning is one of the terminal ends of failing to deal with this issue.

Edited for minor typos.

39

Thank you. Very well said.

40

What if an author still updates the package, but doesn’t want to support new GHC versions, because they don’t like some change in GHC or base? Or what if the package doesn’t work with GHC at all, because it was written for another Haskell compiler?

I suspect in these case, the author should keep their package too?

41

Yes that would fall under “They are being active in the maintenance of their project”, the check that they are active supercedes any check for buildability. To clarify the proposed rule, lack of build(ability) alone is not sufficient for declaring a package name abandoned, it must actually be abandoned before we bother to check whether it still builds, and if it doesn’t, only then do we consider triggering name recycling - and we can mean ‘builds on target compiler’ / not assume GHC as to allow for targeting older or alternative compilers.

42

I don’t think I disagree with your post, but to remark on a small part of it: note that while any particular policy around takeovers might licence the takeover some people want today (a handover of basement), they will also become an attack vector for evil package takeover, and we really should design policies that are robust to sophisticated attacks against software supply chains.