Why not...

[Bret <me...@busboy.sped.ukans.edu>]

	Label me a lurker... plus, I haven't managed to piss anybody off in a day
or two...

>1) Do you feel that the Apache group is behaving like:
>  (a) pre-teens
>  (b) rebellious teenagers
>  (c) young ideallistic adults
>  (d) mature adults
>  (e) idiots

	I'll take something in between (a) and (b)... it's somewhat disheartening
to see a group of remarkably intelligent individuals degenerate into "But
the rules say this..." and "I've been doing this for x years so therefore
I've become omniscent."  That this has all been due to a few extra
characters is even that much more shocking...

>2) Are you happy using a product which is clearly managed by bumbling fools
>   that can't make any decisions?
>  (a) yes, it still is a cool webserver
>  (b) no, no matter how cool it is

	Now, now, let's not be too harsh... <g>
	But seriously, there's an important point here... it's the product that
matters, not whether somebody accepts your idea or chooses their own way.
Seems like a couple people have become increasingly stuck on doing it their
own way for very questionable reasons...		

>3) Oh hey, do you want to vote for the two naming proposals?
>  (a) I believe that documentation is the place to define the API, and I
>      really just want a solution to the name space collision issues, so I
>      would like everything to be prefixed ap_.  I recognize that this is
>      a time-honoured solution, even ANSI and POSIX use this technique,
>      a leading _ is protected namespace, but by no means does it mean that
>      the function/keyword is private.
>
>  (b) I believe that we should spend a bunch of effort right now deciding
>      what is part of the API, and what isn't, and what won't ever be part
>      of the API, and we should include this information as documentation
>      in the symbols.  I clearly don't believe that documentation is
>      sufficient.

	Sorry Dean, but Jim and Ken are absolutely right... the symbols should
have distinct names.  Functions which are exported to the API should be
very clearly marked as such... makes things that much clearer for anybody
reading the code. 
	Now before people proceed to drill the living hell out of me, there are a
couple important caveats to add to this statement...

	1) This does _not_ mean that documentation should only be found in the
source.  Changing the names of functions is not enough in and of itself...
some sort of external documentation is 

	2) One important voice which I think has been lost in this discussion is
Marc's.  T'was he that attempted to remind everybody that part of the
symbol renaming was to clearly define an API, although this certainly isn't
the time to do that.  If the purpose of the renaming were to simply avoid
collisions, hide.h would've done the job.

	However, I believe Roy was right in saying that hide.h is not the right
solution (makes the source code more difficult to read and other assorted
nastiness).  On a related note, a renaming scheme is going to be undertaken
for 2.0 anyways, so why install an obvious "hack" like hide.h as a
temporary solution?  Wouldn't it make more sense to develop a strong base
for this release which accomplishes the immediate goal of avoiding symbol
collisions _and_ lends itself to expansion into a system for defining the
API for the 2.0 release?
	As a compromise, then, I would propose a renaming to a single prefix right
away.  Solves the immediate problem (which aroused Roy's ire and veto)
_and_ provides a solid foundation upon which, in later releases, a clear
system can be designed which distinguishes between API and non-API
functions.  In that respect, I agree with Dean... put off the discussion
about what is and isn't API, but do it in a way that solves the immediate
problem and can be extended later to define which functions belong to the
API and which don't.  But do it in a way that doesn't have to be ripped out
when a new naming scheme is eventually implemented (which would've been the
case for hide.h, at least reasonably).


>5) Do you think that the development guidelines
>   <http://dev.apache.org/guidelines> are a sign of a
>   dysfunctional group who can't trust each other?
>   (a) yes
>   (b) no

	(b) They've been working well for some time, and they should work well...
provided certain members of the group don't abuse them.  That always leads
to escalation and the kind of situation you have now, where nobody's
listening and everybody's angry.

>7) (essay) Do you have any suggestions as to how improve the Apache
>   development process?

	I'm an outsider, and adding anything here would most likely trespass on
ground I don't know much about.  Besides, nothing springs to mind right
away, so I'll shut up at this point...

>8) Would you like to start working on Apache 2.0?
>   (a) Yes I think that would be cool.
>   (b) No, I think you're a bunch of losers I'm going to join some other
>       httpd effort.
>   (c) No, I just like to watch the fighting.
>   (d) What is Apache 2.0?

	(a) Absolutely... although I'm sure a number of people don't like me very
much anymore... :)

	Well, so much for remaining neutral... I would strongly encourage
everybody to remember why you're doing this; to make a cool program even
better.  Continue working on that and leave the bickering and the vetos to
the politicians...
	Just my two cents... I'll now be ducking for cover...
	Later...

								- Bret -