apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "'Aaron Bannert'" <aa...@clove.org>
Subject Re: more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 18:19:39 GMT
On Sat, Jul 13, 2002 at 11:07:57AM -0700, Ryan Bloom wrote:
> 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.

"Stupid veto?" Pardon me, but that is the entire point of a veto.
I have a problem with one of the solutions, and I have a valid
technical reason (that you may not agree with). Let's work together
to fix the problem in a way we'll all be happy with.

> Neither of the vetos has a valid technical justification, which makes
> them invalid.

That is your opinion.

> We have provided mechanisms for users to determine if
> their version of APR matches the installed version.

I know of no APR apps that are currently using these mechanisms, including
httpd. Do you?

> 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.

That is exactly what they are for. Rather than let people go through
the work to come up with something that will be later vetoed, we state
early what we would have a problem with and try to work around it. This
was exactly what I did, and for the last few weeks I have stated numerous
times that we can not use apr_time_t for the new implementation. Only
recently did I go so far as to actually veto that proposal. Fine, it's
done, let's move on.

> 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.

?? What is this about? If you could maybe qualify what you mean by "suck",
maybe we could address some of these vague problems you're having now
instead of later.

-aaron

Mime
View raw message