non-maintainer uploads to hackageDB

Bjorn Bringert bjorn at
Wed Mar 12 09:02:38 EDT 2008

On Mon, Feb 25, 2008 at 1:35 AM, Ross Paterson <ross at> wrote:
> I think we need, perhaps not a policy, but some agreed etiquette regarding
>  uploads to hackageDB.  (Please hold off on the technical suggestions
>  until we've decided what behaviour we want.)
>  Personally, I'd rather have all maintainers doing their own uploads.
>  As I user, I'd like to know that someone takes responsibility for the
>  whole of a package I download, including the packaging, and will be
>  available for bug fixes and enhancements (such as making it work with
>  the next GHC release).
>  As this is free software, there's nothing to stop someone forking a
>  package and maintaining their own version.  Then as a user I'll need
>  to choose between the two, but I'll still be looking for a maintainer
>  of the whole package.  It might be fair to ask that someone creating a
>  fork change the name of the package in some way, to avoid confusion
>  (and eating up the original maintainer's version numbers).
>  This is a different situation from Linux or BSD distributions, where
>  primary releases are repackaged to conform with native conventions.
>  HackageDB is an upstream site, where people can make their own releases,
>  using a common package format (Cabal).  (Similarly I don't think we
>  need the pristine+patches setup used by those distributions: maintainers
>  should just take care of the pristine.)

I'm sorry I missed this when it was first posted. My suggested policy
is that a non-maintainer who wants to upload a package should ask the
maintainer first, and allow for a reasonable response time before
uploading a package.

If a package is uploaded against the maintainer's wishes, the
maintainer should be allowed to request to have it removed. If the
uploader is eager to have the package released, he is welcome to help
fix the issues that the maintainer wants resolved before releasing. If
the uploader still insists on uploading, he should fork the package.
Hopefully this should be very rare.


More information about the Libraries mailing list