Any volunteers? :-)

On Friday, January 31, 2014, Clark Gaebel <cgaebel@uwaterloo.ca> wrote:

Fair point.

I wish I could, but the soonest I could start checking it out is in ~3 months.

- Clark

On Fri, Jan 31, 2014 at 11:44 AM, 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 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 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-responsiveness can probably also be shorter than in the maintainer
> take-over process.
>
> Would this allevi