[Haskell-cafe] possible bug in latest hackage Elf (Elf-0.27)

[Anthony Cowley]

> On May 15, 2014, at 5:18 AM, Sven Panne <svenpanne at gmail.com> wrote:
> 
> 2014-05-15 9:30 GMT+02:00 Roman Cheplyaka <roma at ro-che.info>:
>> If there's no response, then you have two choices:
> 
> Actually three: Fix things locally until the "official" package is fixed.
> 
>> * request package maintainership, which will take several weeks
> 
> I really hope that this will take months, not weeks, see the other discussion
> 
>> * fork the package (i.e. upload your patched version to hackage under a
>>  different name)
> 
> This proposal worries me quite a bit, because if everybody follows
> that advice, it will turn Hackage into a chaotic collection of
> packages with various degrees of being fixed/maintained/etc. Imagine a
> package 'foo', which needs a fix, and several pepole think it's a good
> idea to fork and fix the issue at hand. Now we have 'foo', 'foo-XY',
> 'foo-my-cool-acronym', ... Of course people normally have no incentive
> to really take over maintainership for 'foo', they just want a working
> 'foo' right now for their own project. Later the real maintainer
> re-appears after vacation/sabbatical/whatever, fixes 'foo', and
> continues to work on it, adding new features. Now somebody new comes
> to Hackage to see if there is already a package for some use case, and
> finds 'foo', 'foo-XY', 'foo-my-cool-acronym', ... Then it takes some
> non-trivial detective work to find out which packages are actually
> dead (again) and which is the real one. => Chaos IMHO.
> 
> In a nutshell: If you are really in a hurry, fix things locally.
> Hackage is not the place to fork like hell.

But we do need a mechanism to deal with name expansion. Many of us would prefer to make package name usurpation a slow, forgiving process, but we should then contend with the fact that such a policy adds to the rate at which new packages are uploaded. If search results display, and can be sorted by, information regarding number of downloads, downloads in the last year, and latest upload date, we will be suggesting which of these variations a new user should consider. Pair this with a slow name reclaiming process, and we won't have to always consider perpetuity when coming up with package names. 

Preferably packages would also come with some sort of UUID independent of a user-friendly name so that they could exist on hackage without blocking new uses of a good name if one development has permanently stalled.

Anthony