On Tue, Apr 08, 2008 at 06:46:34PM -0700, Rick Cobb wrote: > Tom, I'll take a small issue with your: > > A > > quick look at all the modules in CVS suggests that this is the best > way to > > contribute code, not by hacking on the core. > > I think that's an effect, not a cause. My company stopped submitting > changes well before I came to it (2003) because the core changes it > needed were not acted on (i.e., accepted). We still don't believe that: > * Conns should belong to a single thread > * Authentication and authorization belong in the same module > * A deployment will only use one authentication protocol > (Ns_ConnReturnUnauthorized) > * System logging shouldn't have hooks for external system log > consolidation (syslog, mod_log_spread...) > > At least the first of those got some action in 4.x, but we've still had > to modify the core and drivers to get our connection count up where we > want it on Windows (>10000 established sockets; that may help folks > understand why 1 thread == 1 socket doesn't work well for us). > > (I'm aware OpenACS has a fine set of workarounds (sorry, modules and > deployment conventions) for the second and third problem, but I can't > use 'em (and don't read the source for 'em) since it's GPL'ed.) > > But we don't submit our changes, because going through the process you > suggest (which I admit, we use an abbreviated form of internally) would > double our technical management overhead, and have us working on use > cases we frankly don't ever deal with (e.g., virtual hosting). > > Would we take that overhead if our developers didn't think they'd end up > spending as much time arguing (sorry, "motivating their changes") with > folks who won't affect our bottom line as they do with their colleagues > & customers? I don't know; I think we'd be more likely to. > > I second your thought that setting direction would be good. But I find > it very easy to hear your input as "nullity is a good direction". > > Stability has its costs as well as its benefits --
I wonder why AOLServer did not adopt a TIPs-like approach. That is specifically useful to track improvements (what, why and how, pros and cons discussions, etc.) and making transparent the development process. I think I already suggested that kind of approach in the past, but someone objected that AOLServer community it's too tiny to adopt this kind of solution. I strongly disagree about that, I know well other little but important communities which adopted something like that, such as: http://trac.osgeo.org/gdal/wiki/rfc1_pmc The aim is exactly manging a project with a well-stated API and products, so ensuring stability while avoiding staling development. -- Francesco P. Lovergine -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
