hackage, package list, trac, some suggestions/questions

[Claus Reinke]

> Yes.  In the meantime, feel free to file feature requests as guest.

done. though i notice that uninstall (#106, now #234), which i
considered essential, is still lingering there a year later..

> No, but here are some rough figures on failures (for the latest version
> of each package):

thanks, that was interesting. btw, i fully expect such statistics
to reflect infrastructure issues at least as much as package author
issues, including overlap between the two where authors try to
cope with infrastructure hickups.

so, having such statistics in generated in a prominent place
would both

- alert package authors and users
- alert cabal/hackage/haddock/ghc/.. maintainers

>> 5. generally, i've always thought that hackage works the
>>     wrong way round; instead of yet another push-based
>>     place for people to put and forget copies of things, it
>>     should work as a pull-based cache:
>
> It's a place for maintainers to put their releases (there may not even
> be a another place to pull from).  It seems to me entirely appropriate
> that maintainers should assume responsibility for that.

i had forgotten that hackage was the first to provide a space
for authors without webspace access. but these days, there is
code.haskell.org, and that seems to be a much better home
for any package than a tarball described by a .cabal file.

why should all releases be centralised? why should package
authors have to remember to think of copies on hackage?
and why should hackage tarballs be the only release venue??

authors/maintainers should assume responsibility for coding,
registering packages with hackage, and indicating when a
package is in a release state, so that hackage and alternative
clients can fetch updated packages and do their thing.

but if no authors chime in, there's probably no case yet
against this "hackage owns everything" approach..

>>     - the maintainer email on each hackage package page
>>         ought to be
>>         (a) protected, not plain text
>>         (b) annotated with last successful contact date
>
> The email address on the package is merely copied from the .cabal file,
> which is also publically available.  If a maintainer wants to hide this,
> they need to obfuscate it in the .cabal file.

good point. as .cabal files are served as text, they might be
scanned as well. still, i'd think that hackage should do as good
mailing list archives do: obfuscate email addresses to make
harvesting more difficult, without users having to obfuscate
things by hand.

if someone figures out how to install the package descriptions
on their own machine for harvesting, there isn't much to be done
about that, just as with harvesters registering on mailing lists.
but one shouldn't make it too easy..

claus