On 7/10/2011 5:34 PM, Roy T. Fielding wrote: > Regardless of anyone else's opinion, the addition or deletion of a > new API to our product is a technical change that can be vetoed. > Likewise, the API being an incomplete abstraction that isn't > needed in httpd is a valid technical reason to veto it even if > it had once been in apr-util.
So if I understand your statement, to examine a hypothetical case, it was entirely my choice to veto your request to deprecate mod_aspdotnet from the httpd project? (It was a suggestion I agreed with, but I do want to understand exactly your point here and it seems like a harmless example to discuss). This doesn't apply directly at httpd, but it would certainly be an interesting case to examine relative to the apr projects votes to drop a poorly supported and incomplete feature. One of the meta questions that comes out of this particularly lengthy thread is; what does any project do with code that would not obtain 3 +1's standing on its own? mod_aspdotnet had hit that point (no committer interest) and mod_ftp may very likely hit that point as well; mod_fcgid is just hanging on at this point with a small surplus. As such things become features of the meta-package (mod_fcgid is proposed for httpd trunk, so it's a good example) how is the desire for dozens of features by their individual authors balance with the fundamental consideration that all code should have three project members paying at least some oversight of it? If vetoes didn't purposefully exist to hang on to orphaned code by the choice of only a single champion, perhaps this general problem set needs to be reexamined? The voting rules seem largely a product of dealing with conflicting desires for adoption and evolution of code, but with coming up on 20 years of history, it is inevitable that httpd will face this issue again in the future.
