Graham Leggett wrote:
William A. Rowe, Jr. wrote:
I don't mind rolling dice that the code is 'good enough' if it gets the
votes here on list. Seriously, no objections. But it's too damned easy
to get +1 "ya, that's a cool new module, but I doubt it works, so throw
it in experimental." Code that, anywhere else in the ASF, would never
get the votes for release. And -that- is why experimental must die :)
The trouble with new modules is that no matter how meticulously you went
over it, there is always one platform that doesn't work (in the case of
LDAP, the PITA platform was Windows), but if you don't release the code
in case it might not work, it will never reach the people who have the
resources to make it work.
Yet - it's not experimental (taking the LDAP example). So we, as an
entire group, agree to figure out how to build the danged thing so it's
working on all platforms by the end of beta (and it was, in 2.0 working
on all platforms, this has to do with the apr-util refactoring today,
and it will work in 2.2 before we christen it GA.)
I find it interesting that you choose to inflict the code on those with
the "resources" to make it work.
Does that mean, until it's been dropped (ignorantly) into production on
high-end machines by less-cautious admins, that we don't expect to find
out if it works or not?
What *IS* experimental ... that is what I'm asking. LDAP in 2.2 isn't.
Cache isn't any longer. mod_dbd or mod_filter? I dunno - haven't spent
time there, but seriously why ship code that doesn't work, let's ship
code that ""works"" and fix the bugs as they arrive. Support it or do
not, that's fine, but once supported let's put our collective energies
behind it.
There is a natural threshold of effort above which people are far less
likely to take the time out to help. An svn update is easy. Checking out
and building an entirely separate sandbox is above the threshold for
most people.
I seriously -don't- expect the casual user to grab from svn. That's
what svn snapshots, are for, that they can easily extract themselves.
And this is why I suggested we seriously consider a CPAN-like proposal
by sctemme ... and nobody seemed to grok this...
..HE DOES NOT PROPOSE A F'ING LIST OF MODULES...
...a cpan like facility is an entire mechasim for obtaining and dropping
into your build all of the "other" modules that interest you. Trivial,
no extra knowledge of what packages to download, which URL's to use.
Yes, search.cpan.org is interesting, but if you thought that was what I
had suggested, e.g. modules.apache.org, you missed it entirely.
Witness the proxy changes to v2.0 in the proxyreq branch. The nature of
the changes meant that a branch was 100% necessary, but the side effect
was that it took far longer to review the changes than other code in the
server. It amounted to a significant deviation from normal development
patterns to test it properly, and so reduced the audience significantly.
Ack. I would have voted for the original proxy to be re-added (and in
fact, if you look back, odds on, I did.) Hindsite is a funny thing :)
I would have probably voted for 2.0.39, not 2.0.35, to be GA ;-)
And, although I've hinted that mod_proxy was sub-release quality, it was
in fact released in modules/proxy/. Yes, parts had to be rewritten from
scratch. You are probably a victim of my ire over mod_rewrite, of who's
rewrite caused even more pain and constranation, and both modules were
sufficiently complex to "expect" bugs from a major effort.
Yes - cache was a *supported* 1.3 feature. We axed it, while stating
that "This version is the best available flavor of Apache http Server"
or something close to it. So sure, folks EXPECTED it to do what 1.3
did, including caching. And should they not have?
This is why experimental must live. :)
Ok... rereading...
rereading...
rereading...
Still not seeing how your post justifies modules/experimental/...
could you explain it again in a different way?
Only Kevin has produced an interesting argument that I'm honestly quite
drawn to, and JimJ has played on the concept in his posts.
But on the whole, you haven't justified putting trash (well, it almost
works) into modules/experimental/, as opposed to putting finished code
(hmmm... this might not solve everyone's problems, but it's solid and
it works) into a proper modules/FOO/ directory that corresponds to the
function of that module.
Bill
