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@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@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@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@gmail.com> wrote:
Problem: no one is really actively working on hackage-server. Are you volunteering? :-)
On Friday, January 31, 2014, Clark Gaebel <cgaebel@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@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@gmail.com> wrote:
On Fri, Jan 31, 2014 at 3:15 AM, Roman Cheplyaka <roma@ro-che.info> wrote:
* Erik de Castro Lopo <mle+hs@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