apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 18:47:17 GMT
At 01:07 PM 7/13/2002, 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.

That is true.  +4, with 2 +0's voting with the majority, and -2 [vetoes].

One veto is technically questionable.  The fact that apr_time_t might
or might not be confusing to posix coders is no more significant than
the fact that the user can declare a time_t and pass that to our
functions.  apr_ types use apr_ definitions.

Aaron's veto is far more compelling, although I'm +0 on retaining the
existing name.  But his is just as bogus as the first, since his rename
does nothing to break binary compatibility and ASSURE no bugs.

As things stand, #2 wins out over #1 the same +4, three -0's voting
with the majority, and two -.5's.  That is 7 for, 2 against, v.s. 6 for and
2 vetoes.

Our #3 and #4 options are out of contention right now.

This simply doesn't call for a "Recount", "Do Over" case.  Either Aaron
and Roy remove their vetoes, or we go with #2.

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

Um.  That was not commentary on your proposal.  It was on struct tm.

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

Technical justification of 1): It introduces bugs if folks don't note the API
has changed underneath their code, yet it still compiles.  [not my veto,
but I can at least explain it.]

Technical justification of 2): It is slower to take differences between structs
of two ints than a single scalar.  [my veto, shared with Brian.]

>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 think Aaron hit in on the head.  Our docs state "Veto Early".  If we didn't
mean that, then better to change that wording and reeducate.

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

As I said... revisit the docs Aaron's pointed out.  They certainly stand
to be improved.

But none of this implies the vote shouldn't happen, or that we shouldn't
be bound to it.  The vetoes are there, you have this odd assumption
that, phrased differently, the votes would have been different.

Yes, it would have been nice if the debate was more civil.  I doubt the
outcome would have been different on the project's code, but it would
have saved alot of wasted time and aggravation.


View raw message