Subject: Re: CVS commit: src/sys
To: Michael van Elst <>
From: Elad Efrat <>
List: tech-security
Date: 06/24/2007 19:12:05
Michael van Elst wrote:
> (Elad Efrat) writes:
> Elad,
>> see above: first commit, then talk = wrong. first talk, then commit if
>> a consensus is reached = right.
> you may wish for that, but the reality looks more like:
> first commit, then talk, then fix -> progress
> first talk, never reach consensus -> starvation

interesting. in what project that is how things happen? moreover: in
what project things usually go in the tree without peer review?

surely, you're not going to say openbsd, or freebsd, or linux, are you?

I am also looking at this page:

titled "netbsd commit guidelines", and claiming that:

     "The following Commit Guidelines define the Project's standards for
      making commits to the source tree:"

and further below:

     4. The more intrusive your changes are the higher is the level of
        required prior approval.

     * "Obvious" fixes can be committed without any prior discussion or
       review. (The definition of "obvious" in the GCC Project is: "could
       not possibly cause anyone to object." We adopt this definition

     * All other (i. e. "non-obvious") fixes should have a review.

     * Implementing (significant) new features requires a prior
       discussion on an appropriate technical mailing list.

     * Changing existing interfaces in libraries or in the kernel
       requires prior approval by Core.

this conflicts with what you're saying pretty severely. so I suggest
that if the project wishes to first commit, then test/discuss/review (if
anyone notices) -- the commit guidelines be changed. otherwise, it is
quite obvious that dsl@ violated the netbsd commit guidelines, and
appropriate action needs to be taken.

starting with reverting the relevant changes will be a good start.