agreeing a policy for maintainers and hackageDB

Gwern Branwen gwern0 at
Tue Jul 1 13:57:15 EDT 2008

On 2008.06.24 18:29:03 +0400, Bulat Ziganshin <bulat.ziganshin at> scribbled 1.3K characters:
> Hello Isaac,
> Tuesday, June 24, 2008, 5:42:48 PM, you wrote:
> >> Do we want to permit unsupported forks? I am not convinced they are a good idea.
> imho, we are going too deep into this topic. there are even
> proposals to force developers to answer emails :)
> We have AUTHORS field which should list everyone contributed to the
> package just for copyrighting purposes. and we have MAINTAINER field
> for the person(s) which are ready to accept patches, feature requests
> and ask dumb user questions. that's all
> if one uploading package know person which maintains package in
> above-mentioned meaning, he declare that person in .cabal file. if
> noone is expected to support the package, it may be mentioned too
> non-maintainers shouldn't upload new versions of maintained packages
> without written ;) maintainer permission. well, as far as maintainer
> answers their letters

And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal & Hackage and would never give permission? Does the maintainer have eternal veto power over uploads?

> it should be ok to fork existing maintained library Foo as SuperFoo
> and leave it unmaintained - sometimes we write just for fun (things
> useful for other haskellers)
> i think that Hackage should be database of ALL packages, and other
> ways should be used to distinguish between better and worse ones
> (such as download count, maintainer field, version, last update time...)
> --
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin at

As I've indicated elsewhere, I'm a strong supporter of this view. It is better from a long-term view: personal websites are hard to find, they are evanescent, and the opposite view induces great friction and transaction costs. Filtering out packages is easy; but there is no library to undelete information, no way to recover packages purposefully deleted or discouraged from ever being on Hackage.

MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :

More information about the Libraries mailing list