cvs commit: apache-site 404.html

1998-01-09 Thread brian
brian   98/01/08 19:13:14

  Modified:.404.html
  Log:
  index of the current directory doesn't make any sense in a 404 situation.
  
  Revision  ChangesPath
  1.3   +0 -1  apache-site/404.html
  
  Index: 404.html
  ===
  RCS file: /export/home/cvs/apache-site/404.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- 404.html  1997/07/23 19:24:31 1.2
  +++ 404.html  1998/01/09 03:13:14 1.3
  @@ -28,7 +28,6 @@
   phr
   
   A HREF=http://www.apache.org/;IMG 
SRC=http://www.apache.org/images/apache_home.gif; ALT=Home/A
  -A HREF=./IMG SRC=http://www.apache.org/images/apache_index.gif; 
ALT=Index/A
   
   /BODY
   /HTML
  
  
  


cvs commit: apache/src Configure

1998-01-09 Thread martin
martin  98/01/09 06:50:51

  Modified:src  Tag: APACHE_1_2_X Configure
  Log:
  Add XPG/4 switch for ReliantUNIX/SINIX compilation
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.96.2.11 +1 -1  apache/src/Configure
  
  Index: Configure
  ===
  RCS file: /home/cvs/apache/src/Configure,v
  retrieving revision 1.96.2.10
  retrieving revision 1.96.2.11
  diff -u -u -r1.96.2.10 -r1.96.2.11
  --- Configure 1997/08/21 22:56:20 1.96.2.10
  +++ Configure 1998/01/09 14:50:50 1.96.2.11
  @@ -424,7 +424,7 @@
;;
   *-sni-sysv4*)
OS='SVR4'
  - CFLAGS=$CFLAGS -DSVR4
  + CFLAGS=$CFLAGS -DSVR4 -D_XPG_IV -DUSE_MMAP_FILES
DEF_WANTHSREGEX=yes
LIBS=$LIBS -lsocket -lnsl -lc
;;
  
  
  


cvs commit: apache-devsite commitpolicies.html

1998-01-09 Thread brian
brian   98/01/09 14:59:29

  Added:   .commitpolicies.html
  Log:
  
  
  Revision  ChangesPath
  1.1  apache-devsite/commitpolicies.html
  
  Index: commitpolicies.html
  ===
  HTML
  H1Policies for CVS commits./H1
  
  We are exploring a new system to help speed development,
  commit-then-review.  With a commit-then-review, we trust that
  committers have a high degree of confidence in their committed patches
  - higher than the typical [PATCH] post to new-httpd.  This is an
  attempt to come up with a standard we expect those with commit access
  to hold up to.
  
  P
  
  UL
  LI The CVS tree should be expected to compile at all times
  LI Experimental new features must be discussed before implemented
  LI The committer is responsible for the quality of the third-party code
 they bring into the code.
  LI Related changes should be posted at once, or very closely together;
 no half-baked projects in the code.
  
  LI Any changes:/BR
UL
LIwhich affect symantics of arguments to directives 
LIwhich would have to be implemented differently on other architectures
LIwhich significantly add to the runtime size of the program
/UL
  need to be discussed on new-httpd before it gets committed, even 
experimentally.
  
  LI A patch must be reversed if the equivalent of a veto comes from
  another developer with commit access.
  
  /UL
  
  
  
  


Re: cvs commit: apache-devsite commitpolicies.html

1998-01-09 Thread Marc Slemko
On 9 Jan 1998 [EMAIL PROTECTED] wrote:

 brian   98/01/09 14:59:29
 
   Added:   .commitpolicies.html
   Log:
   
   
   Revision  ChangesPath
   1.1  apache-devsite/commitpolicies.html
   
   Index: commitpolicies.html
   ===
   HTML
   H1Policies for CVS commits./H1
   
   We are exploring a new system to help speed development,
   commit-then-review.  With a commit-then-review, we trust that
   committers have a high degree of confidence in their committed patches
   - higher than the typical [PATCH] post to new-httpd.  This is an
   attempt to come up with a standard we expect those with commit access
   to hold up to.
   
   P
   
   UL
   LI The CVS tree should be expected to compile at all times

with the exception of platforms with unique development environments that
require special effort to work with such as win32.

   LI Experimental new features must be discussed before implemented
   LI The committer is responsible for the quality of the third-party code
  they bring into the code.
   LI Related changes should be posted at once, or very closely together;
  no half-baked projects in the code.
   
   LI Any changes:/BR
 UL
 LIwhich affect symantics of arguments to directives 
 LIwhich would have to be implemented differently on other architectures
 LIwhich significantly add to the runtime size of the program
 /UL
   need to be discussed on new-httpd before it gets committed, even 
 experimentally.

Should API changes come into this too?

   
   LI A patch must be reversed if the equivalent of a veto comes from
   another developer with commit access.
   
   /UL