Comments on: Heuristics for Blessing Software Packages

By: Michael O'Keefe

Michael O'Keefe — Tue, 04 Aug 2009 01:22:03 +0000

What you folks are doing with the Haskell Platform is absolutely awesome.

I fully agree with solrize that a set of “benevolent dictators for life” taking input from the community would trump any point system.

Haskell is an absolutely awesome language but it strikes me that rounding out the full functionality for a “batteries included” set of “blessed” libraries to offer something competitive with Python and/or Java or .Net languages is what’s really needed (solrize’s point 3).

By: Max

Max — Mon, 03 Aug 2009 10:17:32 +0000

Ubuntu and Debian have package statistics for users who have installed the popularity-contest package (Ubuntu, at least, offers to install it when setting up). Statistics are available at http://popcon.debian.org and http://popcon.ubuntu.com.

On these pages “inst” means number of installations, “vote” means number of installations *which have been used in the past n days* (I think n=30).

By: haddock2009

haddock2009 — Mon, 03 Aug 2009 02:20:48 +0000

..so it looks like any package will only be accepted if it has a maintainer who is willing to maintain it for Haskell Platform. Generally an existing maintainer would take on the rather light responsibilities (stick to PVP, make announcements when there are new releases, anything else?)… but if the maintainer thinks it’s not ready for HP, then it’s probably not, but theoretically someone could sort of fork it and maintain it for HP.

maybe that’s a sketch of the relationship we need to have with maintainers?

well, except some of the core packages are just maintained by “libraries@” which means they make decisions and various people do the busywork of applying patches when appropriate. And often fix them in regards to GHC changes also

By: sclv

sclv — Mon, 03 Aug 2009 00:48:36 +0000

Also it would be particularly nice to bless hslogger, and a few other related packages designed for parsing config files and command line options, etc — the sort of basic machinery to help users get up and running quickly. I don’t know the space well, but I’m sure there’s a few people who can put the right thought and discussion into it.

By: sclv

sclv — Mon, 03 Aug 2009 00:45:54 +0000

If it’s decided that a package should go in *but* — i.e. but it needs better test coverage, or but it needs to clean up its dependencies, or etc, then it seems that the right thing would be to make it a point to encourage package maintainers to bring it up to par. Additionally, I suspect package maintainers might not *want* to be blessed at a given stage. E.g., haxml might want to wait on resolving the two-version issue, etc?

Data.Binary seems to be a gimme, but on the other hand, something like HDBC is more complicated — even though it should be the standard, I think, it needs a backend to do anything, and the backends in turn need to have libraries installed to bind to, which raises the question of why install the frontend if it can’t do anything on its own?

By: dons00

dons00 — Sun, 02 Aug 2009 23:07:45 +0000

haddock2009, Note that 4 packages is 0.27% of Hackage :)

By: haddock2009

haddock2009 — Sun, 02 Aug 2009 23:00:46 +0000

It may be that there simply don’t currently exist as many as 4 libraries that are high-quality enough to go into the Platform currently, too, depending how picky we want to be.

By: solrize

solrize — Sun, 02 Aug 2009 07:37:34 +0000

There should also be some refactoring of stuff between packages. For example, the MaybeT module should go away, and MaybeT should be included in Data.Maybe or mtl or wherever the standard place for such things is.

By: solrize

solrize — Sun, 02 Aug 2009 07:32:26 +0000

Don, I don’t think you should have a point system or anything of the sort. While community input should weigh into the decisions, I think you and the other platform maintainers should feel authorized to use your own subjective judgement as appropriate.

What I think matters the most about something in the platform is the quality of the code. I was flattered when you once encouraged me to contribute stuff to Hackage, but at the same time that told me that Hackage is populated by code written by relatively unwashed implementers like me–and therefore I don’t want to use Hackage code for anything serious (except for some specific packages that I know are well-regarded). Platform code should be:

1) reviewed by experts, who wouldn’t be expected to take responsibility for it themselves, but who would at least make sure that the implementation is reasonably complete and reasonably sane; and

2) well-documented, which not much of it is right now;

3) One significant priority should be on having enough functionality in the platform to enable easy and well-performing implementation of anything that can be done in competing languages like Python or Java.

Example of #3: bos’s Text module makes it possible for the first time to write competitive Unicode text-processing applications. So it should be treated as important.

I agree with the idea of an eventual crypto module, but functions like sha are important enough to include immediately. The module contents can later be replaced with calls to the TBD crypto module so that the existing API will keep working.

Also, a code signing capability should be added to cabal, similar to signatures on .jar files.

By: TomMD

TomMD — Sun, 02 Aug 2009 04:19:44 +0000

“Library longevity”, while not a common issue is worth considering. For example: SHA, pureMD5, RSA, etc should all disappear in the long run and be replaced with an improved Crypto library.