Michael van Elst wrote:
> e@murder.org (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:

http://www.netbsd.org/developers/commit-guidelines.html

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
       here)

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

-e.