Re: [Haskell-cafe] Unmaintained packages and hackage upload rights

Yes. It should be perhaps even require two trustees / admins / whatever if we are actually serious about making things proof against social engineering. Or something. Nb: hackage admins have the super powers. I'm just a trustee. Which just means I can delete bad doc builds to force em to rebuild. On Friday, January 31, 2014, Daniil Frumin wrote:

On Fri, Jan 31, 2014 at 10:05 PM, Clark Gaebel javascript:;> wrote:

...

The automation could just be "new package version + new maintainer added in 30 days if no one manually stops it".

Takeovers should be easy to stop for both existing library maintainers and any core "trusted" members of the community.

Rights, that's why we have hackage trustees. They can easily overwrite/update any package (if I understand the process correctly). Complete takeover of a package should *not* be easy, we must give the maintainers a good sense of ownership.

...

On Fri, Jan 31, 2014 at 1:03 PM, Carter Schonwald wrote:

...

How would the automation work? Automation in trust models is very very fiddly to get right. Like really hard. Like a research problem with reality consequences hard.

At the end of the day, it's a people problem. The best we can do is

come

...

...

up with a very audit able, publicly visible process that makes everything easy for 3rd partiies to audit. And prevents / catches any abuse before it does something like break vector or ByteString.

On Friday, January 31, 2014, Clark Gaebel wrote:

...

There could be an email made to the relevant mailing lists during a takeover attempt. That way we get human visibility, human "veto power"

if

...

the email goes to libraries@, and automation when there are no objections.

On Fri, Jan 31, 2014 at 12:09 PM, Carter Schonwald wrote:

Agreed. It should not be automatic. There should be lots of human visible interaction publicly going on.

On Friday, January 31, 2014, Daniil Frumin wrote:

I have a problem with the 4th step. What if maintainer is unreachable, but the updated version of the package is broken/breaking ever dependency? What if there are several replacements awaiting?

I personally think that problem we are facing is not technical, but a social one. Call me old fashioned, but I prefer trustees to the automatic mechanism.

I understand that Roman may have been really irritated by the whole process - but on the other hand, do we really need/want the process of overtaking packages to be easy? I strongly align with Gershom's position. We should make the process more transparent and visible. In order to put my money where my mouth is, I created a wiki page that (hopefully) describes the process of taking over a package: http://www.haskell.org/haskellwiki/Taking_over_a_package You are strongly encouraged to edit that page and give more details (especially given my far from perfect English)

Maybe it is a good idea to have links to that wiki article on every package page on Hackage?

On Fri, Jan 31, 2014 at 8:44 PM, Carter Schonwald wrote:

...

Problem: no one is really actively working on hackage-server. Are you volunteering? :-)

On Friday, January 31, 2014, Clark Gaebel wrote:

...

We could actually partially automate this:

1) Package maintainership switch is submitted online, with a new replacement package, and perhaps a message. 2) An email is sent to the maintainer with a link to either: - delete the replacement package - allow one-time upload - permanently add the uploader as a maintainer - permanently switch maintaners to the uploader 3) While the package is in this limbo state waiting for a response from the maintainer, put a link to the package at the bottom of the

hackage

...

pag-- Sincerely yours, -- Daniil