[Haskell-cafe] Unmaintained packages and hackage upload rights

[Carter Schonwald]

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 <cgaebel at 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 at gmail.com> wrote:
>
> Problem: no one is really actively working on hackage-server.  Are you
> volunteering? :-)
>
>
> On Friday, January 31, 2014, Clark Gaebel <cgaebel at 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 at 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 at gmail.com>
> wrote:
> > On Fri, Jan 31, 2014 at 3:15 AM, Roman Cheplyaka <roma at ro-che.info>
> wrote:
> >> * Erik de Castro Lopo <mle+hs at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140131/dba676b1/attachment.html>