reassign vincent hanquez packages

[ysangkok]

since vincent hanquez requested to stop receiving notifications, his packages should either be grandfathered or removed.

since it seems that he doesn't want to give away maintainership, i don't think there is any point of keeping the packages in stackage if they are currently disabled. so since we have connection < 0, i am saying that i think it would make most sense to remove connection entirely.

other packages might not be broken, so they could be kept around in stackage as "grand-fathered" until they break.

EDIT: see also:

• Label vincenthz packages as deprecated on Hackage haskell-infra/hackage-trustees#396

[andreasabel]

I'd:

• keep all enabled packages as grandfathered (or try to assign to their hackage maintainers)
• remove all disabled packages that do not have a hackage maintainer other then Vincent

In general, is there a policy of removing packages that have been disabled for a long time (like several major LTS bumps)?

[DanBurton]

I've taken the liberty of switching tls to ping @kazu-yamamoto, the listed maintainer for that package. As for Vincent's other packages, I think we should either do the same (identify the current maintainer and switch pings to them if that person is already listed in build-constraints.yaml) or move them to grandfathered.

As for packages that are disabled, we haven't historically had any procedures for "garbage collection".

[ysangkok]

@NicolasDP , would you be willing to take over basement, foundation, cli and memory?

[NicolasDP]

@ysangkok , thank you for considering me, but I will decline. I haven't contributed to either of these packages for a long time. I do not think I am the right person to take over and carry Vincent's legacy within the Haskell ecosystem.

[ysangkok]

IIRC, no person can take over those packages on Hackage since Vincent refused such a thing. So the only options are the people that currently have the uploader bits.

For basement and foundation, that leaves @snoyberg but given that he's also trying to step down development, it wouldn't make sense to assign the packages to him on Stackage. Not sure what the next step is then, @DanBurton ?

For memory, Nicolas Di Parma is the only uploader besides Vincent. So I suppose this could be removed to grand-fathered already @DanBurton .

[kazu-yamamoto]

Does Vincent want these package to be updated by other people?
If not, we should fork these package with other names and maintain them (like crypoton).

[vincenthz]

For the same reason as other packages, I do not want to pass maintainership of dead packages.

People interested in maintaining packages should just create replacement packages and motivate people to switch to their replacement using good old show of maintainership.

By passing packages to other people silently, this is effectively indirectly creating a supply-chain security potential issue, where I am responsible to carefully select the next person. (or worse some community overall maintainer pass privileges around to random people)

What I'm effectively arguing for, is that every user of a dependency should have a fair shot at:

• removing an unmaintained dependency
• either:
  • vet a new package to replace a dead dependency
  • find alternative replacement in existing packages

I appreciate that this community is too small to be mature for this security aspect, but the longer this is swept under the rug the harder it is to solve.

finally, getting a bit off topic, but packages that have some tractions should not be individually maintained, and should all move towards some kind of standardness / preludness in a stabilisation of the ecosystem effort.

https://xkcd.com/2347/

[vincenthz]

oh I forgot, since I do not maintain any haskell packages anymore, I figured removing the notifications would make sense (and/or removing packages from the set of maintained packages, not sure how things work after that)

[andreasabel]

finally, getting a bit off topic, but packages that have some tractions should not be individually maintained, and should all move towards some kind of standardness / preludness in a stabilisation of the ecosystem effort.

Seconded.
If just someone gave us a shitload of money to do that...

But, yes, seriously, exactly that: For second or third generation packages there shouldn't be room for maintainer ego, we should collaboratively maintain them at https://github.com/haskell. Should. But there is a reason why communism failed, even though it was so idealistic and beautiful in its concepts.

[vincenthz]

@andreasabel this has nothing to do with shitload of money or communism (WTF?), this is a leadership problem (or lack thereof) and related to UX (which "leaders" don't really give a rat's ass).

[snoyberg]

I wasn't paying close attention to this thread, but @vincenthz's response caught my attention. Reading the comment above:

For second or third generation packages there shouldn't be room for maintainer ego

I disagree with a lot of what you said @andreasabel, but this part comes across as straight up insulting.

[jmct]

I agree that the path forward here is for enthusiastic and motivated maintainers to fork the relevant projects and have users switch over to the new forks.

The Haskell Foundation is going to assist in identifying such maintainers, but obviously this isn't a switch that can be flipped instantaneously. It's going to take some time and effort for the necessary coordination.

My feelings are that any other solution is just a shifting the problem to the future by addressing the symptoms but not the root cause.

[ocramz]

@andreasabel

second or third generation packages

what do you mean with this? e.g. if the cryptonite-verse changed maintainership it would be a 2nd generation?

I have mixed feelings about "taking over" OSS packages. In this case, cryptonite and friends used to be a central dependency in most of the Haskell networking stack (which was a liability to start with, but the past cannot be changed).
Given how hard to replicate this functionality is, and how few resources there are to even try, the most economical way to not have someone re-type a whole cryptography stack would be to simply hand over the keys to a willing maintainer, assuming technical competence and good will (which are hard but not impossible within the Haskell community). This would not have broken users, at all. I don't agree with @vincenthz that an OSS package can ever be "dead"; I've recently picked up maintainership of scotty which had been effectively on life support for a few years, rolled up my sleeves and fixed a bunch of stuff, to the benefit of the whole community.

The second-easiest path was forking and renaming: crypton-* are a straight copy of the originals, and switching over meant some delays, misunderstandings, broken dependencies etc., but what's that on the scale of Haskell's 30-plus year history? Plus, this stuff is free right?

removing an unmaintained dependency
either:
* vet a new package to replace a dead dependency
* find alternative replacement in existing packages
I appreciate that this community is too small to be mature for this security aspect, but the longer this is swept under the rug the harder it is to solve.

@vincenthz this is technically true but not helpful at all. You've quite literally built critical infrastructure that many others came to rely on, like it or not, and by not handing it over you're effectively giving everyone the finger to make a point about OSS supply chain security.

[vincenthz]

@ocramz I have been pretty liberal adding people to the repositories and moving them to organisation. Some people helped but unfortunately moved on, and ultimately no one remained available.

The only one successful here was tls, which has transition seamlessly from me moving on from Haskell.

so yes I consider it’s too late, I don’t have time to vet new maintainers, and I find the model of moving existing stuff between a new random maintainer with just a takeover email to hackage trustees absolutely brain dead from many point of view (mainly security).

It’s great that you find time to solo maintain a dead package, but “spiritually” it may have nothing to do with the original scotty. It should be a new package (considering infrastructure limitation) and it should be properly advertise to people still using scotty as a “next evolution”. Those people still using scotty, should be in a position to make an active decision (I.e. more than just changing/putting version bounds) whether they want to use the new stuff or not. Anything else I consider that a hostile takeover of someone previous work (regardless if the original author agrees or not) with ramifications in supply chain.

maybe you should be more concerned with the shortcoming of the tooling and infrastructure (lack of package name spacing, replacement packaging, discoverability, patching) and community, instead of telling me that spending ~10 years of doing stuff for free is not good enough for you and I should be doing more.

[ocramz]

@vincenthz

instead of telling me that spending ~10 years of doing stuff for free is not good enough for you and I should be doing more.

I never said that ! We're all very thankful for your past work. What I said is that the most economical way forward for all participants, mindful of Haskell's current tooling limitations (single namespace etc.), was for you to give away maintainership.

Anything else I consider that a hostile takeover of someone previous work

Fixing 10-year old bugs? That's just ridiculous.

There is a broader discussion to be had about open source being "infrastructure" or not, but it can only start by not assuming hostile intent in others a priori.

[ad-si]

It’s great that you find time to solo maintain a dead package, but “spiritually” it may have nothing to do with the original scotty.

As you alarmingly display, the way the original author maintains packages can also have nothing to do with how they used to maintain packages.

Anything else I consider that a hostile takeover of someone previous work

You did a hostile takeover of your previous work.

(And if you're still reading Vincent: I'm also very grateful for your past work, thank you! Nevertheless, giving someone a gift and then coming years later to take it away or trying to restrict the way it is used, is still an absolute a-hole move.)

I don't understand why we still involve Vincent in this discussions. He has repeatedly said that he does not want to be involved and he does not care about any of our problems. All his packages are open source and there is no need to get him involved.

My suggestion:

1. Mirror all his repositories to https://github.com/haskell-github-trust
   (All references to his name must be removed to honor the BSD 3-Clause license.)
2. Add the https://hackage.haskell.org/user/haskell_github_trust as maintainer to all packages
3. Maybe introduce a two-person-rule for new releases of those packages to accommodate the lack of a lead maintainer.

What are your thoughts on this @jamesdbrock?

[vincenthz]

@ocramz

What I said is that the most economical way forward for all participants,

it may be the case, but in my opinion this is short sighted vision. The long term cost of this is un-trustable packages.

Anything else I consider that a hostile takeover of someone previous work
Fixing 10-year old bugs? That's just ridiculous.

I wasn't referring to what you specifically did for scotty, but making a general comment about the process.

[vincenthz]

@ad-si

(And if you're still reading Vincent: I'm also very grateful for your past work, thank you! Nevertheless, giving someone a gift and then coming years later to take it away or trying to restrict the way it is used, is still an absolute a-hole move.)

nice, name calling ! well done.

After all, all the repositories of each package in question are not:

• still publicly available
• under a BSD3 license

And that people are doing their own derivative packages, for example crypton-* (out of respect for my preferences on the matter, despite the unfortunate extra work it cost them)

But sure, I'm totally "taking it away or restricting the way it is used". In bizarro world.

(All references to his name must be removed to honor the BSD 3-Clause license.)

Maybe you should consult a copyright lawyer instead of peddling disinformation like this. This is not how BSD3 works, and would be a violation of license.

[jmct]

I have a feeling that this conversation is no longer productive.

I think @vincenthz has made his view very clear, and as I understand it, it's ultimately his call to make.

[ad-si]

All packages listed at https://hackage.haskell.org/user/VincentHanquez, have the BSD3 or MIT license. If the relevant repositories do not exist anymore, new ones could be instantiated from the code on Hackage.

But sure, I'm totally "taking it away or restricting the way it is used"

You took away the namespace and now you want to keep it. Even though you have no use for it.

Maybe you should consult a copyright lawyer instead of peddling disinformation like this.
This is not how BSD3 works, and would be a violation of license.

My wording wasn't very clear. I'm talking about listing it as "your package" (which would violate clause 3). Of course, the copyright notices for code authored by you would remain.

[vincenthz]

@ad-si

You took away the namespace and now you want to keep it. Even though you have no use for it.

Develop better tooling, be more creative (new package names). This is how many centralised package repositories work (including my favorite one, rust/cargo/crates.io), for many reasons (including security, supply chain).

Ideally there should not be trustees; and practically there should be, and their actions should be extremely rare, and when action taken should be logged and transparent, not like the permissions system of hackage. They should definitely not be there to reassign packages willy-nilly to anyone that requests using an email.

[ad-si]

@vincenthz

Yeah, I'm not arguing with any of those points in theory.
However, the Haskell ecosystem felt to me more of a group of friends who try to build a nice set of packages. (And hundreds of vacated packages definitely isn't nice.)

But that's maybe just wishful thinking and we should treat it like you said: A group of potentially untrustable strangers who happen to share code. (Especially in light of the xz backdoor.) Sorry for adopting the wrong tone in this discussion, as you seem to play devil's advocate here. I'll fork the packages I need with a new name.

From my side, this issue can be closed.

[jamesdbrock]

My suggestion:

1. Mirror all his repositories to https://github.com/haskell-github-trust

What are your thoughts on this @jamesdbrock?

Hi @ad-si .

Haskell Github Trust is for Other People’s Packages, i.e., for niche packages that no-one will pledge to maintain because they are not “critical infrastructure” and are seldom used. I think some of the packages under discussion fit that description, so yeah.

I recommend doing nothing now, and then if someone needs to update and use one of these abandoned packages, then that person could set up a new forked or copied repo in https://github.com/haskell-github-trust and publish with a new name. That makes it easier for the next person who comes along and wants to update that same package.

[ysangkok]

Closing as the tag has been removed in build-constraints.yaml, so I am not sure there is anything actionable for Stackage to do. Remaining questions seem broader and general, so the discussion could continue on the Hackage issue tracker.

[gbaz]

their actions should be extremely rare, and when action taken should be logged and transparent, not like the permissions system of hackage.

For the record all hackage actions are logged and transparent. admin actions are in the log (https://hackage.haskell.org/admin/log) and trustee actions to update bounds are logged in the individual histories of each package.