What could be done is letting the community rate the quality of the modules for each platform? Maybe with user comments? Like amazon.com (so we hackazon.org ;-) And using lambdas instead of stars for giving the rating :) On Tue, Jan 13, 2009 at 6:13 PM, Don Stewart wrote:

Well, the number one thing is to use Cabal and the cabal-install tool. That is the simplest way to avoid headaches.

Regarding libraries in general, the platform project is underway, aiming to bless a set of stable, "batteries included" packages, saving duplicated work determining which, say, json library to use.

-- Don

...

I agree completely. There is not nearly enough documentation on packaging in haskell and too many hackage packages are broken or do not install. I know several people are working on improving this but they seem do be doing so rather quietly. Could someone briefly outline what improvements are planned and what stage the current work is at? I remember seeing some demos at anglohaskell during the summer but nothing since.

Jamie

On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul wrote:

...

Hi,

I've seen many times the monad topic coming around on the cafe and

...

...

tutorials on monads have been published. However, as a complete Haskell newbie coming from OOP, I felt monads were not particularly difficult to grasp, and very exciting to work with.

During my experiments with Haskell so far, the main problems I kept bumping into were not related to the language but to its libraries: their compilation and installation. Unfortunately, this topic has not received nearly as much attention. I was unable to find a comprehensive tutorial on how to deal with the variety of problems I get when trying to install Hackage packages. This turned out to be (and still is) THE main source of wasted time and headaches. And worse, unlike type problems, these are not interesting ones to solve.

Thus, as a beginner, the package management is what is really getting in the way of switching to Haskell--not the language. Even books like Real World Haskell (otherwise excellent) ignore entirely the topic. Cabal and Cabal-install are clearly wonderful applications that make installing most packages very straightforward. Unfortunately, whenever this "standard" method for package installation fails (or when it is not available as with, e.g., gtk2hs), I find myself in complete disarray.

Below are some of the questions and issues I faced regarding package management:

- For a number of packages, cabal-install gets stuck and has to be killed. I assume this is due to some difficulties in solving the dependencies and it is fine, not all can be automated and cabal-install is not responsible for poor packages. But the question then becomes what to do from there? Is

...

...

some method to solve dependencies? How should we proceed to "debug" a package installation? How do gurus deal with that? (maybe some less known command line arguments? Or ways to figure out the problem and work out its solution (cabal-install is silent in such case)? In particular, how to know why did cabal get stuck in the first place?

- Some packages on Hackage are reported as not building successfully with GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) and the later might depend on the former...What is one supposed to do in such case? For example, is it an appropriate way to proceed to compile a package with one version of GHC and then use the compiled package with another version of GHC? Is it safe? What could possibly go wrong? If it is the right way to go, how should we setup the two GHC versions? For instance, should we have a shared package configuration file and choose through

...

...

path which GHC is used or is there nicer way to set this up?

- Taking for example the "encoding" package on Hackage. Last time I

...

...

the log was saying it fails to build on GHC 6.10, however, looking inside this Hackage log, I could see a successful compilation using "preferred versions". So it looks as if the thing can be compiled somehow. What should one do with this information? If cabal manages to compile it using this method on Hackage, then isn't cabal install just doing it on my disk? Is it possible through some command line? Is it possible manually (without cabal-install) and, if so, how? (I tried to copy-past the build instruction as it appeared on the log...that somehow compiled, but then, I failed to figure out how to install...)

- I'm primarily a windows user and lots of my initial struggles

...

...

came from that. After many difficulties, I figured out that installing MinGW and MSys was *THE* way to get a bit more of the things working. First, a lot of time would be saved by just saying clearly on the GHC download page

...

...

MinGW and MSys are mandatory installation (or even package that with GHC for the windows distribution if license allows, who cares the extra few Mb). Even if that is not technically exact, i.e., even if ghci and many

...

...

command line programs can work without, MSys and MinGW turn out to be quiet necessary whenever trying to install anything producing side effect. Making it plain that these two are necessary would real come has a great time savers for newbie like me on windows (personal opinion of course). Or, if another path exists to go without these two, I'd be very glad to learn. Besides, even these tools basic installation is not enough, you need automake and various things of the like. That makes me wonder if the most precious skill for programming with Haskell would not be a strong C/C++ programming background.

- In face of the difficulties with windows, I switched to Linux. While some things worked better, there were still lots of difficulties with

...

...

compilation. For instance, it is very difficult to figure out which Linux packages of a given distribution are needed for compiling this or that package. Again, gtk2hs is epitome here: which C development packages are needed to compile it is obscure at best (cairo, codeview, etc...). I ended up querying the Debian package management with any keyword found after running gtk2hs and randomly installing all the dev packages...And when gtk2hs finally compiled, it failed to install anyway. As of today, I've never been able to compile even the dumbest demo using gtk2hs whether on linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows,

jamiiecb: plentiful their the tried, probably that trivial package the

...

...

automated setup install worked but did not allow me to compile with codeview and I still do not know how to add codeview to the install packages. Trust that I tried hard and read the docs thoroughly. Gtk2hs is just on of many examples; I had problems under Linux also with, e.g., Happs, yi, database things, etc. and figured out that the situation was roughly identical to windows with MSys and MinGW. So Linux appears not to be the right solution here. Maybe it's just that Linux users are more experienced with the GNU C/C++ libraries...but it won't help a windows user to switch to Linux since this knowledge can't be built out of thin air.

- Would there be some binary version of cabal targeting various OSs? I believe the Haskell platform project is about that. But without waiting for a fair and objective selection of the packages (it seems to be the current status of the project), I'd be happy working with some authoritative bundle produced by a Haskell guru and would trust his subjective choices (who am I to question these choices anyway). Or even an image (e.g., virtual box or Xen) of a fully setup development environment since there are so many dependencies involved in, e.g., simply compiling GHC...

Now, one might argue that these are not Haskell problems, that they are normal when dealing with non-mature packages. So let me explain why I've been trying hard to install these packages:

As a beginner with no experience with emacs, I tried to find some IDE-like environment which would, at least, save me from manually reloading files in ghci or help me browse the source files. Following the Haskellwiki advice, that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. I had to resort to learning emacs which seems the only sensible choice available today.

I am particularly unskilled, no question here. But, would a charitable soul take the pain of writing a comprehensive package management tutorial instead of a monad one, (s)he would have my deepest gratitude :)

Apologies for the long mail.

-Regis

P.S. People on #haskell are wonderful. They helped me solve many issues. Unfortunately, solving specific instances of problem did not contribute much to a deeper understanding of the internal working. I find myself randomly trying things without knowing which would work or why; Hence this plea for a tutorial.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, 2009-01-13 at 18:43 +0100, Peter Verswyvelen wrote:

What could be done is letting the community rate the quality of the modules for each platform? Maybe with user comments? Like amazon.com (so we hackazon.org ;-) And using lambdas instead of stars for giving the rating :)

On Tue, 2009-01-13 at 15:55 -0200, Mauricio wrote:

There's a 'stability' field on cabal description files. Maybe it could appear after the name on the main listing. Or, all packages marked as 'Stable' at that field could get a beautifull color.

My main problem with these mechanisms is that they require a lot of manual work and there is no way to ensure the information is accurate or authoritative. If what we want to know is "does the package build" then we should build it and find out. We should build it on a 100 different platform combinations and combine the information. That's what we're trying to do with the new haskage-server and cabal-install. Lack of developer time is hampering progress. The stability field is almost useless. There is no agreement on what it means and most packages lack it. If what we want to know is "is this version of the package API compatible with this one" then we should follow the package versioning policy. We should let packages opt-in to the policy and if they op-in we should enforce it. That gives us real information and real guarantees. Similar comments apply for test suites and code coverage. Automation and collection of useful information. What human comments are great for however is describing the quality of the API, how well it composes, how good the documentation is, how easy it is to understand and use. That kind of information can only be gleaned through use. I don't know if a star/lambda rating system would be very helpful. There are only a few similar packages in each category (even for xml and databases). Once we eliminate the ones that clearly do not build (using the automatically collected info) then there will only be the comments for two or three packages to review. That's not that much and star rating probably do not provide a very good summary to help in that decision. Automation! Automation! Automation! (Oh and more hackers to help us with these vial community infrastructure projects) Duncan

mle+cl:

Don Stewart wrote:

...

Well, the number one thing is to use Cabal and the cabal-install tool. That is the simplest way to avoid headaches.

I'm sure cabal works very well for many people, but for anyone who has used Debian based distributions for some time, cabal really does seem like a backward step.

For instance, I regularly develop on 6 machines; personal laptop, home desktop, 2 work desktops and 2 work build machines.

At work, the main output of my development work is Debian packages (which get installed on hundreds of machines), and the Debian packages I create have build depends on whatever compilers and libraries are required to build them. We also have a build bot that runs nightly in a clean chroot for each package so that build depends can be verified to be correct.

However, if I install compilers or libraries using cabal there is no package to build depend on, breaking a system which currently works very, very well for all the code we build in C, C++ and Ocaml.

I encourage *strongly* the Debian community to package up hackage packages natively, as we have done on Gentoo and Arch. (This can be automated, in fact, see cabal2arch). cabal-install will work on any system. If you have particular distro requirements, consider distro-specific package tools. -- Don

Erik de Castro Lopo wrote:

Don Stewart wrote:

...

Well, the number one thing is to use Cabal and the cabal-install tool. That is the simplest way to avoid headaches.

I'm sure cabal works very well for many people, but for anyone who has used Debian based distributions for some time, cabal really does seem like a backward step.

For instance, I regularly develop on 6 machines; personal laptop, home desktop, 2 work desktops and 2 work build machines.

At work, the main output of my development work is Debian packages (which get installed on hundreds of machines), and the Debian packages I create have build depends on whatever compilers and libraries are required to build them. We also have a build bot that runs nightly in a clean chroot for each package so that build depends can be verified to be correct.

However, if I install compilers or libraries using cabal there is no package to build depend on, breaking a system which currently works very, very well for all the code we build in C, C++ and Ocaml.

Just in case this isn't clear yet - Cabal is not meant to be a replacement for native Debian packages, it is supposed to let the Debian folks package Haskell stuff more easily. We didn't want to duplicate everything that a good OS packaging system does in Cabal, that's just a waste of time and likely to conflict with what the OS packager is already doing. Sounds like the Debian folks could use some help with automatically packaging Cabal packages, though. Cheers, Simon

There's a 'stability' field on cabal description files. Maybe it could appear after the name on the main listing. Or, all packages marked as 'Stable' at that field could get a beautifull color.

I agree completely. There is not nearly enough documentation on packaging in haskell and too many hackage packages are broken or do not install. I know several people are working on improving this but they seem do be doing so rather quietly. Could someone briefly outline what improvements are planned and what stage the current work is at? I remember seeing some demos at anglohaskell during the summer but nothing since.

Jamie

On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul wrote:

...

Hi,

I've seen many times the monad topic coming around on the cafe and plentiful tutorials on monads have been published. However, as a complete Haskell newbie coming from OOP, I felt monads were not particularly difficult to grasp, and very exciting to work with.

During my experiments with Haskell so far, the main problems I kept bumping into were not related to the language but to its libraries: their compilation and installation. Unfortunately, this topic has not received nearly as much attention. I was unable to find a comprehensive tutorial on how to deal with the variety of problems I get when trying to install Hackage packages. This turned out to be (and still is) THE main source of wasted time and headaches. And worse, unlike type problems, these are not interesting ones to solve.

Thus, as a beginner, the package management is what is really getting in the way of switching to Haskell--not the language. Even books like Real World Haskell (otherwise excellent) ignore entirely the topic. Cabal and Cabal-install are clearly wonderful applications that make installing most packages very straightforward. Unfortunately, whenever this "standard" method for package installation fails (or when it is not available as with, e.g., gtk2hs), I find myself in complete disarray.

Below are some of the questions and issues I faced regarding package management:

- For a number of packages, cabal-install gets stuck and has to be killed. I assume this is due to some difficulties in solving the dependencies and it is fine, not all can be automated and cabal-install is not responsible for poor packages. But the question then becomes what to do from there? Is their some method to solve dependencies? How should we proceed to "debug" a package installation? How do gurus deal with that? (maybe some less known command line arguments? Or ways to figure out the problem and work out its solution (cabal-install is silent in such case)? In particular, how to know why did cabal get stuck in the first place?

- Some packages on Hackage are reported as not building successfully with GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia) and the later might depend on the former...What is one supposed to do in such case? For example, is it an appropriate way to proceed to compile a package with one version of GHC and then use the compiled package with another version of GHC? Is it safe? What could possibly go wrong? If it is the right way to go, how should we setup the two GHC versions? For instance, should we have a shared package configuration file and choose through the path which GHC is used or is there nicer way to set this up?

- Taking for example the "encoding" package on Hackage. Last time I tried, the log was saying it fails to build on GHC 6.10, however, looking inside this Hackage log, I could see a successful compilation using "preferred versions". So it looks as if the thing can be compiled somehow. What should one do with this information? If cabal manages to compile it using this method on Hackage, then isn't cabal install just doing it on my disk? Is it possible through some command line? Is it possible manually (without cabal-install) and, if so, how? (I tried to copy-past the build instruction as it appeared on the log...that somehow compiled, but then, I failed to figure out how to install...)

- I'm primarily a windows user and lots of my initial struggles probably came from that. After many difficulties, I figured out that installing MinGW and MSys was *THE* way to get a bit more of the things working. First, a lot of time would be saved by just saying clearly on the GHC download page that MinGW and MSys are mandatory installation (or even package that with GHC for the windows distribution if license allows, who cares the extra few Mb). Even if that is not technically exact, i.e., even if ghci and many trivial command line programs can work without, MSys and MinGW turn out to be quiet necessary whenever trying to install anything producing side effect. Making it plain that these two are necessary would real come has a great time savers for newbie like me on windows (personal opinion of course). Or, if another path exists to go without these two, I'd be very glad to learn. Besides, even these tools basic installation is not enough, you need automake and various things of the like. That makes me wonder if the most precious skill for programming with Haskell would not be a strong C/C++ programming background.

- In face of the difficulties with windows, I switched to Linux. While some things worked better, there were still lots of difficulties with package compilation. For instance, it is very difficult to figure out which Linux packages of a given distribution are needed for compiling this or that package. Again, gtk2hs is epitome here: which C development packages are needed to compile it is obscure at best (cairo, codeview, etc...). I ended up querying the Debian package management with any keyword found after running gtk2hs and randomly installing all the dev packages...And when gtk2hs finally compiled, it failed to install anyway. As of today, I've never been able to compile even the dumbest demo using gtk2hs whether on linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the automated setup install worked but did not allow me to compile with codeview and I still do not know how to add codeview to the install packages. Trust that I tried hard and read the docs thoroughly. Gtk2hs is just on of many examples; I had problems under Linux also with, e.g., Happs, yi, database things, etc. and figured out that the situation was roughly identical to windows with MSys and MinGW. So Linux appears not to be the right solution here. Maybe it's just that Linux users are more experienced with the GNU C/C++ libraries...but it won't help a windows user to switch to Linux since this knowledge can't be built out of thin air.

- Would there be some binary version of cabal targeting various OSs? I believe the Haskell platform project is about that. But without waiting for a fair and objective selection of the packages (it seems to be the current status of the project), I'd be happy working with some authoritative bundle produced by a Haskell guru and would trust his subjective choices (who am I to question these choices anyway). Or even an image (e.g., virtual box or Xen) of a fully setup development environment since there are so many dependencies involved in, e.g., simply compiling GHC...

Now, one might argue that these are not Haskell problems, that they are normal when dealing with non-mature packages. So let me explain why I've been trying hard to install these packages:

As a beginner with no experience with emacs, I tried to find some IDE-like environment which would, at least, save me from manually reloading files in ghci or help me browse the source files. Following the Haskellwiki advice, that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension. To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows. I had to resort to learning emacs which seems the only sensible choice available today.

I am particularly unskilled, no question here. But, would a charitable soul take the pain of writing a comprehensive package management tutorial instead of a monad one, (s)he would have my deepest gratitude :)

Apologies for the long mail.

-Regis

P.S. People on #haskell are wonderful. They helped me solve many issues. Unfortunately, solving specific instances of problem did not contribute much to a deeper understanding of the internal working. I find myself randomly trying things without knowing which would work or why; Hence this plea for a tutorial.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, 2009-01-13 at 19:20 +0000, Andrew Coppin wrote:

I vividle remember Dons repeatedly telling me that I should try out [some package who's name escapes me], and then discovering that it doesn't actually work on Windows at all. (Couldn't this critical information be included somewhere prominent on Hackage??)

This critical information should be provided on each package page on Hackage. It's not quite as trivial as it looks however. If you'd like to help out, we're working on a new hackage-server that allows users to upload build reports. That way we hope to discover automatically which packages do and do not build on various platforms. The basics work but we need more help in polishing it up. Duncan

On Thu, 2009-01-15 at 00:22 +0100, Manlio Perillo wrote:

Duncan Coutts ha scritto:

...

On Tue, 2009-01-13 at 19:20 +0000, Andrew Coppin wrote:

...

I vividle remember Dons repeatedly telling me that I should try out [some package who's name escapes me], and then discovering that it doesn't actually work on Windows at all. (Couldn't this critical information be included somewhere prominent on Hackage??)

This critical information should be provided on each package page on Hackage. It's not quite as trivial as it looks however.

If you'd like to help out, we're working on a new hackage-server that allows users to upload build reports. That way we hope to discover automatically which packages do and do not build on various platforms. The basics work but we need more help in polishing it up.

Do you know buildbot? http://buildbot.net/trac

Yeah, it's great for some kinds of projects. For example it's used for ghc. However it is very centralised, synchronous and needs ssh on Windows. What we've implemented is using cabal-install to generate build logs and summary info and to upload that to the hackage server. The advantage is that we should get an order or two magnitude more results than if we used a handful of buildbots. It also means we do not have to administer the buildbots, people can administer their own cabal-install setups. We don't need to care so much about individual results if we have enough results. We plan to have two reporting modes, anonymous with minimal info, and non-anonymous with full build logs. So far we've got both but have not separated them yet. Duncan

On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote:

Would be nice if after a failed build cabal asked whether or not to upload its log immediately, and (on the hackage side) this led to an email being sent to the maintainer.

It should not be quite that synchronous but yes that's the general idea. Packages can fail to install for many reasons that are not the fault of the package author, for example missing C libraries. Also, I think maintainers would not be pleased to receive 10's of emails per day! :-) I think in practise it will have to be opt-in for package authors/maintainers and it should only send aggregated information (like "it appears not to work on windows with ghc-6.8"). Duncan

Eugene Kirpichov ha scritto:

Well, I thought about these 10's of emails too; probably hackage could send an email when a new broken build arrives but only if there were no 'unresolved' broken builds before this one; or probably an email at the first broken build and a weekly email reminding "you've got some unresolved broken builds".

As for missing C libraries: could cabal probably integrate with the native package manager (apt/rpm/..) and ask the user whether to invoke it to install these libraries in case they are missing?

I like the idea. An "external package" database, where for each "software" we have an Haskell name, with this name mapped to each specific package.

However, this is not a solution for Windows since there's no native package manager.

For windows an "Haskell external package" name can be mapped to an URL to a "well know" Windows installer.

[...]

Manlio Perillo

On Thu, 2009-01-15 at 14:25 +0100, Ketil Malde wrote:

Duncan Coutts writes:

...

On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote:

...

Would be nice if after a failed build cabal asked whether or not to upload its log immediately, and (on the hackage side) this led to an email being sent to the maintainer.

...

It should not be quite that synchronous but yes that's the general idea.

Perhaps the maintainer should receive a build summary at regular intervals? This would also work as a check whether there is a live maintainer at the other end of the listed maintainer address. (And hopefully be enough of an annoyance on the libraries@ list that people would start looking for maintainers for orphaned packages :-)

It may well be tempting to plague maintainers until they fix their packages however in practise it will not work. We want a low barrier to entry for packages on hackage and we do not want to annoy package maintainers to the point where they decide to stop using hackage at all. Of course we also want to measure package quality. The approach I've always advocated is to define subsets of hackage that do meet higher quality levels. Be defining such subsets and holding them up as being a "good thing" in the community then it puts social pressure on maintainers to have their packages in those higher quality subsets. Then to help them do that they may choose to opt-in to various services like receiving a build summary at regular intervals. So it's the same goal but without the stick. Duncan

Duncan Coutts wrote:

It may well be tempting to plague maintainers until they fix their packages however in practise it will not work. We want a low barrier to entry for packages on hackage and we do not want to annoy package maintainers to the point where they decide to stop using hackage at all.

+1. As a package maintainer, I love to get feedback (especially when things are broken) but I don't like being harassed. I get lots of email from all over and in order to make sure the most important things are seen soonest, routine email from bots often finds its way into filtering and rerouting... which means, whether intended or not, it often gets ignored or overlooked. After a decade or so in this game, one of the big tricks with project management (and kid yourself not, this *is* PM what Duncan et al. are so kind to take on for us) is how to balance interaction between the developers, the managers, and the clientele. The biggest trick is in that key word: interaction. When people feel put upon, ignored, or talked at (instead of talked to) then they're not interacting, not communicating, not being a part of the community. And when people aren't communicating they feel unappreciated. In the F/OSS world that means they stop contributing. Just like with friendships, jobs, and life in general, it takes a lot more work to find new developers than it does to keep the ones you have. Since life happens and you can't stop entropy, that means in turn that barriers to entry must be as low as is reasonable[1]. One of the things I've always liked about Hackage is how low the barriers are. I've also been a CPAN developer for many years, but I haven't released as much Perl code as Haskell code because it takes more work to publish a CPAN module than it does to publish a Hackage package. (Even after having accounts in both systems, of which again Hackage is easier.) Rather than just being a stick in the mud, here are some suggestions for what I, as a developer, would like to see in Hackage/Cabal/FooBlatz's future. First, I would like (via opt-in) to get periodic aggregated notice about failed builds. The simplest version of this would be sending out emails when the HackageDB build fails, rather than needing to remember to check back a while after uploading a new version. It would be nice to extend this to collect cabal-install failures, though that can get tricky about how not to harass the clientele. Minimally these aggregated reports should indicate the package and version, the problem, the Haskell compiler and its version, as well as the OS. Since some packages have many dependencies or make heavy use of the FFI, CPP, or have architecture dependent differences, it would be nice to be able to set per-package preferences to get additional information like OS version, dependency versions, CPU info, build logs, etc. Since it can be hard to set up sandboxes for every configuration, it'd also be nice if clients could opt in to send contact email as well, if they're willing to back-and-forth with the developer to fix things in the event of bugs. Second, and this would take more work, I would like it if the Haddock documentation for packages could be given a wiki-like and/or reddit-like interface so that people could make comments about what is unclear or needs better documentation as well as offering spelling/grammar/punctuation suggestions[2]. Viewers should be able to set preferences for whether they want to see the real/current documentation, or whether they want to see the commented/modified version (hiding things below a certain depth or rank for reddit-like). While building errors are an obvious point of failure, we know the design space and just need to find an elegant minimalistic solution there. I think the documentation problem is just as important a point of failure, if not more so because it is discussed less often. The solution here is harder since the design space hasn't been so thoroughly charted by previous languages. But given the very community-oriented nature of Haskell programming, it's a shame that we don't yet have a community-oriented solution to the documentation problem. The big trick will be how to both segregate and integrate community feedback and the official documentation (which should always be under the maintainer's control, hence the wiki/reddit should also be opt-in), in addition to issues about how package versioning interacts with the comments. At the same time, like QuickCheck, this strikes me as a ripe domain for "killer app" breakthroughs. Perhaps one of the folks working on wiki and web development tools in Haskell would like to make a name for themselves? [1] Which does not mean as low as is possible. When the barriers are too low the community can expand too quickly for the leaders to keep things functioning smoothly and cohesively. Just as with biology and finance, these population booms are just as quickly followed by busts and starvation, the damage of which has a momentum all its own. The greater community's embitterment toward the busted one raises the barriers to entry quite high, and often this retaliation does not wane for a very long time. [2] For wiki edits to the documentation (as opposed to reddit comments), maintainers should be able to get a darcs (or diff) patch against the release version of the source code, as desired. This alleviates the forking problem which could inhibit importing changes from the wiki back into the source.

Of course we also want to measure package quality. The approach I've always advocated is to define subsets of hackage that do meet higher quality levels. Be defining such subsets and holding them up as being a "good thing" in the community then it puts social pressure on maintainers to have their packages in those higher quality subsets. Then to help them do that they may choose to opt-in to various services like receiving a build summary at regular intervals.

So it's the same goal but without the stick.

I like this approach as well. As I said, we Haskellers are very community driven and the social pressure towards perfectionism is already strong. Stick-based approaches are very anti-social. (And if you think about it, they're very imperative too. Whereas modeling high-quality work is much more declarative. Hmm...) -- Live well, ~wren

2009/1/18 Duncan Coutts :

...

Second, and this would take more work, I would like it if the Haddock documentation for packages could be given a wiki-like and/or reddit-like interface so that people could make comments about what is unclear or needs better documentation as well as offering spelling/grammar/punctuation suggestions[2]. Viewers should be able to set preferences for whether they want to see the real/current documentation, or whether they want to see the commented/modified version (hiding things below a certain depth or rank for reddit-like).

We had a thread on this the other day with similar ideas.

It might not count as a summary, since I'm not sure I've read all of the discussion, but I added a ticket describing this type of system here: http://trac.haskell.org/haddock/ticket/72 If something is missing, please add it, and feel free to post more thoughts. David

On Thu, 2009-01-15 at 12:45 +0100, Manlio Perillo wrote:

Duncan Coutts ha scritto:

...

[...]

...

Do you know buildbot? http://buildbot.net/trac

Yeah, it's great for some kinds of projects. For example it's used for ghc. However it is very centralised, synchronous and needs ssh on Windows.

What we've implemented is using cabal-install to generate build logs and summary info and to upload that to the hackage server. The advantage is that we should get an order or two magnitude more results than if we used a handful of buildbots.

This seems a good idea. However, it is possible for a thirdy part user to submit build logs for a specific platform?

Yes.

In detail: - The package author submit his package, and additional build logs for each platform he have access to - Other users can submit additional build logs for their platform

I think, however, that a centralized system has its advantages. As an example, a newly submitted package can be put in a 'incoming queue', and moved to the final destination only if it builds (and tests succeed) on all the supported platforms.

What we really want is both. We want to let random users on random platforms submit simple anonymous build reports (no logs). In addition since any client can upload reports we can set up a number of dedicated clients that will build every new package in a chroot and upload non-anonymous detailed build reports with build logs. The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients. Duncan

On Thu, 2009-01-15 at 13:26 +0100, Manlio Perillo wrote:

...

...

In detail: - The package author submit his package, and additional build logs for each platform he have access to - Other users can submit additional build logs for their platform

I think, however, that a centralized system has its advantages. As an example, a newly submitted package can be put in a 'incoming queue', and moved to the final destination only if it builds (and tests succeed) on all the supported platforms.

What we really want is both. We want to let random users on random platforms submit simple anonymous build reports (no logs).

In addition since any client can upload reports we can set up a number of dedicated clients that will build every new package in a chroot and upload non-anonymous detailed build reports with build logs.

Since nowdays virtual machines are very affordable, it would be nice to have a set of standard virtual system images, preconfigured to run Cabal installation process.

So that when I compile a package on my system, Cabal can be instructed to: 1) Start each virtual machine on the system 2) Submit the package to each machine an get the report 3) Stop each virtual machine

Is this a feasible task?

Yes, and the great thing is that anyone could do that. That's the advantage of a decentralised system. It does not require the permission or help of the cabal/hackage hackers to do it.

The only "problem" is with proprietary operating systems like Windows and Mac OS, where pre-configured systems can not be provided.

True. The other issue is that perhaps knowing something builds on a clean virtual machine is not quite so useful as knowing it builds on 100's of messy machines in dozens of different configurations. So that's not to say that using dedicated build clients running on virtual machines is not useful, it is. But we don't need lots and lots of those. Duncan

Yitzchak Gale ha scritto:

Duncan Coutts wrote:

...

We want to let random users on random platforms submit simple anonymous build reports (no logs)... The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients.

And that we open ourselves up to some serious security concerns - like hostile build reports and DOS.

DOS is always a problem, for every application open to the Internet. As for hostile builds reports, I don't see it as a security concern.

-Yitz

Manlio Perillo

On Thu, 2009-01-15 at 14:38 +0200, Yitzchak Gale wrote:

Duncan Coutts wrote:

...

We want to let random users on random platforms submit simple anonymous build reports (no logs)... The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients.

And that we open ourselves up to some serious security concerns - like hostile build reports and DOS.

Detailed build reports with logs are not anonymous, clients will need an account on hackage (ie username and password). Yes, we could get flooded with anonymous build reports, but they're much smaller and hopefully they'll either be obviously bogus or drowned out by the volume of legit reports. So the information content and reliability of each data item is lower but hopefully the volume makes up for it, so long as we do the statistics carefully. As Manlio says, we're always open to DOS attacks. We just have to make sure we're not more vulnerable than average by doing too much work on the server side compared to the work done by the client (ie the processing of anonymous reports has to be fairly cheap). Duncan

"Yitzchak Gale" writes:

...

or drowned out by the volume of legit reports.

Again, if this is automated, it is trivial generate the required volume.

It won't help re: botnets, but you can stop casual flooding attacks by rate-limiting per IP on the server. -- Gregory Collins