You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1998/01/10 00:08:13 UTC
Re: cvs commit: apache-devsite commitpolicies.html
On 9 Jan 1998 brian@hyperreal.org 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>
>
>
>
>
>