Policy for taking over a package on Hackage

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Wed May 25 15:37:27 CEST 2011

On 25 May 2011 23:23, Otakar Smrz <otakar.smrz at cmu.edu> wrote:
> I took over the maintenance of wl-pprint since Stefan suggested it
> himself. I needed to include OverlappingInstances, because that was
> required to make better use of the library (there is a difference having
> this flag there, which is consistent with the GHC documentation on
> OverlappingInstances).
> I was not aware that I have to announce this. I thought people would
> know from checking Hackage that there is this maintainer change and a
> new version of the package. Sorry.

The whole email wasn't aimed at you specifically: it's just that with
Hackage's current infrastructure it's quite easy for someone to "take
over" a package and possibly do something malicious with it (so the
next time they do a "cabal update" they could inadvertently get a
package with said malicious code).  Especially if there's no
announcement of the change, it's difficult to know that someone has
indeed taken over maintaining a library, and thus they could keep
addressing queries (or throwing blame) at someone "known" to be the
maintainer of a package even if they didn't upload the latest version.

> Since I do not have any plans to develop wl-pprint further, I have no
> problem giving the maintainer's role to you or anyone interested.

OK; if no-one has any objections I'll do so and make it class-based as
I've discussed in the threads on -cafe (after considering name clashes
with Applicative, etc.).

> PS: For the point 4 of your suggested rules, I think uploading a new
> version of a package if only the maintainer changes, rather than when
> there is some actual change to the library, is inappropriate. You could
> easily get package versions increasing without any code/documentation
> being actually improved or extended.

By "point release" I meant incrementing the fourth digit, which is
usually used to refer to bug-fixes.  My aim with this was that the new
maintainer could immediately "make their mark" so that people looking
for a project's maintainer on the hackage page knew who to contact
(rather than waiting for them to finish of their new & improved

Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com

More information about the Libraries mailing list