On Mon, Jan 30, 2012 at 3:06 AM, <hv@crypt.org> wrote: > I consider this deprecation risky: Further, I consider there is a non-zero > probability that once we try it we may find that the practice we wish > to deprecate is so widespread that we reconsider our approach. > [snip] > Attempting this at the start of a cycle would give us the space we need > to discover whether it's a really bad idea. Apologies in advance for "picking on you", but this is a good example of the confusion of issues/arguments that I would like to avoid. (a) "it may break things by being misimplemented, or it may break things by introducing new warnings deep in code that doesn't expect it." Fair point -- I don't have an opinion on that, but leave it to Rik to decide between expert opinions. (b) "a non-zero probability that once we try it we may find that the practice we wish to deprecate is so widespread that we reconsider our approach" I argue that we have no way to know this during the development cycle beyond the sort of "grep/smoke CPAN" approaches already done. This is only something we'll find out after a stable release when the broader userbase starts to use it (which might not happen for years). This is not an argument to delay; this is an argument not to do it because of the risks involved. (c) "Attempting this at the start of a cycle would give us the space we need to discover whether it's a really bad idea." This *is* an argument for delay, but much as with (b), I don't think it's legitimate for the same reason I cited above. Thus, if your recommendation is "not now", then only (a) seems to have merit. Alternatively, if you're argument is "never", then only (b) seems to have merit. If many people feel the same either (a) or (b), then it probably does rise to the level of "controversial feature". Whichever way you (and others) wish to recommend, these discussions will go smoother and get resolved faster if the issues are more cleanly separated. -- DavidThread Previous | Thread Next