httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Change
Date Sat, 10 Jan 1998 03:24:04 GMT

On Fri, 9 Jan 1998, Brian Behlendorf wrote:

> The simple fact is that it won't be easy for us to review changes made to
> the code if it doesn't even compile.  If your projects doesn't compile,
> don't commit it.  I think you're saying the same thing.  So maybe changing
> #1 to "If your project doesn't compile, don't commit it" makes sense?

+1, or changing it to "if your project hasn't been tested, then don't
commit it" which is more specific.

> >> 3) The committer is responsible for the quality of the third-party code
> >>    they bring into the code.
> >
> >Definately, but follows from "the committer has tested the code they
> >commit". 
> More than that though; if the code has buffer overruns or security holes,
> it's the same as though the one doing the commit wrote code with similar
> problems.  Or if it doesn't use the API well, etc.  

Right and it's easier for someone reviewing the commit to make a change to
improve this situation.

> good point.  I think "code that doesn't do anything but just sits there and
> thus #ifdef 0" is what I'd call half-baked.  Or, code that is half-way to
> something really cool but significantly impacts the
> performance/functionality of another stable piece".  

Works for me.


View raw message