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

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 page in a new "suggested replacements" section. In this section, each candidate replacement package is listed, along with its message and how long it's been waiting. 4) After a bikeshed-long amount of time with no response from the maintainer (I'll suggest 1 month), the package is automatically updated to the suggested version and the package uploader is added as a maintainer.

On Fri, Jan 31, 2014 at 11:34 AM, Daniil Frumin wrote:

...

I think the proposed approach is only reasonable. However, I would like to stress that in any case it would be better to make sure that we give the maintainer enough time to respond, e.g.: if the maintainer is unreachable for a couple of weeks at least

On Fri, Jan 31, 2014 at 1:04 PM, Erik Hesselink wrote:

...

On Fri, Jan 31, 2014 at 3:15 AM, Roman Cheplyaka wrote:

...

* Erik de Castro Lopo [2014-01-31 09:22:36+1100]

...

I really can understand why you did this; I am frustrated by some of the same issues. However, I think if any significant number of people did this, the results could easily be disasterous.

Agreed. Maybe we need those disasterous results to realize that the current process is bad and come up with a better one. Or maybe it's just me, and everyone else is happy (enough) with the process, so nothing will happen.

That's a rather fatalist attitude, and also one that is not warranted given the replies in this thread. Let me try to be more constructive instead:

I propose to make the trustees group able to upload any package, with the understanding that they only do so to make packages where the maintainer is unreachable compile on more compilers or with more versions of dependencies. The newly uploaded version should have a public repository of the forked source available and listed in the cabal file. The process would then be:

* User fixes a package, emails the maintainer. * No response: User emails trustees. * Trustees check the above conditions, and upload the new version.

This is more lightweight that the process to take over maintainership, and it can be, because we're not trusting a random user with a random package. Instead, we're only trusting a fixed set of maintainers and a small, publicly visible change. Because of this, the waiting times for non-responsiveness can probably also be shorter than in the maintainer take-over process.

Would this alleviate the frustration, while at the same time maintaining enough security and sense of package ownership?

Regards,

Erik _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Sincerely yours, -- Daniil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Clark.

Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907

-- Sincerely yours, -- Daniil