
Ill check in 3 months then :-)
Everyone here has a lot of different ideas bout how to improve hackage
(some of which may admittedly be at odds with others). But unless there's
some associated commitment to work on hackage server by some volunteers who
have the time and care to help out, not is going to happen.
Any volunteers? :-)
On Friday, January 31, 2014, Clark Gaebel
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
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
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
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 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