agreeing a policy for maintainers and hackageDB

[Ross Paterson]

On Tue, Jun 24, 2008 at 11:24:08AM +0200, Henning Thielemann wrote:
>  As Chris Kuklewicz explains in the other thread "package spam", an  
> unmaintained package is often not generated by someone who uploads a new  
> version where only the Cabal field Maintainer is removed or changed to 
> the empty string. Actually a package most oftenly becomes unmaintained by 
> being not updated for a long time. Thus I think the time of the last  
> release, the highest compiler version it is tested with and so on may be  
> sorting criteria for finding out the most up-to-date packages.
>  If nevertheless an unmaintained flag should be managed, this should be  
> part of HackageDB (like user reviews), not part of Cabal. But then I  
> wonder who shall decide whether a package is maintained or not. Sometimes 
> users are afraid that a package is unmaintained because there was no new  
> release for half a year, although patches are constantly committed to a  
> darcs repository.

All that other information will be useful in building the complete
picture.  Breaking changes to the core libraries are also helpful in
weeding out unmaintained packages :-).  The maintainer field is an
additional piece of information, describing the situation at the time
of the release.  There are two kinds of uploads that are happening now,
but are difficult to distinguish from normal releases:

* museum pieces: a package that hasn't been touched for years is
  updated to use Cabal and the latest libraries and uploaded.
* can't wait for the maintainer: someone takes the current state of
  the darcs repository, possibly makes a few fixes, and uploads that.

If these are to be allowed, users (and future filtering schemes) really
need to be able to identify them.