Policy for taking over a package on Hackage

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Wed May 25 14:01:40 CEST 2011

With my wl-pprint-text package, Jason Dagit suggested to me on
#haskell that it would make sense to make such a pretty-printer be
class-based so that the same API could be used for String, ByteString,
Text, etc.

I was thinking of doing so, and in such a case it would probably make
the most amount of sense to actually then migrate the package back to
the wl-pprint package instead of defining yet another package (and
corresponding namespace), especially as I recalled from when I first
started hacking on wl-pprint-text at the beginning of the year that
the last (and only) upload had been in 2007 by Stefan O'Rear.  As
such, I was going to email Stefan and asked if he minded if I took
over maintaining wl-pprint.

However, when I went to the package page to get his email address, I
saw that Otakar Smrz had released a new version about a month ago, and
that the only change in the package that I could find was that
OverlappingInstances was added to the .cabal file (which I thought
wouldn't make a difference anyway).

Now, for all I know, Otakar had already asked Stefan for permission to
take over the package (I've CC'd both of them just in case).  But even
if he didn't, we don't officially have any policies set in place -
especially ones that are enforced by requiring registering a package
and specifying a maintainer - to indicate that such a thing shouldn't
be done.  Furthermore, if packages aren't announced then there's no
way for people to know that there _is_ a new maintainer.

This situation also arose last year [1], and was resolved by someone
volunteering to take over a package.  However, no formal policy was
set in place (despite one being proposed).  As such, I'd like to
propose the following policy based upon the one Ben Millwood proposed
last time on how to take over maintainership of a package that hasn't
been updated for a while:

1. Email the current listed maintainer and wait a specified period of
time (e.g. 2 weeks).
2. Email haskell-cafe, explicitly CC'ing maintainers of reverse
dependencies (at least those that are themselves still active) and
request permission to take over.  This way, people who know the
maintainer might point out that they are indeed still around, etc.
3. If no-one objects within another two weeks, announce that you have
taken over maintainership with a new email (in case people are
ignoring the previous thread).
4. Upload a point release of the previous package (assuming it follows
the PVP) with yourself as the new maintainer (just to get it out
there).  Alternatively, if you already have a new version ready to go
then upload that.

Of course, having a policy like this is useless if there is no way to
enforce it.  Is it possible at the very least to have Hackage note
when a new version of a package is uploaded with a new maintainer and
require it to be approved by someone before it iis officially
available?  I think this would be the bare minimum (as opposed to
requiring explicit logins on a per-package basis or some kind of
signing) required for this kind of scheme to be effective.

[1]: http://www.haskell.org/pipermail/haskell-cafe/2010-August/081353.html
and http://www.haskell.org/pipermail/haskell-cafe/2010-August/082319.html

Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com

More information about the Libraries mailing list