Package spam :-)

[Gwern Branwen]

On 2008.06.20 11:49:17 -0700, Don Stewart <dons at galois.com> scribbled 0.9K characters:
> ross:
> > On Fri, Jun 20, 2008 at 10:01:29AM +0200, Jean-Philippe Bernardy wrote:
> > > We already discussed this before, but that repository can be
> > > considered orphaned. I'll give pointers to anybody interested in
> > > adopting it.
> >
> > Thanks for the clarification, Jean-Philippe.
> >
> > On the broader issue, personally I'd prefer not to have non-maintained
> > packages on hackageDB (because their presence lowers people's expectations
> > of the whole collection) but others disagree on that point.  If we must
> > have them, they ought not to be marked as maintained.  It's not fair on
> > users, or on the person named as maintainer.
>
> Perhaps if the .cabal files for orphaned packages could be
> marked as, say:
>
>     maintainer: unmaintained
>
> or
>
>     maintainer: orphaned
>
> This might alleviate some problems (a future hackage could filter
> unmaintained packages).
>
> Gwern, would that work for you, for these library salvaging efforts?
>
> -- Don

This *would* work for me; however, there is a reason I haven't done this or something like it before (and instead simply omitted the maintainer: field whenever I thought something was unmaintained).

Fundamentally, I feel that putting something like into the free-form text field is kind of abusing it, that there should be some more structured way. As you've already pointed out, when a package is unmaintained, what is the canonical machine-readable way of saying so?

We have such ways of specifying dependencies and tested-status, which is good for cabal-install. But what about maintainedness? Is it "unmaintained"? "unsupported"? "Unsupported"? "orphaned"? "Orphaned"? I can tell you just from past experience with the stability: field* that people will use all those and more if we don't give them a clear and unambiguous restriction on what can be put in - and then how will Hackage programmatically filter out unmaintained stuff?

The status quo of not listing maintainer at least is programmatic - if there's a maintainer field, it's maintained by the person listed; if not, not. We could formalize this a little bit. For example, the cabal tools see an omitted maintainer field as a problem, not as a valid choice, and Hackage does nothing based on an omission. These are relatively small tweaks, though. What's the alternative? some sort of data Maintainer = None | Maintained String? But how could you then make maintainer: backwards compatible...? Add an entirely new field? (maintained: True) But then we wouldn't see it in sufficiently wide-spread use to be usable for years and years.

* Which needs to be fixed for all the reasons I've listed here for maintainer:; see <http://hackage.haskell.org/trac/hackage/ticket/265>.

--
gwern
DI VIP J2 AFSPC detection STEEPLEBUSH DES chosen DDR&E RUOP
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20080622/ba9abd05/attachment.bin