On 9 Jan 1998 [EMAIL PROTECTED] wrote: > brian 98/01/09 14:59:29 > > Added: . commitpolicies.html > Log: > > > Revision Changes Path > 1.1 apache-devsite/commitpolicies.html > > Index: commitpolicies.html > =================================================================== > <HTML> > <H1>Policies 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> > <LI>which affect symantics of arguments to directives > <LI>which would have to be implemented differently on other architectures > <LI>which 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> > > > > >