On Thu, May 19, 2011 at 2:18 PM, Simon Peyton-Jones <[email protected]> wrote: > 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?
No, I think it's fine. Once I got down to do the detailed review I forgot that this important principle had already been stated. > | 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.) Good to know that internal changes doesn't need review. Would an ask-for-forgiveness model work i.e. if the maintainer makes some radical change someone who reads the commit emails could complain and have the change reverted. > | 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? I don't think we need to equate "chance to react" with upfront review. Once can react by e.g. following commit messages. > | 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. I'd like to set some expectations here. My current belief is that the process that's used to managed e.g. bytestring, text, and network is fine. That is the default the-maintainer-knows-what-he's-doing open source approach. I'll try to be open to any restrictions to that, but this is the point I'm starting at. Cheers, Johan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
