Re: [Haskell-cafe] Unmaintained packages and hackage upload rights

31 Jan 2014


      automation ... isn't flexible. the moment theres an automatic path, a lot
of non social engineering approaches to break any hackage trust model


On Fri, Jan 31, 2014 at 12:45 PM, Clark Gaebel  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  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?
...
Problem: no one is really actively working on hackage-server.  Are you
volunteering? :-)
On Friday, January 31, 2014, Clark Gaebel 
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
...
...
On Fri, Jan 31, 2014 at 11:34 AM, Daniil Frumin 
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
...
...
...
is unreachable for a couple of weeks at least
On Fri, Jan 31, 2014 at 1:04 PM, Erik Hesselink 
...
...
wrote:
> On Fri, Jan 31, 2014 at 3:15 AM, Roman Cheplyaka 
...
...
> wrote:
>> * Erik de Castro Lopo  [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
...
...
...
>>> did this, the results could easily be disasterous.
>>
>> Agreed. Maybe we need those disasterous results to realize that
...
...
...
>> 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 also one that is not
warranted
> given the replies in this thread. Let me try to be more
constructive
> instead:
>
> I propose to make the trustees group able to upload any package,
with
> the understanding that they only do so to make packages where the
> maintainer is unreachable compile on more compilers or with more
> versions of dependencies. The newly uploaded version should have a
> public repository of the forked source available and listed in the
> cabal file. The process would then be:
>
> * User fixes a package, emails the maintainer.
> * No response: User emails trustees.
> * Trustees check the above conditions, and upload the new version.
>
> This is more lightweight that the process to take over
On Fri, Jan 31, 2014 at 8:44 PM, Carter Schonwald
 wrote:
maintainer.
maintainer
people
the
maintainership,
...
...
...
> and it can be, because we're not trusting a random user with a
random
> package. Instead, we're only trusting a fixed set of maintainers
and a
> small, publicly visible change. Because of this, the waiting times
for
> non-respo
--
Clark.
Key ID     : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907