[Haskell-cafe] Unmaintained packages and hackage upload rights

[Daniil Frumin]

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
<carter.schonwald at gmail.com> wrote:
> Problem: no one is really actively working on hackage-server.  Are you
> volunteering? :-)
>
>
> On Friday, January 31, 2014, Clark Gaebel <cgaebel at uwaterloo.ca> 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 <difrumin at gmail.com>
>> 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 <hesselink at gmail.com>
>>> wrote:
>>> > On Fri, Jan 31, 2014 at 3:15 AM, Roman Cheplyaka <roma at ro-che.info>
>>> > wrote:
>>> >> * Erik de Castro Lopo <mle+hs at mega-nerd.com> [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 at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>>
>>> --
>>> Sincerely yours,
>>> -- Daniil
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at 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