On Thu, Apr 8, 2010 at 6:38 PM, Matthew Gruen <[email protected]> wrote: > On Wed, Apr 7, 2010 at 9:02 AM, Maciej Piechotka <[email protected]> > wrote: >> I guess 'works also with B in version X.Y.Z' is also. Most of the above >> changes should not be IMHO in cabal (sorry for answering PS here). >> Especially 'not maintained anymore' and 'does not build on recent >> GHC' ;) >> >> <quote> >> >> As we are with Haddock - 'rebuild' button if package failed to build? >> For some reasons some packages fails to build on hackage (as yi). I'm >> not sure if it will work however. At least uploading docs should be >> possible. >> >> Regards >> > > More flexibility for building times is a good thing, but people > shouldn't able to DDOS the server by compiling, since it's a rather > CPU-intensive thing, or by building documentation. Now, it looks like > yi fails because data-accessor-template fails because of TH versioning > issues (seemingly). I like the ideas of docs you can upload to get > around these sorts of problems, and the ability to add links to other > docs and tutorials. People could edit Hackage to reference > haskellwiki, community.haskell.org, and other sites/services. > > I see what you mean about the changes being segregated from cabal, and > I agree here. There's a set of information that's useful both for the > web interface and for cabal-install (which is what Hackage currently > displays, although perhaps not enough of it), and that should stay in > the .cabal files. But, other information that's user-editable on > Hackage is a plus. >
One thing in the branch over in http://code.haskell.org/hackage-server is the ability for package maintainers to upload documentation to the server. This way we're not tying the ability of the server doing a build-check to the ability to host documentation for a package. Antoine _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
