<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">The automation could just be "new package version + new maintainer added in 30 days if no one manually stops it".<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">
Takeovers should be easy to stop for both existing library maintainers and any core "trusted" members of the community.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 1:03 PM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div>
<br></div><div>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. <span></span></div>
<div><div><br></div><br><div><div><div class="h5"><br>On Friday, January 31, 2014, Clark Gaebel <<a href="mailto:cgaebel@uwaterloo.ca" target="_blank">cgaebel@uwaterloo.ca</a>> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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.<br>
</div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div>On Fri, Jan 31, 2014 at 12:09 PM, Carter Schonwald <span dir="ltr"><<a>carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Agreed. It should not be automatic. There should be lots of human visible interaction publicly going on. <div>
<div><span></span><br><br>On Friday, January 31, 2014, Daniil Frumin <<a>difrumin@gmail.com</a>> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have a problem with the 4th step. What if maintainer is unreachable,<br>
but the updated version of the package is broken/breaking ever<br>
dependency? What if there are several replacements awaiting?<br>
<br>
I personally think that problem we are facing is not technical, but a<br>
social one. Call me old fashioned, but I prefer trustees to the<br>
automatic mechanism.<br>
<br>
I understand that Roman may have been really irritated by the whole<br>
process - but on the other hand, do we really need/want the process of<br>
overtaking packages to be easy? I strongly align with Gershom's<br>
position. We should make the process more transparent and visible. In<br>
order to put my money where my mouth is, I created a wiki page that<br>
(hopefully) describes the process of taking over a package:<br>
<a href="http://www.haskell.org/haskellwiki/Taking_over_a_package" target="_blank">http://www.haskell.org/haskellwiki/Taking_over_a_package</a><br>
You are strongly encouraged to edit that page and give more details<br>
(especially given my far from perfect English)<br>
<br>
Maybe it is a good idea to have links to that wiki article on every<br>
package page on Hackage?<br>
<br>
On Fri, Jan 31, 2014 at 8:44 PM, Carter Schonwald<br>
<<a>carter.schonwald@gmail.com</a>> wrote:<br>
> Problem: no one is really actively working on hackage-server. Are you<br>
> volunteering? :-)<br>
><br>
><br>
> On Friday, January 31, 2014, Clark Gaebel <<a>cgaebel@uwaterloo.ca</a>> wrote:<br>
>><br>
>> We could actually partially automate this:<br>
>><br>
>> 1) Package maintainership switch is submitted online, with a new<br>
>> replacement package, and perhaps a message.<br>
>> 2) An email is sent to the maintainer with a link to either:<br>
>> - delete the replacement package<br>
>> - allow one-time upload<br>
>> - permanently add the uploader as a maintainer<br>
>> - permanently switch maintaners to the uploader<br>
>> 3) While the package is in this limbo state waiting for a response from<br>
>> the maintainer, put a link to the package at the bottom of the hackage page<br>
>> in a new "suggested replacements" section. In this section, each candidate<br>
>> replacement package is listed, along with its message and how long it's been<br>
>> waiting.<br>
>> 4) After a bikeshed-long amount of time with no response from the<br>
>> maintainer (I'll suggest 1 month), the package is automatically updated to<br>
>> the suggested version and the package uploader is added as a maintainer.<br>
>><br>
>><br>
>> On Fri, Jan 31, 2014 at 11:34 AM, Daniil Frumin <<a>difrumin@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> I think the proposed approach is only reasonable. However, I would<br>
>>> like to stress that in any case it would be better to make sure that<br>
>>> we give the maintainer enough time to respond, e.g.: if the maintainer<br>
>>> is unreachable for a couple of weeks at least<br>
>>><br>
>>> On Fri, Jan 31, 2014 at 1:04 PM, Erik Hesselink <<a>hesselink@gmail.com</a>><br>
>>> wrote:<br>
>>> > On Fri, Jan 31, 2014 at 3:15 AM, Roman Cheplyaka <<a>roma@ro-che.info</a>><br>
>>> > wrote:<br>
>>> >> * Erik de Castro Lopo <<a>mle+hs@mega-nerd.com</a>> [2014-01-31<br>
>>> >> 09:22:36+1100]<br>
>>> >>> I really can understand why you did this; I am frustrated by some of<br>
>>> >>> the same issues. However, I think if any significant number of people<br>
>>> >>> did this, the results could easily be disasterous.<br>
>>> >><br>
>>> >> Agreed. Maybe we need those disasterous results to realize that the<br>
>>> >> current process is bad and come up with a better one. Or maybe it's<br>
>>> >> just<br>
>>> >> me, and everyone else is happy (enough) with the process, so nothing<br>
>>> >> will happen.<br>
>>> ><br>
>>> > That's a rather fatalist attitude, and als</blockquote></div></div></blockquote></div></div></div>-- <br><div class="im"><div dir="ltr">Clark.<br><br><span style="font-family:courier new,monospace"><span style="color:rgb(153,153,153)"><font size="1">Key ID : 0x78099922<br>
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907</font></span></span></div>
</div></div>
</blockquote></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Clark.<br><br><span style="font-family:courier new,monospace"><span style="color:rgb(153,153,153)"><font size="1">Key ID : 0x78099922<br>Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907</font></span></span></div>
</div>