Message-ID: <19981111170802.A27926@engelschall.com>
Date: Wed, 11 Nov 1998 17:08:02 +0100
From: "Ralf S. Engelschall" <rse@engelschall.com>
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-1.3/src CHANGES
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Engelschall, Germany.
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


In article <3649AD22.48F6C16F@Golux.Com> you wrote:
> Ralf S. Engelschall wrote:

>[...]
>> > +1 to making the default _exactly_ the same as Configure. The hell with
>> > the archives.
>> 
>> Sorry, but then I'll vote -1. Making it totally similar to Configure makes new
>> confusion: First because people are already used to APACI's paths (harmless
>> problem) and second because a script named "configure" usually doesn't imply
>> Apache paths in the users mind (big problem).

> Well, then so much for your remark about being willing to adjust
> the paths, Ralf.  You've just contradicted yourself by essentially
> saying you'll veto anything that changes the default from
> the current behaviour.

Don't panic, I'll not really veto it when a real voting is done for this.  I
was more annoyed before because of this late and agressive anti-APACI
disucssions. Sorry for this. But nevertheless I still think it's not good this
way and would vote -0...

> I don't see any room for compromise here.  One side wants the default
> APACI path behaviour to be Apache Classic, and the other wants it
> to be GNU Classic.

Then we should do a voting, shouldn't we?

> Consider this: someone who's used to the configure-style interface
> is already used to lots of command-line options, yes?  So what's
> one more (--use-GNU-paths) to it?  Someone who's used to the
> Apache Classic paths, on the other hand, is going to be handed
> a rude surprise unless it remembers to add '--compat' to the
> bewildering and unfamiliar welter of options it already has to
> type.  

<grin> Yes, sure. I accept your POV and your argument. But you know that one
can easily reword your sentences here for as an argument for the other point
of view:

| Consider this: someone who's used to the old-style interface
| is already used to doing a lot of manual work, yes?  So what's
| one more configure option (--compat) to it? Someone who's used to the
| Apache GNU paths, on the other hand, is going to be handed
| a rude surprise unless it remembers to add '--use-GNU-path' to the
| bewildering and unfamiliar welter of options it already has to
| type.  

So I don't think it's not really matter of one option more or less.  It's
more: what do people expect? Perhaps we should ask a few users?

> It may come to love APACI, but I don't know how positive
> the initial experience will be if that little detail is forgotten.

Ok, as long as the stuff is done really clean and backward compatible I'm
still open for all good compromises. How about this:

1. We enhance APACI with a new general option 
   (say --use-layout=ID) and kick out the --compat option.

2. We pre-configure Apache Classic (ID=classic), Apache 
   GNU (=gnu) and perhaps more (like ID=local for local in-source-tree
   testing) into APACI which can be selected via --use-layout=ID

3. We do a short voting inside the group to
   make sure what ID should be the default.

4. We make ID=classic or ID=gnu the default 
   according to the voting.

Is this an acceptable approach?
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com