httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: apache-1.3 STATUS
Date Thu, 09 Apr 1998 01:28:59 GMT
dgaudet     98/04/08 18:28:58

  Modified:    .        STATUS
  I, too, retract my votes, opinions, and plans regarding 1.3.
  Revision  Changes    Path
  1.282     +14 -52    apache-1.3/STATUS
  Index: STATUS
  RCS file: /export/home/cvs/apache-1.3/STATUS,v
  retrieving revision 1.281
  retrieving revision 1.282
  diff -u -r1.281 -r1.282
  --- STATUS	1998/04/09 00:42:54	1.281
  +++ STATUS	1998/04/09 01:28:57	1.282
  @@ -15,7 +15,7 @@
         or not, and if not, what changes are needed to make it right.
         Approve guidelines as written:
  -         +1: Dean, Paul, Jim, Martin, Ralf, Randy, Brian, Ken
  +         +1: Paul, Jim, Martin, Ralf, Randy, Brian, Ken
  @@ -195,15 +195,12 @@
   Needs patch:
  -    * Dean's "locale" project
  -	See <>
       * Documentation for:
         1) htdocs/manual/sourcereorg.html and other files should mention 
            new mod_so capabilities.
         2) windows.html should be cleaned up.
  -    * uri issues (dean will do unless someone else wants 'em):
  +    * uri issues
   	- RFC2068 requires a server to recognize its own IP addr(s) in dot
   	notation, we do this fine if the user follows the dns-caveats
   	documentation... we should handle it in the case the user doesn't ever
  @@ -233,11 +230,11 @@
               ap_xxx:    +1: Ken, Brian, Ralf, Martin, Paul, Randy
           - Public API functions (e.g., palloc)
  -            ap_xxx:    +1: Ralf, Dean, Randy, Martin, Brian, Paul
  +            ap_xxx:    +1: Ralf, Randy, Martin, Brian, Paul
           - Private functions which we can't make static (because of
             cross-object usage) but should be (e.g., new_connection)
  -            ap_xxx:    +1: Dean, Randy, Martin, Brian, Paul
  +            ap_xxx:    +1: Randy, Martin, Brian, Paul
   	               -0: Ralf
               apx_xxx:   +1: Ralf
               appri_xxx: +0: Ralf
  @@ -246,7 +243,7 @@
             status_module) which are used special in Configure,
             mod_so, etc and have to be exported:
  -            ..._module:+1: Dean
  +            ..._module:+1: 
   	               +0: Ralf
               ap_xxx:    +1:
   	               -0: Ralf
  @@ -293,32 +290,6 @@
                    the user while still providing the private
  -            - Dean: [Use ap_ only] Why? Because it's far easier to type,
  -              and damn it, I type these things far too much.  Just using
  -              apapi_ for the few hours I did while writing
  -              apapi_vformatter is making me puke.  So many extra
  -              characters, so much wasted screen width, and
  -              keystrokes.
  -	      Furthermore, nobody has explained just what happens when
  -	      functions which are "part of the API", such as palloc
  -	      suddenly get moved to libap and are no longer "part of
  -	      the API".  Calling it apapi_palloc is foolish.  The name
  -	      "ap_palloc" has two prefixes for those not paying attention,
  -	      the first "ap_" protects apache's namespace.  The next,
  -	      "p" indicates it is a pool function.  Similarly we would
  -	      have "ap_table_get".  There's no need to waste space with
  -	      "apapi_table_get", the "api" part is just redundant.
  -	      If folks can't figure out what is in the api and what
  -	      isn't THEN IT'S IS A DOCUMENTATION PROBLEM.  It's not
  -	      a code problem.  They have to look in header files or
  -	      other docs anyhow to learn how to use a function, so why
  -	      should they repeatedly type apapi ?
  -	      ap_ is a name space protection mechanism, it is not a
  -	      documentation mechanism.
               - Randy: I agree with Dean 100%. The work created to
                 keep this straight far outweighs any gain this
                 could give. 
  @@ -342,14 +313,7 @@
                 background of our cognitive model of the source code).
       * Paul would like to see a 'gdbm' option because he uses
  -      it a lot. Dean notes that 'gdbm' include 'db' support
  -      so we need to watch the library ordering.
  -	Dean notes:  Check rev 1.72 -> rev 1.73 of
  -	src/Configuration.tmpl.  I re-ordered mod_auth_dbm and
  -	mod_auth_db at this time, and I'm pretty sure it was to
  -	deal with this issue.  But I think I still ran into
  -	troubles if I automatically looked for gdbm.
  +      it a lot.
       * The binary should have the same name on Win32 and UNIX.
   	+1: Ken
  @@ -362,15 +326,15 @@
       * Maybe a http_paths.h file? See
  -	+1: Dean, Brian, Paul, Ralf, Martin
  +	+1: Brian, Paul, Ralf, Martin
       * Release builds: Should we provide Configuration or not?
         Should we 'make all suexec' in src/support?
   	Ken +1 (possible suexec path issue, though)
           Brian +1
  -    * root's environment is inherited by the Apache server. Jim, Ken &
  -      Dean thinks we should recommend using 'env' to build the
  +    * root's environment is inherited by the Apache server. Jim & Ken
  +      think we should recommend using 'env' to build the
         appropriate environment. Marc and Alexei don't see any
         big deal. Martin says that not every "env" has a -u flag.
  @@ -381,13 +345,11 @@
           Apache should be sending 200 *and* Accept-Ranges.
       * Marc's socket options like source routing (kill them?)
  -	Marc, Dean, Martin say Yes
  +	Marc, Martin say Yes
       * Ken's PR#1053: an error when accessing a negotiated document
         explicitly names the variant selected.  Should it do so, or should
         the base input name be referenced?
  -	Dean says: doesn't seem important enough to be in the STATUS...
  -	    it's probably a pain to fix.
       * Proposed API Changes:
  @@ -396,7 +358,7 @@
   	  field is r->content_languages.  Heck it's not even mentioned in
   	  apache-devsite/mmn.txt when we got content_languages (note the s!).
   	  The proposal is to remove r->content_language:
  -	    Status: Dean +1, Paul +1, Ralf +1, Ken +1
  +	    Status: Paul +1, Ralf +1, Ken +1
   	- child_exit() is redundant, it can be implemented via cleanups.  It is
   	  not "symmetric" in the sense that there is no exit API method to go
  @@ -405,7 +367,7 @@
   	  mod_mmap_static, and mod_php3 for example).  The proposal is to
   	  remove the child_exit() method and document cleanups as the method of
   	  handling this need.
  -	    Status: Dean +1, Rasmus +1, Paul +1, Jim +1, 
  +	    Status: Rasmus +1, Paul +1, Jim +1, 
   	            Martin +1, Ralf +1, Ken +1
       * Don't wait for WIN32:  It's been quite some time and WIN32 doesn't seem
  @@ -415,7 +377,7 @@
   	Proposal: the next release should be named 1.3.0 and should be labelled
   	    "stable on unix, beta on NT".
  -	    +1: Dean
  +	    +1: 
   	    -0: Ralf (because we've done a lot of good but new stuff
   		      in 1.3b6-dev now and we should give us at least
   		      one pre-release before the so-called "release" [1.3.0].
  @@ -429,7 +391,7 @@
   	    candidate on unix, beta on NT".  The release after that will be
   	    called 1.3.0 "stable on unix, beta on NT".
   	    +1: Jim, Ralf, Randy, Brian, Martin
  -	    +0: Dean
  +	    +0: 
               Randy: APACI should go in a beta release if it is to go in at all.

View raw message