[Haskell-cafe] Unmaintained packages and hackage upload rights
carter.schonwald at gmail.com
Fri Jan 31 18:03:16 UTC 2014
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:
> 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
> >> in a new "suggested replacements" section. In this section, each
> >> replacement package is listed, along with its message and how long it's
> >> 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
> >> 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
> >>> >>> the same issues. However, I think if any significant number of
> >>> >>> 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
> Key ID : 0x78099922
> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe