Re: Package spam :-)

Gwern Branwen wrote:

On 2008.06.20 11:49:17 -0700, Don Stewart 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. Here is another view: The use of a cabal field to indicate orphan seems wrong to me. The maintainer field in the cabal file currently indicates who was responsible for and interested in such things as bug reports and patches at the time of the release of that version of that package. The orphan state is associated with the package's basename, not any given version of the package. I think of "orphan" vs "non-orphan" as associated with promised future versions of the package. In an extreme case, the orphan status could change several times in a day. Things at this level of abstraction should be tracked by a future version of hackage. What expectations should a user have when a package: has an Author? has a Maintainer? is an orphan? is supported? is unsupported? -- Chris