[Hackage] #667: Improve tools to manage ad-hoc package releases

[Hackage]

#667: Improve tools to manage ad-hoc package releases
------------------------------+---------------------------------------------
  Reporter:  duncan           |        Owner:     
      Type:  enhancement      |       Status:  new
  Priority:  normal           |    Milestone:     
 Component:  miscellaneous    |      Version:     
  Severity:  normal           |     Keywords:     
Difficulty:  project(> week)  |   Ghcversion:     
  Platform:                   |  
------------------------------+---------------------------------------------
 Hackage is suited for major software releases by package maintainers. It
 is not suited to distributing betas, daily snapshots or random forks, or
 patches of existing releases.

 For example a user may have some patch or bugfix for a package that they
 need. It takes time for maintainers to review and integrate these.
 Sometimes maintainers have little time, or they disagree with a patch
 approach or quality.

 It is right that maintainers have control over what is released on
 hackage. However there is a need for decentralised, ad-hoc and short term
 releases. We do not want to encourage the pollution of the package
 namespace with lots of short-term forks.

 One solution is to let users post package forks on their own webspace. We
 would want to extend cabal so that people can run:

 {{{
 cabal install http://code.haskell.org/~user/foo/foo-fork-to-fix-
 blah-1.0.1.tar.gz
 }}}

 This makes it very decentralised. We may want to add some feature to
 hackage package pages to link to third-party forks.

 In addition to hosting and installing single packages it would be useful
 to be able to publish package collections. Of course this is exactly what
 a hackage archive is. We should provide easy tools to make and manage
 hackage archives that can be hosted on dumb http file servers.

 Going one step further, the hackage index format should be extended to
 make it more RESTful by including links to tarballs rather than just
 assuming that tarballs are found relative to the index file using some
 fixed layout. This would allow people to publish indexes that span
 multiple servers. This gets close to the concept of a package "search
 path" promoted by the searchpath project (http://searchpath.org/).

 Additonally, an index should allow us to point to source control repos
 rather than just to release tarballs. This kind of index would be useful
 for nighly builds.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/667>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects