httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@apache.org>
Subject Re: [vote] mod_ldap
Date Wed, 13 Jul 2011 00:07:34 GMT
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.


Mime
View raw message