Hello, On 16-07-2010, Ivan Lazar Miljenovic wrote:

I'd like to request some clarification of some of the questions:

1. By "all projects", are you including one-use only scripts? How about university assessments (when it isn't Haskell-oriented, just have to write a program to do some simulation or something) and thus it isn't meant to be something used by other people or used after a certain date, etc.?

You can use cabal as a standalone build system generator. So you can use it also for unreleased projects. Using it this way shows that the tool "cabal" itself is useful. But you need to draw a line, so if you don't use it for "one-use only scripts", I think you should still answer "for all projects". But if you only use it for project that you intend to publish, you should answer "Only for projects released on Hackage".

3. I use cabal-install only in testing my own packages (as it's easier to do "cabal foo" than "runhaskell Setup.hs foo"). I also use cabal-install to test which packages I have installed have newer versions available (cabal update && cabal upgrade --dry-run) so that I can update the Gentoo packages for them. As such, which option should I choose from the ones offered (as none of them match my case)? Should the question be clarified and be made more explicit?

Depending if you only use Gentoo Haskell package or not: - if you use only Gentoo packages: "No, I only use packages from my Linux/Mac/Windows distribution" - if you still have some packages installed from Cabal: "I use cabal-install when my Linux/Mac/Windows distribution doesn't provide the package"

9. I wouldn't classify Hackage as a "tool", but even still, what happens if we think Hackage is very important but still should be replaced? (Playing devil's advocate here: I think it could do with some upgrades but there's no need to completely throw out what's already there).

It depends how strong your feeling about Hackage is: - if you say "damn it misses this or that" each time you use Hackage: "Hackage should be replaced by a better tool" - if you only have minor problems and think it is an important tool: "Hackage is a very important tool for the Haskell community" Regards, Sylvain Le Gall

I give again the survey URL: http://polldaddy.com/s/2C49D15023CB88C6 On 20-07-2010, Ketil Malde wrote:

Ivan Lazar Miljenovic writes:

...

I'd like to request some clarification of some of the questions:

You might want to add a "don't know" or similar option, so that people don't have to fill in questions arbitrarily in the case they feel none of the answers match.

You can just skip the question. No question are mandatory.

...

3. I use cabal-install only in testing my own packages (as it's easier to do "cabal foo" than "runhaskell Setup.hs foo").

I generally try to use distribution packages first, and (manually) download from hackage in case my distribution doesn't supply what I need. I'm not quite sure what to answer here.

I think the answer: "I use cabal-install when my Linux/Mac/Windows distribution doesn't provide the package" should be ok. Thank you for answering the survey. Regards, Sylvain Le Gall

Hello, On 20-07-2010, Christopher Done wrote:

Do you value libraries/tools that are shipped through Hackage?

* Yes, I always use only libraries/tools available on Hackage * Yes, but if a package is not available on Hackage, I will still use it

I'm torn between the first two. I picked the first. If it's not available on Hackage, I will usually package it up and put it on Hackage. (E.g. the Frisby library hasn't been on Hackage for some reason so I uploaded it http://hackage.haskell.org/package/frisby)

I think you pick the right answer.

Anyway, I took the survey. Nice idea. How much response have you had so far?

I have 239 answers so far. This is far beyond what I expected. Right now, my problem is that polldady limits answers to 100 per month, so I will have to wait until August to be able to read 200 answers (and september for the rest). But, you can still answer to the poll -- I will probably upgrade my account to read all the answers before september ;-) If you want to know some basic things I discover: - Being able to rate/comment a package is a must have - Most common pitfalls: Difficult to choose which library to use I never thought of adding ratings/comments to my OCaml project (OASIS-DB). All your answers already clarify a very important feature missing from my project. A lot of thanks. http://oasis.forge.ocamlcore.org/oasis-db.html Regards, Sylvain Le Gall

That sounds like a good idea. I'd like to know when my packages fail to build or show warnings about deprecated features, etc. On 22 July 2010 09:16, Ketil Malde wrote:

I've rather recently started to use cabal-install to install packages from Hackage.  Unfortunately, so far many packages fail to install.  I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time.

Wouldn't it make sense to provide automated notification of the package author when a package fails to build?  I certainly would like to know about it, but of course, I never remember to check back to see.

-k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I don't know how wise that is; I tend to fix packages when I find they're broken. I'd prefer a way for there to be more than one maintainer for a package, i.e., collaborators, like on Github, so that a maintainer can add me as a collaborator. My only problem with Hackage is I feel like the maintainer is a fence I have to climb every time I want to upload a bugfix or a non-broken version of the package. I just want to fix it, upload it, and continue with my work. Also a "last seen" a la StackOverflow would be good, so that you can see what a maintainer was last on Hackage. That's assuming the new Hackage will support logins. On 22 July 2010 09:52, Isak Hansen wrote:

On Thu, Jul 22, 2010 at 9:16 AM, Ketil Malde wrote:

...

I've rather recently started to use cabal-install to install packages from Hackage.  Unfortunately, so far many packages fail to install.  I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time.

Wouldn't it make sense to provide automated notification of the package author when a package fails to build?  I certainly would like to know about it, but of course, I never remember to check back to see.

How about taking it one step further, actually "hiding" unmaintained packages after a grace period?

Unless the user runs cabal with an --include-deprecated option, or something.

Isak

...

-k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ 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 Thu, Jul 22, 2010 at 10:02, Malcolm Wallace wrote:

...

My only problem with Hackage is I feel like the maintainer is a fence I have to climb every time I want to upload a bugfix or a non-broken version of the package. I just want to fix it, upload it, and continue with my work.

Unfortunately, experience shows that a gatekeeper is usually necessary.  Otherwise random people create and apply patches that break stuff they don't care about, whilst fixing only their immediate problem.  Distributed version control, like darcs and git, already lowers the barrier to participation very significantly.  But having someone review patches before publishing them to the world at large is widely considered the most effective quality control known in the field of software engineering.

An alternative would be to let people upload forks of a package, similar to how github/bitbucket supports forks on a VCS level. I'm not convinced it's a common enough situation to be worth the hassle though. /M -- Magnus Therning                        (OpenPGP: 0xAB4DFBA4) magnus＠therning．org          Jabber: magnus＠therning．org http://therning.org/magnus         identi.ca|twitter: magthe

Not to discourage this brainstorming, but many of what people think to be "new ideas" are being implemented by a GsoC student [1] already. Yay!

...

...

I've rather recently started to use cabal-install to install packages from Hackage.  Unfortunately, so far many packages fail to install.  I try to email authors/maintainers, but when I check build logs on Hackage, I discover that some of these packages have failed building for some time.

The hackage build logs can be misleading - many system specific packages may or may not build on hackage because it just isn't the right OS. Still other packages require particular C libraries that the hackage server doesn't have. For these reasons the build reports will come from end developer systems (see linked blog).

...

...

Wouldn't it make sense to provide automated notification of the package author when a package fails to build?  I certainly would like to know about it, but of course, I never remember to check back to see.

Yes, but because this comes from the cabal-installer vs hackage there was more work needing done.

...

How about taking it one step further, actually "hiding" unmaintained packages after a grace period?

Talk to Gracenotes and Coutts - they can be found on #hackage frequently. Cheers, Thomas [1] http://cogracenotes.wordpress.com/

On Thursday 22 July 2010 18:23:32, Stephen Tetley wrote:

On 22 July 2010 16:56, Thomas DuBuisson wrote:

...

The hackage build logs can be misleading - many system specific packages may or may not build on hackage because it just isn't the right OS.  Still other packages require particular C libraries that the hackage server doesn't have.  For these reasons the build reports will come from end developer systems (see linked blog).

Presumably you can only get false negatives - i.e. "correct" packages failing to build due to missing C libraries, or depending on Haskell libraries at different version numbers to the build server?

...

...

...

Isak Hansen:

How about taking it one step further, actually "hiding" unmaintained packages after a grace period?

Hiding unmaintained libraries seems contrary to Hackage's spirit - if you want to depend on an unmaintained library why not volunteer to be the maintainer.

I think it was more meant to be fails to build and not updated for (>= k months) ==> move to packages/notshiny If it doesn't build and nobody seems to care about it anymore, why let it clutter the pkg-list, that's crowded enough even without zombies. Of course, new release that builds ==> back to pkg-list