On 2008.06.20 11:49:17 -0700, Don Stewart
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