Deciding on the decision model for adding and excluding packages
We need to start thinking about how to add or exclude packages from the Haskell Platform. I've written a summary of the discussion so far for evidence-based critieria for deciding on package notability. http://donsbot.wordpress.com/2009/08/01/heuristics-for-blessing-software-pac... Please read it over and think about what the decision model looks like. So we can feed data in, to make decisions on how to include/exclude packages. -- Don
On 01/08/2009 23:16, Don Stewart wrote:
We need to start thinking about how to add or exclude packages from the Haskell Platform.
I've written a summary of the discussion so far for evidence-based critieria for deciding on package notability.
http://donsbot.wordpress.com/2009/08/01/heuristics-for-blessing-software-pac...
Please read it over and think about what the decision model looks like. So we can feed data in, to make decisions on how to include/exclude packages.
From that page, it looks like all the automatic procedures for deciding the top packages result in packages that we don't want in the platform for one reason or another. I'd argue against having a points system: such things also tend to produce unsatisfactory results, so you end up tweaking the weightings to get the results you did want. OTOH, the set of criteria you outlined for evaluating packages are good, but they should be used as a set of guidelines rather than a way to make decisions. In practice we'll probably find that there are criteria not on the list that end up being more important, e.g. utf8-string is immensely popular but is a stopgap measure and we don't really want to endorse its use, and extensible-exceptions is essentially a backwards-compatibility shim, so we don't want it in for similar reasons (OTOH, what about base3?). I suggest the best way forward is to identify needs: we need a package that provides a certain functionality, so look at what is available and go from there. If the available packages aren't suitable for one reason or another, then feed that back to the maintainers and the community. On a concrete note, I think we should seriously consider putting gtk2hs in the platform. As someone pointed out recently (I forget who, sorry!) the point of the platform is to give you the hard-to-install pieces, and gtk2hs is one such piece. Having gtk2hs would be a significant step up in terms of functionality, though. Cheers, Simon
Hi Simon,
I'd argue against having a points system: such things also tend to produce unsatisfactory results, so you end up tweaking the weightings to get the results you did want.
I strongly agree with this (and have argued against Duncan and Don on this before) - 100% coverage is something nice to have if you go about it the right way. If you are required to have 100% coverage (or any other metric) then you cheat. Aim for quality packages, and if someone thinks about test coverage that indicates quality - even if they decide in this particular case coverage is a little meaningless.
On a concrete note, I think we should seriously consider putting gtk2hs in the platform. As someone pointed out recently (I forget who, sorry!) the point of the platform is to give you the hard-to-install pieces, and gtk2hs is one such piece. Having gtk2hs would be a significant step up in terms of functionality, though.
YES! Gtk2hs is wonderful, and never has an up to date GHC release. I currently don't care too much about the platform (I've got a copy of cabal install and its not really aimed at me anyway) - but if you bundle network, hmatrix and gtk2hs then I can't imagine any Windows user who wouldn't install it. Thanks Neil
marlowsd:
I suggest the best way forward is to identify needs: we need a package that provides a certain functionality, so look at what is available and go from there. If the available packages aren't suitable for one reason or another, then feed that back to the maintainers and the community.
I think this is good. We can start by looking at the categories provided by Python: http://docs.python.org/library/index.html And filling in the gaps. Doing this may lead to some concrete proposed packages, which in turn can force the process along. -- Don
Don Stewart wrote:
We need to start thinking about how to add or exclude packages from the Haskell Platform.
I've written a summary of the discussion so far for evidence-based critieria for deciding on package notability.
http://donsbot.wordpress.com/2009/08/01/heuristics-for-blessing-software -packages/
Please read it over and think about what the decision model looks
So we can feed data in, to make decisions on how to include/exclude
like. packages. I suggest making the discussion concrete by opening up for a list of suggestions, and then trying to figure out which of those suggestions should go in. Hopefully we can then back out a set of principles or precedents for the future from the discussion. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
ganesh.sittampalam:
Don Stewart wrote:
We need to start thinking about how to add or exclude packages from the Haskell Platform.
I've written a summary of the discussion so far for evidence-based critieria for deciding on package notability.
http://donsbot.wordpress.com/2009/08/01/heuristics-for-blessing-software -packages/
Please read it over and think about what the decision model looks
So we can feed data in, to make decisions on how to include/exclude
like. packages.
I suggest making the discussion concrete by opening up for a list of suggestions, and then trying to figure out which of those suggestions should go in. Hopefully we can then back out a set of principles or precedents for the future from the discussion.
Package suggestions, you mean? -- Don
Don Stewart wrote:
ganesh.sittampalam:
I suggest making the discussion concrete by opening up for a list of suggestions, and then trying to figure out which of those suggestions should go in. Hopefully we can then back out a set of principles or precedents for the future from the discussion.
Package suggestions, you mean?
Yes. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
ganesh.sittampalam:
Don Stewart wrote:
ganesh.sittampalam:
I suggest making the discussion concrete by opening up for a list of suggestions, and then trying to figure out which of those suggestions should go in. Hopefully we can then back out a set of principles or precedents for the future from the discussion.
Package suggestions, you mean?
Yes.
Ok. I'll put tools in place to collect those. Stay tuned. -- Don
participants (4)
-
Don Stewart -
Neil Mitchell -
Simon Marlow -
Sittampalam, Ganesh