Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
Date: 12 Jul 2002 21:37:14 -0000
Message-ID: <20020712213714.2360.qmail@icarus.apache.org>
From: dreid@apache.org
To: apr-cvs@apache.org
Subject: cvs commit: apr STATUS

dreid       2002/07/12 14:37:14

  Modified:    .        STATUS
  Log:
  Add my votes.
  
  Revision  Changes    Path
  1.157     +4 -4      apr/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/apr/STATUS,v
  retrieving revision 1.156
  retrieving revision 1.157
  diff -u -r1.156 -r1.157
  --- STATUS	12 Jul 2002 04:28:16 -0000	1.156
  +++ STATUS	12 Jul 2002 21:37:14 -0000	1.157
  @@ -64,7 +64,7 @@
   
         1) Keeping the existing apr_time_t names, in spite of confusion
            with ANSI/C99 time_t's units, and prior decimal usec definition.
  -         +1: rbb, jerenkrantz, striker
  +         +1: rbb, jerenkrantz, striker, dreid
            +0: wrowe [apr_types don't promise to map to C99/ANSI units]
            +0: brianp
            -0.5: jwoolley
  @@ -80,7 +80,7 @@
            but keep it ambigious and make no contract with the user about the
            units represented.  Needs a better suggestion than apr_timeval_t.
            +1: aaron, jwoolley, brianp, ianh
  -         -0: jerenkrantz, striker
  +         -0: jerenkrantz, striker, dreid
            -0.5: rbb, wrowe
   
         3) Renaming the function to get rid of apr_time_t vs time_t confusion,
  @@ -91,7 +91,7 @@
            +0.5: wrowe,  [prefers apr_butime_t but isn't going to fight that]
                  brianp
            -0: striker, jerenkrantz
  -         -0.5: rbb, ianh
  +         -0.5: rbb, ianh, dreid
   
         [fielding: Is APR time guaranteed to be a scalar quantity?  If so,
          then we must include units as part of the definition of the