William A. Rowe, Jr. said: > 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.)
Nice in theory, doesn't work in practice. The LDAP code had very subtle flaws in it that only surfaced once people outside the ASF starting experimenting with it. LDAP deserved it's experimental status, even though it was originally a very popular and well used module for v1.3. The v2.2 refactoring was in response to bugs posted against v2.0. If LDAP wasn't available in a form that end users could try out, we would have never found out the refactoring was necessary. > I find it interesting that you choose to inflict the code on those with > the "resources" to make it work. And who else would I "inflict" the code on? I don't have a Windows machine nor the resources to code for it, and I'm not about to pretend that every line of code that I write will compile and run warning free on every platform just because it compiles and runs warning free on my platform. New code needs incubation. > 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? No, it's dropped into test by admins trying to find out whether this particular feature solves their need or not. Experimental features are off by default, and not available in vendor supplied distributions by default. If an admin wants to use them, they need to build the code themselves and actively switch the feature on, and it's kinda hard to miss the warnings along the way. If it _is_ possible to miss a warning along the way, then that is a problem that needs fixing. > What *IS* experimental ... that is what I'm asking. The httpd incubator. > LDAP in 2.2 isn't. > Cache isn't any longer. They graduated. > 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. All the code is supported - including experimental code. If experimental code is unsupported (aka abandoned), then move the code out of experimental. We need a clearly defined method to tell the end user some code is not battle tested. >> 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. I wasn't referring to the casual user, I am referring to users who normally work from svn. I have an httpd v2.0 tree that's already set up, configured and ready to test stuff. Testing the proxyreq branch meant I had to check out a brand new tree, go through the setup from scratch, deploy it, configure it, then test it worked, then delete it all at the end. I made time to do this because of the urgency involved, but under normal circumstances the testing would have been delayed as by bottomless inbox and keeping the clients happy took priority. > 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. I understand fully what was proposed, but a CPAN like proposal does not solve the problem of dealing with identifying and making available code that needs battle testing / incubation. A new module delivery mechanism is not an incubator. > 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. The entire underlying architecture of httpd had changed, on which proxy depended. Proxy had to be almost completely rewritten from scratch, there was no choice, as the new filter mechanism fundamentally changed how proxy worked. As filters were developed in the main v2.0 tree, so was proxy. Proxy existed in v1.3, there was no point in moving proxy from modules/proxy to modules/experimental and then back again, the whole of httpd v2.0 was experimental at that point. Cache and LDAP are both additions, and so went into experimental. > 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? You're 100% right they should have. v2.0 should have been released when cache was ready, but the people doing the releasing didn't rate cache as important enough. Hindsight and all that. > Still not seeing how your post justifies modules/experimental/... > could you explain it again in a different way? httpd needs an incubator to develop small well defined modular features, and provide a meaningful distribution mechanism to get this incubated code to a wide audience. Up till now, experimental is that mechanism. You have proposed that experimental be removed, but by doing that you have removed the incubator. You have not yet proposed a process that will replace the incubator. > 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. You're right, I haven't justified putting trash into the tree, and I won't either. Regards, Graham --
