httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: Back to the roots
Date Tue, 27 Apr 1999 08:49:16 GMT
On Tue, 27 Apr 1999, Ralf S. Engelschall wrote:
> My main concern is the source tree layout, Ben. Compare this yourself (right:
> the current MM source tree; left: the MM source tree with your approach):
>     CHANGES          CHANGES        
>     CVS              CVS            
>     INSTALL          INSTALL        
>     LICENSE          LICENSE        
>     README           README         
>     aclocal.m4       aclocal.m4     
>     config.guess     config.guess   
>     config.sub       config.sub     
>     configure        configure      
>     fbtool           fbtool         
>     ltconfig         ltconfig       
>     mm-config.1      mm-config.1    
>     mm-config.pod    mm-config.pod  
>     mm.3             mm.3           
>     mm.h             mm.h           
>     mm.pod           mm.pod         
>     mm_alloc.c       mm_alloc.c     
>     mm_core.c        mm_core.c      
>     mm_global.c      mm_global.c    
>     mm_lib.c         mm_lib.c       
>     mm_test.c        mm_test.c      
>     mm_vers.c        mm_vers.c      
>     shtool           shtool_echo    
>                      shtool_fixperm 
>                      shtool_guessos 
>                      shtool_install 
>                      shtool_mkdir   
>                      shtool_mkshadow
>                      shtool_move    
>                      shtool_path    
>                      shtool_prop    
>                      shtool_slo     
>                      shtool_table   
>                      shtool_version 

Sigh; this is why god invented mkdir(1).  Problem solved.

> Sure, I guess you've no problem with the right side. That's fine. But I
> personally have great problems with such source trees because it strikes my
> optical aesthetics. That's why shtool is a single script - to let me avoid
> such source trees. But because when someone hasn't problems with it, all I can
> say is that then he just shouldn't use shtool. That's all. 

Does trying to keep straight the organization of shell code in a 50K file
strike your "optical aesthetics", too?  It sure does mine...

> BTW, I find it rather silly that every time I contribute something to the
> community I first have to explain my intentions in depth and get blamed for my
> approaches when I make a suggestion. Hey, it's all Open Source and no one is
> forced to use or like anything. I really would wish people say either a short
> "Sorry, it's not really what I like so I'll not use it" or a short "Hey,
> that's cool stuff, I'll use it". Then it would be fine. But every time endless
> non-technical and rhetoric discussions occur where at the end nothing has
> really changed in the minds of any speakers IMHO. I'm tired of such
> discussions and still don't understand why an author always should fight for
> his product and is pressed into a discussion by rhetoric questions.  Yes, I
> know it's my failure that I always reply to such questions and let myself
> being pressed into such situations. But I don't understand why people are
> always such aggressive when new stuff occurs.

If you think this is bad, you should work on commercial software
development projects.  At least our debate is out in the open, where
clearly incorrect statements can be corrected.  You have the
double-penalty in private debates of different aesthetics *and* different
skill levels of developers and managers.  Whee!  

I think everyone appreciates your work, Ralf, but just keep in mind that
code doesn't make right; just because you've implemented things a certain
way, and it works, doesn't mean everyone agrees that's the right way to do
it.  I think also you tend to "surprise" us with code before asking for
our input or ideas on design, and then ask us to swallow a couple hundred
K worth of patches in one go.  That's clearly not as effective as getting
us to buy-in on the ideas and approaches first, and the code (bit by bit)
second.  When possible, of course.

On that note, I'm +1 on the inclusion of EAPI in 2.0; I don't think we're
going to get to I/O layering anytime soon.


View raw message