Nb: hackage admins have the super powers. I'm just a trustee. Which just means I can delete bad doc builds to force em to rebuild.
On Friday, January 31, 2014, Daniil Frumin <
difrumin@gmail.com> wrote:
On Fri, Jan 31, 2014 at 10:05 PM, Clark Gaebel <cgaebel@uwaterloo.ca> wrote:
> 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.
Rights, that's why we have hackage trustees. They can easily
overwrite/update any package (if I understand the process correctly).
Complete takeover of a package should *not* be easy, we must give the
maintainers a good sense of ownership.
>
>
> On Fri, Jan 31, 2014 at 1:03 PM, Carter Schonwald
> <carter.schonwald@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@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
>>> >> pag--
Sincerely yours,
-- Daniil