Re: Forget it (was: Re: [CONTRIB] Autoconf Interface Emulation)

["Ralf S. Engelschall" <rs...@engelschall.com>]

In article <34...@Golux.Com> you wrote:
> Ralf S. Engelschall wrote:

>[...]
>> Either way: Three vetoes are enough, I give up contributing this stuff for
>> inclusion because I really want to avoid fights. If the majority really thinks
>> it is not worth to have it then forget it, please. I really don't want to
>> fight any more with arguments now. But if this issue is already such
>> complicated then it seems we will get more horrible debates when Apache 2.0 is
>> really started.  Because it seems there is heavy resistance to the GNU-style
>> configuration approach which (IMHO) _is_ a really good approach because all of
>> my personal packages used and gained from it in the past and the same would
>> apply to Apache...

> I don't think that's the upshot of the last discussion round; I think the
> conclusion was "yes, let's try it for 2.0.  it's going to be a real
> hairball to come up to speed and do it right, so under no circumstances
> should we try to impose it on 1.3, which is perilously close to release.
> [quick, add some features so we can push the release date out!]".

The point everyone forgets is that my GNU/Autoconf-style interface emulation
is _ONLY_ for 1.3 because only there is a need to fill the gap between our own
src/Configure script and the GNU/Autoconf-style configuration script the users
expect. For Apache 2.0 we either use Autoconf itself (then there is no need
for an interface emulation) or use a totally different system (then we need a
totally different emulation).

That's the point why I said: "Either now or never". Because only for 1.3 there
is a gap which has to be filled and for this gap I wrote the stuff. When we
don't include it in 1.3 we can forget it completely. Because for 2.0 we need
to start from scratch, anyway.

>> So, let us forget this topic for the official 1.3 distribution now, please.
>> I'll put it onto my personal webserver for those users who really like it and
>> thus there is no more need to fight...

> If it pleases a significant number of users, I think it's worth re-examining.
> So if you get a couple of dozen rave reviews I'll probably turn round and
> be supportive of doing it in 1.3.[1-9].

> Hey, it's what happened with mod_rewite.. ;->

<grin> Yes, this is another point of view. Mod_rewrite in it's beginning in
April 1996 was not wanted by the group. Heavy resistance showed up except for
Alexei. Then after a lot of users found it useful and cool the groups decision
turned around. BUT: Very late, very slowly and we needed a lot of arguments
and IMHO a little bit too much arguments (because in the end I was just before
giving up, really). Today mod_rewrite is considered standard and a lot of
users use it and like it, because it both works great and has proofen its
usefulness and flexibility. It was a good addition to Apache and the addition
was worth it, I think.

But as I said before in this thread: When there is again such huge resistance
for a useful stuff then I really want to avoid fights here. I'm not interested
to spend a lot of time for fighting. Instead I can do more another useful
stuff for the group. Always remember: the only way to win a fight or
flamewar is to avoid it ;-)

But I'm happy, Ken, that you at least said that it's perhaps worth
re-examining. This is a start and indicates that you are fair. I wished some
other would think the same way and try the stuff out and not just voting for
concept (even if this is also important). I understand this, yes, and it is
good that some of us, like Jim, always try to keep the release goal in mind
and give us important directions while we develop. So, I have to say that I'm
really happy that we have people in the group who are forcing strict
development because it avoid problems in general. But sometimes it is a little
bit too conservative IMHO. At least in situations like this where an IMHO
useful addition is available but is vetoed just because it seems very late in
the release cycle... 

Here we should weigt on what is really better: To do an exception and include
it because it fills an important gap which missed for a long time or to veto
it because we are still at the end of the release cycle and have to avoid new
problems. Sure, we must review it carefully and perhaps fix it a little bit,
but then the advantage of having it is more then the disadvantage of upcoming
PR's.

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com