httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ranier Vilela <ran...@cultura.com.br>
Subject Re: Issues for 2.1.8
Date Thu, 22 Sep 2005 11:57:14 GMT
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"

Mime
View raw message