On 2014-05-11 at 01:41:56 +0200, Bardur Arantsson wrote: [...]
As usual Debian has encountered and solved all these problems before. Sounds eminently sensible, so +1 to such a policy change.
There's IMHO an important difference between Hackage and how Debian operates: Debian repackages upstream packages into a unified package repository and also takes care of applying add-on patches to fix bugs and/or integrate better with other repackaged Debian packages in the current Debian release. There is not much need for the upstream maintainer to cooperate. Hackage, on the other hand, is both, a package repository *and* a place where upstream authors publish their packages[1]. So on Hackage there needs to active cooperation between package authors and Hackage maintainers. For instance, package authors may not be bothered into supporting 3-year old GHC setups which, OTOH, Hackage trustee/maintainers might be willing to put in effort for, but there still needs to be an agreement where the Hackage trustee authority ends, and how absolute the package's authors wishes are in the context of some form of Utilitaranism maximizing the total benefit for everyone using Hackage. [1]: IMHO, publishing a package on Hackage also comes with a reasonable level of responsibility for package authors, as Hackage should be about keeping packages in a working state. It'd be a pity for Hackage to degenerate into a pastebin-like dumping space for bitrotting code where you have filter out all the noise to find out which packages are still maintained and working. (Maybe the HP as the authority to pick go-to implementations may help here in the future, but I'm afraid we still have too many places with competing designs (with different trade-offs) for the same task, and I see the HP library addition process being blocked by that for the next few years -- but that's a worth a whole thread/discussion of its own)