apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 18:07:57 GMT
> >A big reason that they are too complex, is that rather than come up
with
> >a simple design, we are all afraid of the damned vetos that are being
> >thrown about.  This whole conversation should just start over, with
no
> >vetos, and no emotions.  Vetos should be a last resort, but we don't
use
> >them as a last resort, we use them as a way to shape where people go
> >with their ideas.
> 
> Because you haven't won the day?  Sorry, but the manner in which you
> jumped into the conversation has left several folks with that
impression.

Screw that.  I have lost votes before, and I can accept that.  What is
pissing me off is that the obvious majority would rather keep
apr_time_t, but because of a stupid veto, we are being forced to change
the name.

Just because I have been too busy recently to watch and respond to the
hundred or so messages about this doesn't mean I am jumping in at the
last minute.  I have replied when I had time to reply, which is the best
that I can do.

> Nobody is afraid of vetoes.  The most polar extremes lost [keeping the
> current type, and changing the representation to POSIX time.]  Both
> have two recorded vetoes.  The only veto folks objected to was a veto

Neither of the vetos has a valid technical justification, which makes
them invalid.  We have provided mechanisms for users to determine if
their version of APR matches the installed version.

Vetos used to be rare, now they are common.  That stops debate, because
a veto can only be removed by the person who issued it.  I have a
problem with the frequency with which vetos are used in APR and httpd
development today.  We are all supposed to be working together to solve
a problem, vetos are meant to be used when rational discussion DOESN'T
come up with a solution.  Instead, we use them to head off possible
solutions that we don't like.

I don't really care what the damned solution is to the time problem
anymore, because regardless of what it is, it is likely to suck.  What I
do care about, is solving the process that got us to this mess in the
first place.

Ryan



Mime
View raw message