New libraries process

Chris Dornan chris at
Thu May 19 14:56:20 CEST 2011

Hi All,


Is there any chance that we can allow (say) the Haskell committee to have a
veto if they think a mistake with systemic consequences is about to be made.


I don't expect it to be used, but it would signal that the stability or lack
thereof of the Haskell libraries has systemic consequences for all Haskell
users and other library maintainers.


I do not want a heavyweight process, but it would be good to see some
representation of the bigger picture in this process, even if it is
generally held in reserve.


Others have a much more experience in these matters - I may be bothering
over nothing and complicating things. It is just an idea.





From: libraries-bounces at [mailto:libraries-bounces at]
On Behalf Of Simon Peyton-Jones
Sent: 19 May 2011 13:19
To: 'Johan Tibell'
Cc: cvs-ghc at; Haskell Libraries
Subject: New libraries process


[Changing subject line; sorry for the odd initial one!]

| "widespread support" is a bit of a wishy-washy phrase. If 7 people
| want it, is that widespread support?
| ...should be added. However, there's a strong selection bias here and
| ...This is one of the places where having a real maintainer is crucial.

I agree.  The maintainer should take account of selection bias.  I've added
words to that effect.

| experiencing. If the maintainer is "required" to accept such changes,

No, we intended that the  maintainer is never *required* to accept a change.
To quote "the community offers opinions; the maintainer decides".   If you
think that point should be made even more strongly, can you go ahead and

| It's not clear when the "deadline for discussion" should be used. Does
| it apply to any change or only public API changes? Does it apply even
| if it's the maintainer that making the change? Having to spent two
| weeks (even though most of the time is spent waiting) to make a single
| change is too high an overhead for me. I suspect I would just not
| bother making the change.

Our intention was to make sure that the community had *some* opportunity to
comment on a change that may affect them.   You point about public APIs is a
good one -- for internal changes perhaps all a proposer needs to is to
persuade the maintainer.  (Or, if the proposer is the maintainer, persuade

| To make things more concrete, what steps are
| required of the (future) maintainer of containers who wants to add a
| strict version of some function (many functions are missing a strict
| version at the moment)?

So this is a public-API change, but you could argue that it's one that
cannot hurt a client because it's only widening the interface.

What about if you wanted to change the signature of a function in the API.
Wouldn't it be reasonably to give your community a chance to react?

| Depends entirely on what the process ends up being.

Good.  I'll be dissatisfied if we don't end up with a process that you think
is sane.


Libraries mailing list
Libraries at 


No virus found in this message.
Checked by AVG -
Version: 10.0.1325 / Virus Database: 1509/3646 - Release Date: 05/18/11

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list