Johan Tibell wrote:
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. 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)?
Arguably, the right thing to do here is to have one proposal which says: "Let's add strict versions for these functions because ... and but not for these functions because ...". Having two weeks to discuss this doesn't seem that unreasonable. IMO, changing APIs one function at a time is usually not optimal. If a change is part of a larger design then it's much better to discuss the entire design at once. If it's completely isolated, then it often isn't really worthwhile anyway. Again, this is probably just my opinion but I think that proposals of the form "add this function" should be routinely rejected unless there are really good reasons to accept them. As you say, they often just complicate the API and don't contribute to the overall design. Roman