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.
Dean
|