[Haskell-cafe] Unmaintained packages and hackage upload rights

[Clark Gaebel]

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.


On Fri, Jan 31, 2014 at 1:03 PM, Carter Schonwald <
carter.schonwald at gmail.com> 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 <cgaebel at uwaterloo.ca> 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 <
>> carter.schonwald at gmail.com> 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 <difrumin at gmail.com> 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
>> <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 als
>>
>> --
>> Clark.
>>
>> Key ID     : 0x78099922
>> Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
>>
>


-- 
Clark.

Key ID     : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140131/de91f4b5/attachment.html>