Package spam :-)

[Chris Kuklewicz]

Gwern Branwen wrote:
> 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>.

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