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. Chris From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 19 May 2011 13:19 To: 'Johan Tibell' Cc: cvs-ghc@haskell.org; 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 edit? | 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 himself.) | 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. Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1325 / Virus Database: 1509/3646 - Release Date: 05/18/11