[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 _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
