Re: Issues for 2.1.8
I thnk we all understand what Bill is saying, there is simpy normal, healthy disagreement. That's good. Look... every now and then we ALL get the urgre to clean up the room and move the furniture around and get the dirty laundry off the floor. Bill thinks modules/experimental is part of the 'cleanup' that he thinks should happen. More power to him. My 2 cents jives with Jim J, Brad and others. Healthy discussion and it's nice to see... but I don't think it's broken. Don't fix it. Clean it up, sure. Try and make it 'tidier' and get rid of shit that isn't going anywhere and nobody seems to care about, but don't DEEP-SIX it. Even if the directory is EMPTY for any particular release I still think it is an ENTICEMENT to CONTRIBUTE. It's very presence in the tarball is an INVITATION for those who, as Shakespeare would say, are "Seeking the bubble reputation even in the cannon's mouth". It says "Can you think of something useful that we haven't yet?". As stated before... it's just a perfect symbol of the way everyone should look at Apache... that is has NEVER been 'finished' or 'perfect', is not now, and never will be. It is a total 'work in progress' at all times. It is, in essence, a living 'experiment' unto itself. That's all. Kevin Kiley In a message dated 9/22/2005 11:18:35 AM Central Daylight Time, [EMAIL PROTECTED] writes: But what you are suggesting is exactly what has proven NOT to work. Moving modules into sub-projects has already proven to kill the module. It needs to be included in the release. That is an essential part ofthe incubation process. modules/experimental WORKS!! That fact hasalready been proven true by the number of modules that have passedthrough modules/experimental and graduated to become standard modules. If it isn't broken, then why are you trying to fix it with somethingthat we already know DOESN'T work.Brad
Re: Issues for 2.1.8
>>> On 9/22/2005 at 9:20 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > We have one, FYI... http://svn.apache.org/repos/asf/incubator/httpd/ > currently empty as there are no modules or subprojects in incubation > at this moment. > > Bill But what you are suggesting is exactly what has proven NOT to work. Moving modules into sub-projects has already proven to kill the module. It needs to be included in the release. That is an essential part of the incubation process. modules/experimental WORKS!! That fact has already been proven true by the number of modules that have passed through modules/experimental and graduated to become standard modules. If it isn't broken, then why are you trying to fix it with something that we already know DOESN'T work. Brad
Re: Issues for 2.1.8
Ranier Vilela wrote: William "Bill Hitcock" A. Rowe, hates stable apache releases? Au contraire, I'm in the small minority who believes only stable code should exist in a stable release tarball.
Re: Issues for 2.1.8
Graham Leggett wrote: 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. Badda bing badda boom - I think you've nailed it on the head :) 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. Now -that- is something to discuss ... and I'll drop this thread on that very productive note until next week. We have one, FYI... http://svn.apache.org/repos/asf/incubator/httpd/ currently empty as there are no modules or subprojects in incubation at this moment. Bill
Re: Issues for 2.1.8
William A. Rowe, Jr. escreveu: 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 William "Bill Hitcock" A. Rowe, hates stable apache releases? Please vote. P.S: From a new, new, very new "timer"
Re: Issues for 2.1.8
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 po
Re: Issues for 2.1.8
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
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: Exactly my point. This is what sandboxes are for. Not production. Sandboxes are for refactoring. An entire sandbox for a single feature like a module is like hammering in a nail with a sledgehammer. experimental/ is a sandbox for small well defined features where running a separate sandbox is overkill. You argue that this produces good results. So let's take one bug... ASF Bugzilla Bug 16696 Errore Windows Xp with Cache Opened: 2003-02-03 11:26 When I set the directives how the manual say: CacheEnable disk / I continuosly have a Window error message (Si è verificato un errore In Apache HTTP server. L'applicazione verrà chiusa: It was an error on Apache HTTP server. The application will be close). Thank So let's see what was done... Additional Comment #1 From Paul Querna 2005-06-03 02:47 Can you please try this with 2.0.54? This was productive? No 'need info', or 'what does your error log say?' or 'what happens if...?' questions for over two years? Bugs like this largely get ignored as they contain no information, no backtrace, or any other useful information. They are not ignored maliciously, they are ignored because the next bug along did contain complete information, so that bug got handled first. This isn't the audience we need 'testing' experiments; the simple fact is that there is no 'community' outside of the devs to handle this. If you hack at an 'experimental' module, are you willing to subscribe and handle users@ to guide them in YOUR experiment? This is the exact very audience we need 'testing' experiments. Where in the bug report did the end user express their frustration or dissatisfaction that the cache module didn't work? Nowhere. They tried it on Windows, it didn't work for them, and they took time out to log a bug for it. There are no "me too"s attached to the report, so it's safe to assume the problem went away. The point is an end user bothered to try it out and send feedback, and that is why we have cache today. If it's not in the tree, it does not exist. We have learned this from past experience. And we learned that users, even with big warnings (hmmm... does perchild sound familiar?) expect our code to work, at least, do something useful. In fact, perchild proved WHY we should not do this. It -was- in the tree and yet it also did not exist. All we gained from perchild was ill-will twords us, the developers and foundation. Experiments are only useful while someone is willing to stand behind them. Here at the ASF, 'someone' means at miminum, a small core of developers. If nobody is standing behind the module, it will mean that nobody will object if someone says "perchild is causing grief and seems unsupported, any objection to putting it in an attic?". You are 100% right that experimental is not the place for abandoned modules. cache attracted developers (as you observed above) and so was a success in the release tarball, but managed to piss off alot of users who had grabbed 2.0 expecting to be able to deploy a caching proxy without all that much trouble. People were disappointed because v2.0 didn't have a cache full stop. The actual cache module only came much later. v2.0 was a _big_ jump from v1.3. The v2.0 proxy was a complete rewrite using an entirely new architecture, and when v2.0 went GA cache was nowhere near ready, however cache was not considered a showstopper. 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. 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. 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. This is why experimental must live. :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: > > Ack, but we've agreed what shipped in 2.2.0 stays in 2.2.x - which is > why I'd rather see us add 'finished' modules to 2.2.12, for example, > as opposed to having a completely orphaned module in 2.2.24 still > creating noise. > modules/supported modules/beta modules/discontinued ? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Issues for 2.1.8
Jim Jagielski 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 :) I agree with your point that experimental has the potential of being abused, and to end up as a dumping ground for modules and code that aren't up to snuff, but "we" still want out there. So for us to have an experimental classification, we need to do some due-diligence and not be afraid to say "this has been experimental too long; we either fix/promote it, or we drop it." Ack, but we've agreed what shipped in 2.2.0 stays in 2.2.x - which is why I'd rather see us add 'finished' modules to 2.2.12, for example, as opposed to having a completely orphaned module in 2.2.24 still creating noise. Bill
Re: Issues for 2.1.8
>>> On Wednesday, September 21, 2005 at 9:19 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > > Exactly my point. This is what sandboxes are for. Not production. You > argue that this produces good results. So let's take one bug... > >ASF Bugzilla Bug 16696 Errore Windows Xp with Cache >Opened: 2003-02-03 11:26 > >When I set the directives how the manual say: > CacheEnable disk / >I continuosly have a Window error message (Si è verificato un errore >In Apache HTTP server. L'applicazione verrà chiusa: It was an error >on Apache HTTP server. The application will be close). >Thank > > So let's see what was done... > >Additional Comment #1 From Paul Querna 2005-06-03 02:47 > >Can you please try this with 2.0.54? > > This was productive? No 'need info', or 'what does your error log say?' > or 'what happens if...?' questions for over two years? So you took one bug and tried to apply its effects across the board. What about all of the bugs that were helpful in making mod_cache usable? The worst that happened is that we ended up with a bug in bugzilla that needed to be cleaned out. So what? > I'm not suggesting we will get everything right from the starting line. > But until the module is useful, it doesn't belong in svn, but inside > a sandbox. And once it is useful, it belongs in trunk. Then if the > authors, or others, are still dubious about it's behavior, we should > decide if (like perchild) it's beyond redemption for the coming release, > and just defer it for the next release. I believe that a module like mod_cache absolutely belongs in svn and the release. In the case of mod_cache there was a community behind it and it demanded visibility and testing in order to move it to a non-experimental state. If it had been pushed off to some sandbox somewhere, our users would still be waiting for it. That is a lesson that was learned from auth_ldap. Granted not all modules are like mod_cache. But that is something that should be decided on a case by case basis through discussion on the list. > cache attracted developers (as you observed above) and so was a success > in the release tarball, but managed to piss off alot of users who had > grabbed 2.0 expecting to be able to deploy a caching proxy without all > that much trouble. perchild lost it's appeal and never evolved, pissing > off many more users and spawning competing forks of a multiple-user, > multiple-vhost worker MPM models. We aren't here to make everybody happy all of the time. So it pissed off some users. Those that stuck with it, helped to produce something that is now a standard module. The important point is that mod_cache got the feedback it needed to improve it. Even if that feedback came from a pissed off user. > > 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 :) > > Bill I haven't seen experimental being abused in this way in the past so why would you assume that it would be abused this way in the future. The list still has to vote and decide what goes into experimental and what doesn't. Just like any other project decision, you have to trust the collective to do the right thing. Brad
Re: Issues for 2.1.8
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 :) > I agree with your point that experimental has the potential of being abused, and to end up as a dumping ground for modules and code that aren't up to snuff, but "we" still want out there. So for us to have an experimental classification, we need to do some due-diligence and not be afraid to say "this has been experimental too long; we either fix/promote it, or we drop it." In that way, experimental is almost like a beta classification... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Issues for 2.1.8
Graham Leggett wrote: The problem is that cache in 2.0 never worked at all once it 'filled up' - showing the author truly never took the module through it's paces. Cache was built from scratch in the source tree in the experimental directory, and is only nearing completion now. Cache has had many authors during it's stay in the experimental (and now cache) directories, so to say "the author never took the module through it's paces" makes no sense whatsoever. Exactly my point. This is what sandboxes are for. Not production. You argue that this produces good results. So let's take one bug... ASF Bugzilla Bug 16696 Errore Windows Xp with Cache Opened: 2003-02-03 11:26 When I set the directives how the manual say: CacheEnable disk / I continuosly have a Window error message (Si è verificato un errore In Apache HTTP server. L'applicazione verrà chiusa: It was an error on Apache HTTP server. The application will be close). Thank So let's see what was done... Additional Comment #1 From Paul Querna 2005-06-03 02:47 Can you please try this with 2.0.54? This was productive? No 'need info', or 'what does your error log say?' or 'what happens if...?' questions for over two years? This isn't the audience we need 'testing' experiments; the simple fact is that there is no 'community' outside of the devs to handle this. If you hack at an 'experimental' module, are you willing to subscribe and handle users@ to guide them in YOUR experiment? I'm not suggesting we will get everything right from the starting line. But until the module is useful, it doesn't belong in svn, but inside a sandbox. And once it is useful, it belongs in trunk. Then if the authors, or others, are still dubious about it's behavior, we should decide if (like perchild) it's beyond redemption for the coming release, and just defer it for the next release. The folks were thinking of a mechanism to bring in third party mods. But what about our own, experimental, somewhat unstable, or simply still moving target sandboxes, which keep growing new features too quickly? If it's not in the tree, it does not exist. We have learned this from past experience. And we learned that users, even with big warnings (hmmm... does perchild sound familiar?) expect our code to work, at least, do something useful. In fact, perchild proved WHY we should not do this. It -was- in the tree and yet it also did not exist. All we gained from perchild was ill-will twords us, the developers and foundation. Experiments are only useful while someone is willing to stand behind them. Here at the ASF, 'someone' means at miminum, a small core of developers. cache attracted developers (as you observed above) and so was a success in the release tarball, but managed to piss off alot of users who had grabbed 2.0 expecting to be able to deploy a caching proxy without all that much trouble. perchild lost it's appeal and never evolved, pissing off many more users and spawning competing forks of a multiple-user, multiple-vhost worker MPM models. 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 :) Bill
Re: Issues for 2.1.8
Mads Toftum wrote: On Tue, Sep 20, 2005 at 10:58:16PM -0500, William A. Rowe, Jr. wrote: Because --with-foo / --without-foo syntax gives **NO** indication to the user, or indication from the user, that they are willing to use experimental code. So your concern is not really that the modules are there, but rather that they're not clearly marked as experimental? * /modules/experimental/ is not a helpful layout, the modules belong within their functional/behavioral choice of /modules/footype/ dirs. Jim's proposal of modules/experimental/foo/ v.s. modules/stable/bar/ makes alot of sense. * what do we gain from the 'experimental' designation? I've already aruged not to ship unstable code in a GA. What if we added the experimental placeholder, and a second 'experimental' tarball if we want users to pick up all the experimental/new modules? This could include other httpd subproject modules, as well, and fit into Kevin's comment that some users just want to peek behind the curtain and see what is coming up. * ...but I'm not sure we even agree on what experimental actually means. I'm not even sure there is agreement between the members of the 'ship experimental modules in our releases' croud. Let's back up and define it? I'm guessing there are more than one class of 'experimental' modules ... Then how about grouping the modules in an experimental section of --help output? Or to take it even further, perhaps a --enable-experimental flag? If we had a worthwhile definition of 'experimental', I'd be +1, but I'm not sure experimental is the phrase we are looking for. I'll toss up an example. /examples/ modules should be exactly that, worthless in a running server, but providing documentation by example. Hmmm... perhaps these belong somewhere in the TL /docs/ tree instead? What about bucketeer and other production-useless, but test-useful modules? Perhaps --with-tests would be good to enable these rather than suggesting they are experiments? Bill
Re: Issues for 2.1.8
>>> On Tuesday, September 20, 2005 at 9:58:16 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Jim Jagielski wrote: >> What is the real issue with having an experimental module subdir? >> If it makes it easier for people to use it or try it out, then >> why not? > > Because --with-foo / --without-foo syntax gives **NO** indication to > the user, or indication from the user, that they are willing to use > experimental code. > But why does that matter? So I build a module that is experimental. Nothing is going to happen until I use it and in order to use it I will probably have to look at the documentation. In fact even before I decide that it is something useful to me, I will have to look at the docs. The docs clearly state that the status is experimental. Brad
Re: Issues for 2.1.8
On Sep 20, 2005, at 6:03 PM, William A. Rowe, Jr. wrote: I thank everyone who's voicing an opinion - it's very important that we come to concensus. I'm incredibly concerned however that most votes on this issue are from our 'newcomers' - those without the experience of the pains and problems encountered in previous Apache release cycles. I appreciate all of the enthusiasm, drive and forward momentum! But I'm worried that a policy we arrived at, following the contentious and problematic 2.0 GA, would be tossed aside so quickly without any feedback from our 'older' devs. So this message is not at our newcomers, welcome to you all. Rather, I'm addressing this post to our 'old timers' who did struggle through the 1.3.x and 2.0.x GA process, to add your thoughts and observations. I recall the days when all modules were simply lumped in the ./src/ directory :) Anyway, the 'experimental' module directory, to me, has always been a sort of "preview look" into what's new and exciting in httpd-land. They are modules that people can use and play with, and be part of the development effort with. It may be that we simply need to restructure the module dir concept, with 2 dirs under modules: modules/supported (or modules/production ?) modules/experimental (modules/in-development ?) you get the idea. We then have the same layout under each, so that there is a modules/experimental/loggers directory and a modules/supported/loggers one for example. configure is made aware of the "noteworthiness" of the modules/experimental directory and prints out a little disclaimer that "you have selected an experimental/in-development module; please understand that this module has not been completely tested, but we welcome your feedback, bug-reports and, especially, your patches!"
Re: Issues for 2.1.8
Nick Kew wrote: > > > > > * mod_dbd is new but is going to be Big and Important :-) And it's > > > descended from a family of modules that have been in production > > > for a couple of years. > > > > Question; does this require the apr-util features in 1.3? > > 1.2 or higher. > > I should add a little more about it. It is descended from a family of > connection pooling modules built around apr_reslist. I've been using > it two years myself, and some *very* big household name sites have been > using it for some time. What is new is the apr_dbd/mod_dbd split, > which was arrived at by discussion here a little under a year ago. > So, like proxy, cache, etc, it's really a refactoring of existing stuff. > > Oh, and let me repeat: mod_dbd offers the biggest advance in applications > development since mod_perl gave us the beginnings of LAMP ten years ago! > Remember the late 1980s, when every PC application came on a huge > stack of floppies, comprising *mostly* just a bunch of drivers for hundreds > of different printers? Database handling in Apache 1.x and 2.0 looks like > that: every module or application that wants a database has to reinvent > that wheel - and then reinvent connection pooling on top of it if it wants > more scalability! > Are you running for office? :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: > > Jim Jagielski wrote: > > What is the real issue with having an experimental module subdir? > > If it makes it easier for people to use it or try it out, then > > why not? > > Because --with-foo / --without-foo syntax gives **NO** indication to > the user, or indication from the user, that they are willing to use > experimental code. > Certainly configure can be adjusted to print that fact... > It also adds additional headaches. mod_dumpio, for example, clearly > is a logger. Why, as a new module, would one look for it to be within > 'experimental' as opposed to it's purpose (logging). > IMO, the easier we make it for end-users and developers to try out modules that haven't enjoyed a large amount of "real world usage" time, the better. How about instead of 'experimental' something like 'in-development' or 'nrfpty (not ready for prime time yet) :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: Please don't confuse my weeks of effort, originating from my manual inspection (not automation) of the 'unusual' traffic patterns, combined with third party observations in the security community, with any detailed review of mod_proxy as a whole! If you believe that I've had a major impact on the stability or quality of the entire proxy framework you are demonstrating that you truly don't know 5% of the lines within the proxy module and are entirely ignorant of the many complaints in our bugzilla w.r.t. various specific behaviors. I was the one who rewrote proxy for v2.0, and coordinated a lot of the early bugfixes to it before moving onto the LDAP stuff, after which others took over proxy. I think I still know that code well enough to know that it works. The problem is that cache in 2.0 never worked at all once it 'filled up' - showing the author truly never took the module through it's paces. Cache was built from scratch in the source tree in the experimental directory, and is only nearing completion now. Cache has had many authors during it's stay in the experimental (and now cache) directories, so to say "the author never took the module through it's paces" makes no sense whatsoever. Yes, yes, yes!!! Now let's discuss incubations processes - in yet another thread unrelated to general availability release - and find the way that 'cool new stuff' will truly be tested, fixed and finally brought into the core :) Why? We already have an incubation process. If that process has flaws, lets fix those flaws. If the flaw is that --with-foo doesn't show the experimental status, then lets update the comment for that module in ./configure --help to say "experimental". Beyond that it's user beware. So let's engage Mr. Temme and his idea of a CPAN-ish modules facility? We already have a basic one (modules.apache.org). While a CPAN-ish one may be a better modules.apache.org, it still does not fix the perception that the tarball is "Apache" code, and modules/CPAN-ish is "external" code. The folks were thinking of a mechanism to bring in third party mods. But what about our own, experimental, somewhat unstable, or simply still moving target sandboxes, which keep growing new features too quickly? If it's not in the tree, it does not exist. We have learned this from past experience. There are 7 LDAP modules in modules.apache.org. The end user needs an LDAP module - in most cases where the use has general needs, the user is going to want to install the official Apache module, as they don't have time to evaluate 7 different solutions to their problem. But nothing in the list of 7 modules suggests that any of these modules is an official Apache one - why would the end user think that? The majority of end users are going to experience httpd from a vendor supplied package anyway, and are going to use what their vendor installs. Regards, Graham --
Re: Issues for 2.1.8
On Tue, Sep 20, 2005 at 10:58:16PM -0500, William A. Rowe, Jr. wrote: > Because --with-foo / --without-foo syntax gives **NO** indication to > the user, or indication from the user, that they are willing to use > experimental code. That's easy to fix, we can do the same thing we do for the experimental MPM's and warn loudly at configure time. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Issues for 2.1.8
On Tue, Sep 20, 2005 at 10:58:16PM -0500, William A. Rowe, Jr. wrote: > Because --with-foo / --without-foo syntax gives **NO** indication to > the user, or indication from the user, that they are willing to use > experimental code. > So your concern is not really that the modules are there, but rather that they're not clearly marked as experimental? Then how about grouping the modules in an experimental section of --help output? Or to take it even further, perhaps a --enable-experimental flag? vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: Issues for 2.1.8
Graham Leggett wrote: The majority of bugs in the v2.0 proxy code originated when a vendor of an HTTP protocol testing suite added each individual protocol violation they picked up to bugzilla. This makes proxy one of the most scrutinised pieces of code in the server. Many of these violations were fixed, with the more minor ones being still outstanding. Please don't confuse my weeks of effort, originating from my manual inspection (not automation) of the 'unusual' traffic patterns, combined with third party observations in the security community, with any detailed review of mod_proxy as a whole! If you believe that I've had a major impact on the stability or quality of the entire proxy framework you are demonstrating that you truly don't know 5% of the lines within the proxy module and are entirely ignorant of the many complaints in our bugzilla w.r.t. various specific behaviors. * ssl - I'm under the impression (and could be wrong) that most of the ssl issues are unusual, more experimental configurations using features that even the mod_ssl project doesn't build by default ;-) So they are new. Why does that make them experimental? because the author hacked them in as a cool idea, while not entirely investigating all of their side effects, and the mod_ssl community had burried them within #ifdef SSL_EXPERIMENTAL_XXX feature flags? Remember that there is a big difference between "works" and "works well". Cache for example has worked well enough for light load servers for a long time, but cache is not (yet) good enough for CNN. The problem is that cache in 2.0 never worked at all once it 'filled up' - showing the author truly never took the module through it's paces. We need an incubation process of some kind for new code that people who are brave enough might try and use in production, without having to jump the whole way in and install trunk onto production. That process up till now has been the experimental directory. Without that directory, we would have had no ldap and no cache. Yes, yes, yes!!! Now let's discuss incubations processes - in yet another thread unrelated to general availability release - and find the way that 'cool new stuff' will truly be tested, fixed and finally brought into the core :) If you want to commit non-working, experimental code, then we can always roll another sandbox to 'play' in until there is something worthy of inclusion in trunk. A sandbox nobody can play in, because it implies running a development version of the entire webserver, rather than just a development/experimental version of a single feature. So let's engage Mr. Temme and his idea of a CPAN-ish modules facility? The folks were thinking of a mechanism to bring in third party mods. But what about our own, experimental, somewhat unstable, or simply still moving target sandboxes, which keep growing new features too quickly? If we are our own first consumer of a CPAN-ish Apache modules facility, I'll wager we would do a better job anyways :) Bill
Re: Issues for 2.1.8
Jim Jagielski wrote: What is the real issue with having an experimental module subdir? If it makes it easier for people to use it or try it out, then why not? Because --with-foo / --without-foo syntax gives **NO** indication to the user, or indication from the user, that they are willing to use experimental code. It also adds additional headaches. mod_dumpio, for example, clearly is a logger. Why, as a new module, would one look for it to be within 'experimental' as opposed to it's purpose (logging). The problem is that apache config syntax, and our directory structure bear no relation to each other. YOU the developer understand that the code in experimental/mod_foo.c isn't cooked, but the USER sees none of that when they invoke --with-foo. This is all about developers who want testers to adopt code inflicting it on users who don't know that it might not be quite ready for them to rely upon, and was only provided for them to experiment with. Bill
Re: Issues for 2.1.8
> Jim J. wrote... > > People will not use it unless they can *really* trust a module. Simply> expecting people to migrate to it because of the theoretical> benefits isn't quite wise, until it has proven itself. The idea is> to make it easier for people to have access to a module, use it> and test it. More exposure means more feedback and more bug-fixes> (hopefully :) ). But simply "being there" isn't enough to> expect world-wide usage, but "being there" is enough to hope> that people have easier access to play around with it. Well said, Jim. The experimental modules section of the general release has always been the 'enticing' part of the tarball and the "You can play too" advertisement. It is the constant reminder that Apache had never been, is not now, and will never be FINISHED. You need to keep everything you've got to prevent the trend of the last few years to keep from "closing in" and losing your ability to attract new talent into your developer pool. Yours Kevin Kiley
Re: Issues for 2.1.8
On Tuesday 20 September 2005 23:44, William A. Rowe, Jr. wrote: > Nick Kew wrote: > > The highest numbers of bugs are for the more complex subsystems. > > For example, cache, ldap, ssl, proxy - which are NOT currently in > > experimental. > > Whoa... > > * cache - that's experimental. > * ldap - that's experimental. Hmmm, must be too long since I looked at 2.0 areas other than those I've worked actively on - like proxy :-) > > * mod_charset_lite has been there a long time. It could use more work > > (configuration is very limiting) but is useful within its > > limitations. > > So it's no longer an experiment; move it to modules/filters/ +1 > > * mod_filter has been there a while and got some positive feedback. > > But since it's only in 2.1 (or 2.0+power-user-hack), that's limited. > > * Event MPM - similar situation to mod_filter. > > So they are new. Why does that make them experimental? If they work, > and will continue to be maintained, then move them to the right place. Well really they're beta. We think they work, but we'll only find out for sure when the bug reports roll in. > > * mod_dbd is new but is going to be Big and Important :-) And it's > > descended from a family of modules that have been in production > > for a couple of years. > > Question; does this require the apr-util features in 1.3? 1.2 or higher. I should add a little more about it. It is descended from a family of connection pooling modules built around apr_reslist. I've been using it two years myself, and some *very* big household name sites have been using it for some time. What is new is the apr_dbd/mod_dbd split, which was arrived at by discussion here a little under a year ago. So, like proxy, cache, etc, it's really a refactoring of existing stuff. Oh, and let me repeat: mod_dbd offers the biggest advance in applications development since mod_perl gave us the beginnings of LAMP ten years ago! Remember the late 1980s, when every PC application came on a huge stack of floppies, comprising *mostly* just a bunch of drivers for hundreds of different printers? Database handling in Apache 1.x and 2.0 looks like that: every module or application that wants a database has to reinvent that wheel - and then reinvent connection pooling on top of it if it wants more scalability! > Of course auth, and proxy refactoring may still have (big) flaws. No > problem, that's what the alpha/beta/GA cycle is ment to catch & address. That argument applies equally to filter, event and dbd. And to a lesser extent everything else that's changed since 2.0 and APR-0.9. -- Nick Kew
Re: Issues for 2.1.8
OK so here you go (funny, I guess I now consider myself an old-timer). I am +1 for including experimental modules in the stable releases mainly because of my experience with auth_ldap and mod_ldap which I consider to be very successful. Back in 2001 the dev list, for some odd reason (and you can read the archives for more details), voted to remove auth_ldap and mod_ldap out of the core project and into it's own sub-project. During the next 10 months, all development/maintenance of the module ceased. Moving these modules into a sub-project with no visibility and no release mechanism, essentially killed them. In Aug. of 2002 after some discussion on the list, I proposed to move auth_ldap and mod_ldap back into the core project but as experimental modules. Once they were moved back, myself, Graham and others started working on them with the goal in mind of getting them stabilized and out of experimental. With the release of 2.2, that goal will be accomplished. IMO, moving auth_ldap and mod_ldap back into the experimental directory and releasing them in the tarball, provided them with the opportunity to be developed, tested, stabilized and to become standard modules. Allowing them to be released along side of the standard modules gave them the visibility and testing they needed to identify stabilization issues and other bugs that needed to be addressed before they could be promoted out of experimental. It is true that auth_ldap and mod_ldap are still classified as experimental in the 2.0 branch but this is not because of stability issues or anything else other than circumstances. The authentication refactoring essentially caused a fork in the auth_ldap code. All new development continued in trunk even though bug fixes where still being backported to 2.0. They are still experimental in 2.0 only because there is no point in moving them with the current release expectation of 2.2 where they will be classified as standard modules. IMO, we need to continue to do this with other modules like mod_dbd, mod_filter, etc. It does the project more good to keep the user engaged in new stuff allowing it to move forward and stabilize newer functionality. Brad >>> On Tuesday, September 20, 2005 at 4:03:04 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Colm MacCarthaigh wrote: >> On Tue, Sep 20, 2005 at 02:01:07PM -0700, Paul Querna wrote: >> >>>So, lets change the VERSIONING file/policy. Experimental Modules will >>>be included in the stable branch. Majority Agree? >> >> +1 > > I thank everyone who's voicing an opinion - it's very important that we > come to concensus. > > I'm incredibly concerned however that most votes on this issue are from > our 'newcomers' - those without the experience of the pains and problems > encountered in previous Apache release cycles. I appreciate all of the > enthusiasm, drive and forward momentum! But I'm worried that a policy > we arrived at, following the contentious and problematic 2.0 GA, would > be tossed aside so quickly without any feedback from our 'older' devs. > > So this message is not at our newcomers, welcome to you all. Rather, > I'm addressing this post to our 'old timers' who did struggle through > the 1.3.x and 2.0.x GA process, to add your thoughts and observations. > > Bill
Re: Issues for 2.1.8
Nick Kew wrote: > > I agree about both of those. And I'd say the same even more strongly for > mod_dbd, simply because it (or whatever it becomes when updated in the > light of real-life experience) should become the basis of a new generation > of applications. If it's there, it'll start to permeate the Usual Suspects > like mod_perl. If not, we'll still have the old situation of Perl, Python, > PHP, Tcl, Authentication, Logging etc each maintaining its own separate > database connections, and having to reinvent the connection pooling > wheel if they want to if they want to improve scalability. > People will not use it unless they can *really* trust a module. Simply expecting people to migrate to it because of the theoretical benefits isn't quite wise, until it has proven itself. The idea is to make it easier for people to have access to a module, use it and test it. More exposure means more feedback and more bug-fixes (hopefully :) ). But simply "being there" isn't enough to expect world-wide usage, but "being there" is enough to hope that people have easier access to play around with it. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: * cache - that's experimental. * ldap - that's experimental. These are experimental in 2.0 only, they have been promoted in 2.1/2.2. * proxy - that SHOULD have stayed experimental, it sure wasn't cooked when we reimported it into 2.0. [Newcomers, do be aware that we punted proxy OUT of httpd 2, it was so horrid. It was significantly refactored, and reintroduced, but brought back as many new bugs as the refactoring eliminated.] I have lots of proxy installs that to date have worked with zero hassle for years. The majority of bugs in the v2.0 proxy code originated when a vendor of an HTTP protocol testing suite added each individual protocol violation they picked up to bugzilla. This makes proxy one of the most scrutinised pieces of code in the server. Many of these violations were fixed, with the more minor ones being still outstanding. * ssl - I'm under the impression (and could be wrong) that most of the ssl issues are unusual, more experimental configurations using features that even the mod_ssl project doesn't build by default ;-) So they are new. Why does that make them experimental? Because we don't yet know if they work well enough to be useful to end users - only end users can tell us that, and end users don't use code that isn't there. Remember that there is a big difference between "works" and "works well". Cache for example has worked well enough for light load servers for a long time, but cache is not (yet) good enough for CNN. We need an incubation process of some kind for new code that people who are brave enough might try and use in production, without having to jump the whole way in and install trunk onto production. That process up till now has been the experimental directory. Without that directory, we would have had no ldap and no cache. Please lets bear in mind that a lot of code marked stable is really just as new and untested, and going through the same process. Obvious cases: proxy, cache and ldap have been hugely re-hacked since anything in 2.0. Proxy got a load balancer hook and a new protocol module, otherwise the code is largely the same if you haven't switched either of these new things on. Cache and LDAP got a huge rework, thus their graduation from experimental. If you want to commit non-working, experimental code, then we can always roll another sandbox to 'play' in until there is something worthy of inclusion in trunk. A sandbox nobody can play in, because it implies running a development version of the entire webserver, rather than just a development/experimental version of a single feature. Regards, Graham --
Re: Issues for 2.1.8
What is the real issue with having an experimental module subdir? If it makes it easier for people to use it or try it out, then why not? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Issues for 2.1.8
Nick Kew wrote: So, lets change the VERSIONING file/policy. Experimental Modules will be included in the stable branch. Majority Agree? +1, qualified by: Let's *prune* /experimental/ actively. Any module that's attracting bug reports/trouble that aren't getting fixed goes out. Modules that are getting used and properly maintained get promoted. Wrong again - once it has shipped as 2.2.0, it will stay in 2.2.x, no matter if it's getting any better or not. This is solidly codified in our VERSIONING policy. The confusion here, is that there should be no more /experimental/, period. If it isn't gone, I'll svn rm it myself on friday, after moving each module living under the long abandoned /experimental/ tree into the proper categorical modules/xxx/ home dir. Then, we can decide which modules, based on the already-rolled alphas, just aren't ready for prime time and should be axed before beta. Bill
Re: Issues for 2.1.8
Nick Kew wrote: The highest numbers of bugs are for the more complex subsystems. For example, cache, ldap, ssl, proxy - which are NOT currently in experimental. Whoa... * cache - that's experimental. * ldap - that's experimental. * proxy - that SHOULD have stayed experimental, it sure wasn't cooked when we reimported it into 2.0. [Newcomers, do be aware that we punted proxy OUT of httpd 2, it was so horrid. It was significantly refactored, and reintroduced, but brought back as many new bugs as the refactoring eliminated.] * ssl - I'm under the impression (and could be wrong) that most of the ssl issues are unusual, more experimental configurations using features that even the mod_ssl project doesn't build by default ;-) Regarding the new modules, there are some bug reports which mod_filter solves, but AFAIK none for mod_filter itself, nor for mod_dbd or mod_charset_lite (bugzilla is timing out right now, so I can't check). mod_charset_lite certainly isn't really an experiment - it's simply very lightweight, and can't be built without iconv (or apr_iconv) support. We should prune out things that are unmaintained - especially perchild - but not things that are new. [...] So taking the useful modules currently marked /experimental/ * mod_charset_lite has been there a long time. It could use more work (configuration is very limiting) but is useful within its limitations. So it's no longer an experiment; move it to modules/filters/ * mod_filter has been there a while and got some positive feedback. But since it's only in 2.1 (or 2.0+power-user-hack), that's limited. * Event MPM - similar situation to mod_filter. So they are new. Why does that make them experimental? If they work, and will continue to be maintained, then move them to the right place. * mod_dbd is new but is going to be Big and Important :-) And it's descended from a family of modules that have been in production for a couple of years. Question; does this require the apr-util features in 1.3? * perchild keeps on going nowhere and should be removed until and unless something happens. ++1 it should be removed from 2.2.x branch, period. THEN if something good happens on trunk, we reconsider the new code. Please lets bear in mind that a lot of code marked stable is really just as new and untested, and going through the same process. Obvious cases: proxy, cache and ldap have been hugely re-hacked since anything in 2.0. Almost entirely by the developer/power user group who paid close attention to the flaws in the almost-unusable 2.0 implementation, right? All three should work orders of magnitude better than in 2.1. Of course auth, and proxy refactoring may still have (big) flaws. No problem, that's what the alpha/beta/GA cycle is ment to catch & address. We agreed post-2.0.36 that there should simply not be an /experimental/ tree in release versions. We didn't suggest that a module shouldn't be promoted, and actually argued that /experimental/ be gone from trunk. Classify the module correctly, commit working code, and at branch time we decide what will be 'pruned' - such as what you suggest for perchild. If you want to commit non-working, experimental code, then we can always roll another sandbox to 'play' in until there is something worthy of inclusion in trunk. Bill
Re: Issues for 2.1.8
On Tuesday 20 September 2005 22:01, Paul Querna wrote: > Mads Toftum wrote: > > On Tue, Sep 20, 2005 at 09:37:58PM +0100, Nick Kew wrote: > >> I agree about both of those. And I'd say the same even more strongly > >> for mod_dbd, simply because it (or whatever it becomes when updated in > >> the light of real-life experience) should become the basis of a new > >> generation of applications. If it's there, it'll start to permeate the > >> Usual Suspects like mod_perl. If not, we'll still have the old > >> situation of Perl, Python, PHP, Tcl, Authentication, Logging etc each > >> maintaining its own separate database connections, and having to > >> reinvent the connection pooling wheel if they want to if they want to > >> improve scalability. > > > > big +1 - let's not toss all the cool new features before the release and > > get into the same situation as 1.3 -> 2.0 having trouble convincing > > people that it was worth the upgrade. Yep. > So, lets change the VERSIONING file/policy. Experimental Modules will > be included in the stable branch. Majority Agree? +1, qualified by: Let's *prune* /experimental/ actively. Any module that's attracting bug reports/trouble that aren't getting fixed goes out. Modules that are getting used and properly maintained get promoted. -- Nick Kew
Re: Issues for 2.1.8
On Tuesday 20 September 2005 22:38, [EMAIL PROTECTED] wrote: > William A. Rowe, Jr. wrote: > > [EMAIL PROTECTED] wrote: > > [..cut..] > > > I'd argue the opposite. Do you notice how few people at any given time > > are following bugzilla? Cleaning up and mopping up? I've done my 400+ > > hours of time on that side, and am likely to jump back in from time to > > time, but it's unfair to throw unstable code out into the general (read: > > I know that this is a problem and for sure I have to admit that I should > do more on PR's. I think everybody appreciates your efforts > on the bugzilla frontier here. So some honest question (I really don't know > the answer): From your experience in the past: Is the number of PR's for > experimental modules that have not been handled by the driver(s) of these > modules remarkably higher than for other parts of httpd? The highest numbers of bugs are for the more complex subsystems. For example, cache, ldap, ssl, proxy - which are NOT currently in experimental. Regarding the new modules, there are some bug reports which mod_filter solves, but AFAIK none for mod_filter itself, nor for mod_dbd or mod_charset_lite (bugzilla is timing out right now, so I can't check). We should prune out things that are unmaintained - especially perchild - but not things that are new. > If yes, then these module shouldn't be in the experimental section of a > stable branch. > > > non-developer) community and have it all land on the backs of five folk > > who may or may not be interested in that specific flakey module. > > I understand your concerns and I know that users are sometimes the way: > "Hey its in the stable release, so it should work and I want it to be > fixed". That's the story of perchild. And was the story of cache for a long, long time, before people got around to doing some serious hacking. > And as I mentioned special care must be taken to decide which > modules can remain in the experimental section of a stable branch and which > not. Of course the driver(s) of these modules should remain commited to > handle the PR's and patches coming in. Furthermore the module should have a > minimum level of quality. I know these are very "soft" definitions from my > side and that is a weak spot. So taking the useful modules currently marked /experimental/ * mod_charset_lite has been there a long time. It could use more work (configuration is very limiting) but is useful within its limitations. * mod_filter has been there a while and got some positive feedback. But since it's only in 2.1 (or 2.0+power-user-hack), that's limited. * Event MPM - similar situation to mod_filter. * mod_dbd is new but is going to be Big and Important :-) And it's descended from a family of modules that have been in production for a couple of years. OTOH, * perchild keeps on going nowhere and should be removed until and unless something happens. > > It got fixed not because there were more testers, but as often as not, > > because there were developers who -cared-. So, if those same developers > > Of course they got fixed because developers cared and did good work. But > they also got better because people used them, found bugs (some resulting > in PR's, some in patches), edge cases and proposed new features. So you > need both sides Yep. Please lets bear in mind that a lot of code marked stable is really just as new and untested, and going through the same process. Obvious cases: proxy, cache and ldap have been hugely re-hacked since anything in 2.0. -- Nick Kew
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: > >> >> Sometimes things are marked experimental not because they are unstable >> in the sense that they contain a disproportionate ammount of bugs we >> have yet to notice, but rather are unstable in the sense that their >> behaviour or API may change in future versions - because the developers >> havn't quite got a feel for what might be optimal in the majority case >> yet. > > > And all the more reason they can't exist in stable. You *CAN'T* change > the API of any shipped module, because you are forced to bump the module Of course you can only do this on trunk, but having it shipped as experimental gives you the chance of detecting such API shortcomings due to wider usage. Of course this can lead to situations where there is a dead end for an experimental module that cannot be solved in the stable branch. In this case this problem remains a known issue / limitation that will be fixed with the next stable branch. [..cut..] Regards Rüdiger
Re: Issues for 2.1.8
On Tue, Sep 20, 2005 at 04:58:05PM -0500, William A. Rowe, Jr. wrote: > And all the more reason they can't exist in stable. You *CAN'T* change > the API of any shipped module, because you are forced to bump the module > major if the resulting change is ABI-incompatible. That hurts every > third party installed module, not simply the affected module. In the caching/event cases, we're talking about behavioural changes. For filter and dbd you're right though. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Issues for 2.1.8
Colm MacCarthaigh wrote: On Tue, Sep 20, 2005 at 02:01:07PM -0700, Paul Querna wrote: So, lets change the VERSIONING file/policy. Experimental Modules will be included in the stable branch. Majority Agree? +1 I thank everyone who's voicing an opinion - it's very important that we come to concensus. I'm incredibly concerned however that most votes on this issue are from our 'newcomers' - those without the experience of the pains and problems encountered in previous Apache release cycles. I appreciate all of the enthusiasm, drive and forward momentum! But I'm worried that a policy we arrived at, following the contentious and problematic 2.0 GA, would be tossed aside so quickly without any feedback from our 'older' devs. So this message is not at our newcomers, welcome to you all. Rather, I'm addressing this post to our 'old timers' who did struggle through the 1.3.x and 2.0.x GA process, to add your thoughts and observations. Bill
Re: Issues for 2.1.8
Colm MacCarthaigh wrote: Sometimes things are marked experimental not because they are unstable in the sense that they contain a disproportionate ammount of bugs we have yet to notice, but rather are unstable in the sense that their behaviour or API may change in future versions - because the developers havn't quite got a feel for what might be optimal in the majority case yet. And all the more reason they can't exist in stable. You *CAN'T* change the API of any shipped module, because you are forced to bump the module major if the resulting change is ABI-incompatible. That hurts every third party installed module, not simply the affected module.
Re: Issues for 2.1.8
Colm MacCarthaigh wrote: [..cut..] > > Sometimes things are marked experimental not because they are unstable > in the sense that they contain a disproportionate ammount of bugs we > have yet to notice, but rather are unstable in the sense that their > behaviour or API may change in future versions - because the developers > havn't quite got a feel for what might be optimal in the majority case > yet. > > IMO, things like the event MPM or caching in 2.0 fall in to this > category, and I've been happy to run them in production. > > The trouble with these things is that being in GA tarballs is what > eventually lets us figure out what works for the majority case. > > I'm not sure asking power users and devs to test these things is as > useful an alternative for this category of things. > I totally agree. Regards Rüdiger
Re: Issues for 2.1.8
On Tue, Sep 20, 2005 at 02:01:07PM -0700, Paul Querna wrote: > So, lets change the VERSIONING file/policy. Experimental Modules will > be included in the stable branch. Majority Agree? +1 -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Issues for 2.1.8
Paul Querna wrote: > So, lets change the VERSIONING file/policy. Experimental Modules will > be included in the stable branch. Majority Agree? > > -Paul +1 Regards Rüdiger
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: [..cut..] > > If the community isn't willing to support the code (e.g. 'experimental', > or not-supported) then it doesn't belong in release tarballs. experimental does not mean not supported. If the driver(s) behind these modules are not willing to care then they shoold be removed. > > Create snapshots, alphas, whatever of the unstable branch and get those > with higher pain tolerance, more eager to adopt 'all the cool stuff' to 'Cool stuff' from the trunk sometimes does not work with stable releases because of API changes. But some people are forced to use stable releases in their environments for various reasons. So we would lock out these people, which I regard as valueable. People how use experimental modules should have a higher pain tolerance than ordinary users. [..cut..] Regards Rüdiger
Re: Issues for 2.1.8
On Tue, Sep 20, 2005 at 03:58:36PM -0500, William A. Rowe, Jr. wrote: > And best yet, the developers *should* encourage other devs and power > users to try out snapshots until they are beta quality. Drop them into > httpd.apache.org/dev/dist/ - that's where unstable/unproven code really > belongs. Once we hear back 'good things', then the entire project > should be willing to support these new modules. Sometimes things are marked experimental not because they are unstable in the sense that they contain a disproportionate ammount of bugs we have yet to notice, but rather are unstable in the sense that their behaviour or API may change in future versions - because the developers havn't quite got a feel for what might be optimal in the majority case yet. IMO, things like the event MPM or caching in 2.0 fall in to this category, and I've been happy to run them in production. The trouble with these things is that being in GA tarballs is what eventually lets us figure out what works for the majority case. I'm not sure asking power users and devs to test these things is as useful an alternative for this category of things. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Issues for 2.1.8
William A. Rowe, Jr. wrote: > [EMAIL PROTECTED] wrote: > >> [..cut..] > > I'd argue the opposite. Do you notice how few people at any given time > are following bugzilla? Cleaning up and mopping up? I've done my 400+ > hours of time on that side, and am likely to jump back in from time to > time, but it's unfair to throw unstable code out into the general (read: I know that this is a problem and for sure I have to admit that I should do more on PR's. I think everybody appreciates your efforts on the bugzilla frontier here. So some honest question (I really don't know the answer): >From your experience in the past: Is the number of PR's for experimental modules that have not been handled by the driver(s) of these modules remarkably higher than for other parts of httpd? If yes, then these module shouldn't be in the experimental section of a stable branch. > non-developer) community and have it all land on the backs of five folk > who may or may not be interested in that specific flakey module. I understand your concerns and I know that users are sometimes the way: "Hey its in the stable release, so it should work and I want it to be fixed". And as I mentioned special care must be taken to decide which modules can remain in the experimental section of a stable branch and which not. Of course the driver(s) of these modules should remain commited to handle the PR's and patches coming in. Furthermore the module should have a minimum level of quality. I know these are very "soft" definitions from my side and that is a weak spot. > > It got fixed not because there were more testers, but as often as not, > because there were developers who -cared-. So, if those same developers Of course they got fixed because developers cared and did good work. But they also got better because people used them, found bugs (some resulting in PR's, some in patches), edge cases and proposed new features. So you need both sides > who care want to see their module in GA, it better be something better > than unstable before we inflict it on the entire user community. So if > there is a higher bar for GA, does that mean that > > Of course, these are alphas/betas. There is no reason not to keep these > modules in every alpha release. Drop them from the beta to avoid user's > confusion when they see the GA. > > The better answer; if they won't be release quality in 2.2.0, we should > simply svn rm them from 2.2.x branch. They live on, in trunk :) Thats the problem I see. That means that they will only be used by few and there is not that big feature or bug feedback from the community. > > And best yet, the developers *should* encourage other devs and power > users to try out snapshots until they are beta quality. Drop them into This is not possible for all that people, because of various reasons, e.g. - Dependance on third party modules - Dependance on support contracts - Management decision There may be thousands of reasons why these should not block power users from using snapshots, but in most cases these reason does not matter to management people. > httpd.apache.org/dev/dist/ - that's where unstable/unproven code really > belongs. Once we hear back 'good things', then the entire project As said before we should not have unproven code in the experimental section. > should be willing to support these new modules. > > Bill > > Regards Rüdiger
Re: Issues for 2.1.8
Paul Querna wrote: So, lets change the VERSIONING file/policy. Experimental Modules will be included in the stable branch. Majority Agree? -1, we've bounced back and forth on this for 10 years, but the simple fact is that the stable branch should be stable, because users with low technical literacy aren't always that helpful in moving a module from unstable to stable. If the community isn't willing to support the code (e.g. 'experimental', or not-supported) then it doesn't belong in release tarballs. Create snapshots, alphas, whatever of the unstable branch and get those with higher pain tolerance, more eager to adopt 'all the cool stuff' to participate in the effort to stablilize the new code. *Then* if it's worthwhile, bring it to the list that we adopt the module as supported in the stable/current release branch. Bill
Re: Issues for 2.1.8
+1 >>> On Tuesday, September 20, 2005 at 3:01:07 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > So, lets change the VERSIONING file/policy. Experimental Modules will > be included in the stable branch. Majority Agree? > > -Paul
Re: Issues for 2.1.8
Mads Toftum wrote: On Tue, Sep 20, 2005 at 09:37:58PM +0100, Nick Kew wrote: I agree about both of those. And I'd say the same even more strongly for mod_dbd, simply because it (or whatever it becomes when updated in the light of real-life experience) should become the basis of a new generation of applications. If it's there, it'll start to permeate the Usual Suspects like mod_perl. If not, we'll still have the old situation of Perl, Python, PHP, Tcl, Authentication, Logging etc each maintaining its own separate database connections, and having to reinvent the connection pooling wheel if they want to if they want to improve scalability. big +1 - let's not toss all the cool new features before the release and get into the same situation as 1.3 -> 2.0 having trouble convincing people that it was worth the upgrade. So, lets change the VERSIONING file/policy. Experimental Modules will be included in the stable branch. Majority Agree? -Paul
Re: Issues for 2.1.8
[EMAIL PROTECTED] wrote: Sorry for possibly starting an old discussion here, but is this really a good idea? I guess mod_ldap and mod_cache would not be in that good shape they currently are on 2.2.x branch and on trunk, if they had not been experimental modules in 2.0.x and would have only lived on the trunk. I think by having them in experimental they got in the focus of several people who weren't involved in developing httpd and thus got tested which resulted in PR's, patches and enhancement requests by those people. And even if these people look in the trunk for such modules, it is not always easy to make them work with the previous release. I'd argue the opposite. Do you notice how few people at any given time are following bugzilla? Cleaning up and mopping up? I've done my 400+ hours of time on that side, and am likely to jump back in from time to time, but it's unfair to throw unstable code out into the general (read: non-developer) community and have it all land on the backs of five folk who may or may not be interested in that specific flakey module. It got fixed not because there were more testers, but as often as not, because there were developers who -cared-. So, if those same developers who care want to see their module in GA, it better be something better than unstable before we inflict it on the entire user community. So if there is a higher bar for GA, does that mean that Of course, these are alphas/betas. There is no reason not to keep these modules in every alpha release. Drop them from the beta to avoid user's confusion when they see the GA. The better answer; if they won't be release quality in 2.2.0, we should simply svn rm them from 2.2.x branch. They live on, in trunk :) And best yet, the developers *should* encourage other devs and power users to try out snapshots until they are beta quality. Drop them into httpd.apache.org/dev/dist/ - that's where unstable/unproven code really belongs. Once we hear back 'good things', then the entire project should be willing to support these new modules. Bill
Re: Issues for 2.1.8
On Tue, Sep 20, 2005 at 09:37:58PM +0100, Nick Kew wrote: > I agree about both of those. And I'd say the same even more strongly for > mod_dbd, simply because it (or whatever it becomes when updated in the > light of real-life experience) should become the basis of a new generation > of applications. If it's there, it'll start to permeate the Usual Suspects > like mod_perl. If not, we'll still have the old situation of Perl, Python, > PHP, Tcl, Authentication, Logging etc each maintaining its own separate > database connections, and having to reinvent the connection pooling > wheel if they want to if they want to improve scalability. > big +1 - let's not toss all the cool new features before the release and get into the same situation as 1.3 -> 2.0 having trouble convincing people that it was worth the upgrade. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: Issues for 2.1.8
On Tuesday 20 September 2005 21:14, Colm MacCarthaigh wrote: > On Tue, Sep 20, 2005 at 10:07:04PM +0200, [EMAIL PROTECTED] wrote: > > Especially for mod_filter I think we should ensure that it is contained > > in 2.2 as it was announced as one of the new features of 2.2 at the > > ApacheCon. > > Same goes for the event MPM, which is marked experimental. We shouldn't > lose that either. I agree about both of those. And I'd say the same even more strongly for mod_dbd, simply because it (or whatever it becomes when updated in the light of real-life experience) should become the basis of a new generation of applications. If it's there, it'll start to permeate the Usual Suspects like mod_perl. If not, we'll still have the old situation of Perl, Python, PHP, Tcl, Authentication, Logging etc each maintaining its own separate database connections, and having to reinvent the connection pooling wheel if they want to if they want to improve scalability. -- Nick Kew
Re: Issues for 2.1.8
On Tue, Sep 20, 2005 at 10:07:04PM +0200, [EMAIL PROTECTED] wrote: > Especially for mod_filter I think we should ensure that it is contained in 2.2 > as it was announced as one of the new features of 2.2 at the ApacheCon. Same goes for the event MPM, which is marked experimental. We shouldn't lose that either. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Issues for 2.1.8
Paul Querna wrote: > I would like to tag and start a 2.1.8-beta cycle next weekend. > > According to our VERSIONING file, we should remove all modules > underneath modules/experimental/ for the 2.2.0 release. This currently > includes mod_case_filter, mod_charset_lite, mod_example, mod_dbd, and > mod_filter. This means we should either declare some of these modules Sorry for possibly starting an old discussion here, but is this really a good idea? I guess mod_ldap and mod_cache would not be in that good shape they currently are on 2.2.x branch and on trunk, if they had not been experimental modules in 2.0.x and would have only lived on the trunk. I think by having them in experimental they got in the focus of several people who weren't involved in developing httpd and thus got tested which resulted in PR's, patches and enhancement requests by those people. And even if these people look in the trunk for such modules, it is not always easy to make them work with the previous release. So from my point of view we should keep the experimental module section. Don't get me wrong: We should have a close look on the modules that get packed in the experimental section for releases of stable branches. It should not contain modules that go nowhere and that nobody here has any interest in any longer. Being in the experimental section should be more of an hint for the user of a module that this module has not the same level of quality as the remainder of the release in the meaning of - It may has some bugs - Some features have not been implemented yet - It has not been tested that intensely in the wild Especially for mod_filter I think we should ensure that it is contained in 2.2 as it was announced as one of the new features of 2.2 at the ApacheCon. Furthermore I think it is an really important and exciting feature for 2.2. Otoh I agree with Nick that it may be wise to keep it in the experimental section for some time to get some more testing in the wild. As mod_filter is something that not everybody uses everyday the tests done by the beta users may not be enough. [..cut..] Regards Rüdiger
Re: Issues for 2.1.8
Paul Querna wrote: The windows build with mod_ldap is still broken. I believe it is broken on both trunk and 2.2.x. Can anyone take a look at fixing this? It is? I've fixed on trunk and 1.2 branch of apr-util - or I presumed I finished fixing it there. I'll spin some final cycles trying to close whatever cause for testsock and testpipe on the apr test suite, double check the apr-util test suite and roll off a 1.2.2 tag on that forum.
Re: Issues for 2.1.8
On Sun, Sep 18, 2005 at 02:24:48PM -0700, Paul Querna wrote: > I would like to tag and start a 2.1.8-beta cycle next weekend. Sounds great. I'm going to start looking for things in bugzilla which have regressed since 2.0.x and mark these with the new "regression" keyword which Joshua kindly added. Here's a canned search query for the results: http://people.apache.org/~jorton/regressions21 joe
Re: Issues for 2.1.8
On Monday 19 September 2005 15:37, you wrote: > > > > dbd has another classification problem: there's no slot for it in > > /modules/ > > > ! > > I wonder if we need a new directory. Something like /modules/api/ , > > for > > > modules whose primary purpose is to export functions/hooks/APIs for > > other modules? > > If that happens then mod_ldap should probably land in that bucket as > well. I was thinking mod_so and probably mod_filter also belong there. Another thought I had is that we might contemplate a /modules/introspection/ . mod_status and mod_info would fit there, as would debugging modules such as some of Jeff Trawick's fairly-recent stuff if they get included(?) Finally, do we want a /modules/attic/ for the likes of mod_imap and mod_cern_meta? -- Nick Kew
Re: Issues for 2.1.8
On Mon, Sep 19, 2005 at 08:37:11AM -0600, Brad Nicholes wrote: > If that happens then mod_ldap should probably land in that bucket as > well. And for 2.4, we need a more generic cgid-like daemon for handling the fork()'ing and exec()'ing for the threaded MPMs. Which is another thing which would belong there too. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Issues for 2.1.8
>>> On Sunday, September 18, 2005 at 5:42:23 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > On Sunday 18 September 2005 22:24, Paul Querna wrote: > > dbd has another classification problem: there's no slot for it in /modules/ > ! > I wonder if we need a new directory. Something like /modules/api/ , for > modules whose primary purpose is to export functions/hooks/APIs for > other modules? If that happens then mod_ldap should probably land in that bucket as well. Brad
Re: Issues for 2.1.8
I would like to see mod_charset_lite included as a standard module. I am not sure why it is classified as experimental other than maybe it isn't needed or used on most platforms. The NetWare platform needs to use it to help deal with file system character set conversions when doing file indexing. At the very least, can we still include it in the tarball? Additionally, I don't see a problem with including the experimental modules in the release. If we ever want to see them get out of experimental status, they need to get released, used and fixed. Leaving them out of the release just means that they will get left behind. Brad >>> On Sunday, September 18, 2005 at 3:24:48 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > I would like to tag and start a 2.1.8-beta cycle next weekend. > > According to our VERSIONING file, we should remove all modules > underneath modules/experimental/ for the 2.2.0 release. This currently > includes mod_case_filter, mod_charset_lite, mod_example, mod_dbd, and > mod_filter. This means we should either declare some of these modules > 'stable', or remove them from the 2.2.x branch until they are considered > stable. The alternative is to change our VERSIONING policy/file. Thoughts? > > If there are any fixes you want in 2.1.8, please try to backport them > from trunk this week. I believe all the items in the non-showstoppers > patch that was released with 2.1.7 should be committed. Are there any > other issues people found with 2.1.7? > > The windows build with mod_ldap is still broken. I believe it is broken > on both trunk and 2.2.x. Can anyone take a look at fixing this? > > Thanks, > > Paul
Re: Issues for 2.1.8
On 9/18/05, Nick Kew <[EMAIL PROTECTED]> wrote: > On Sunday 18 September 2005 22:24, Paul Querna wrote: > > I would like to tag and start a 2.1.8-beta cycle next weekend. > > > > According to our VERSIONING file, we should remove all modules > > underneath modules/experimental/ for the 2.2.0 release. This currently > > includes mod_case_filter, mod_charset_lite, mod_example, mod_dbd, and > > mod_filter. This means we should either declare some of these modules > > 'stable', or remove them from the 2.2.x branch until they are considered > > stable. The alternative is to change our VERSIONING policy/file. Thoughts? > > Yow! > > Well, I'm responsible for mod_filter and mod_dbd being in experimental. > I thought it appropriate to put them there until such time as they've been > sufficiently test-driven in the real world to declare stable. That depends on > them going into a release. The same probably applies to charset_lite if > anyone is taking an interest(?) charset_lite is stable as in "works without crashing" (at least on z/OS). It is rather simplistic in its configuration options and I thought for a while that the configuration might need to be completely redesigned to accomodate real-world issues. But it is usable enough with the current directives and should be placed in the filter directory.
Re: Issues for 2.1.8
On Sunday 18 September 2005 22:24, Paul Querna wrote: > I would like to tag and start a 2.1.8-beta cycle next weekend. > > According to our VERSIONING file, we should remove all modules > underneath modules/experimental/ for the 2.2.0 release. This currently > includes mod_case_filter, mod_charset_lite, mod_example, mod_dbd, and > mod_filter. This means we should either declare some of these modules > 'stable', or remove them from the 2.2.x branch until they are considered > stable. The alternative is to change our VERSIONING policy/file. Thoughts? Yow! Well, I'm responsible for mod_filter and mod_dbd being in experimental. I thought it appropriate to put them there until such time as they've been sufficiently test-driven in the real world to declare stable. That depends on them going into a release. The same probably applies to charset_lite if anyone is taking an interest(?) mod_example should probably go (we know it's problematic, and noone got round to fixing it AFAICR). I've never looked at case_filter, but I guess that's probably another example? Looking at that "versioning", I guess that means they have to become part of the general beta. Which I guess is on the par with other much-rewritten parts like proxy and cache. dbd has another classification problem: there's no slot for it in /modules/ ! I wonder if we need a new directory. Something like /modules/api/ , for modules whose primary purpose is to export functions/hooks/APIs for other modules? > If there are any fixes you want in 2.1.8, please try to backport them > from trunk this week. I hacked up a mod_authn_dbd one night at apachecon(!) It's mostly copied from mod_authn_dbm, with the backend calls translated to dbd, and it's totally untested. I just uploaded it to http://people.apache.org/~niq/mod_authn_dbd.c and if I or anyone can find time, it would be nice to add authn_dbd (and authz_dbd, which I haven't started). -- Nick Kew
Re: Issues for 2.1.8
"Paul Querna" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I would like to tag and start a 2.1.8-beta cycle next weekend. > > According to our VERSIONING file, we should remove all modules underneath > modules/experimental/ for the 2.2.0 release. This currently includes > mod_case_filter, mod_charset_lite, mod_example, mod_dbd, and mod_filter. > This means we should either declare some of these modules 'stable', or > remove them from the 2.2.x branch until they are considered stable. The > alternative is to change our VERSIONING policy/file. Thoughts? > > If there are any fixes you want in 2.1.8, please try to backport them from > trunk this week. I believe all the items in the non-showstoppers patch > that was released with 2.1.7 should be committed. Are there any other > issues people found with 2.1.7? > > The windows build with mod_ldap is still broken. I believe it is broken > on both trunk and 2.2.x. Can anyone take a look at fixing this? > Actually, according to Gump (http://vmgump.apache.org/gump/public/apache-httpd/apache-httpd-make/index.html), the entire build for trunk is currently hosed (or at least mod_setenvif :). > Thanks, > > Paul >
Issues for 2.1.8
I would like to tag and start a 2.1.8-beta cycle next weekend. According to our VERSIONING file, we should remove all modules underneath modules/experimental/ for the 2.2.0 release. This currently includes mod_case_filter, mod_charset_lite, mod_example, mod_dbd, and mod_filter. This means we should either declare some of these modules 'stable', or remove them from the 2.2.x branch until they are considered stable. The alternative is to change our VERSIONING policy/file. Thoughts? If there are any fixes you want in 2.1.8, please try to backport them from trunk this week. I believe all the items in the non-showstoppers patch that was released with 2.1.7 should be committed. Are there any other issues people found with 2.1.7? The windows build with mod_ldap is still broken. I believe it is broken on both trunk and 2.2.x. Can anyone take a look at fixing this? Thanks, Paul
