Subject: Re: CVS commit: src/sys
To: Michael van Elst <email@example.com>
From: Elad Efrat <firstname.lastname@example.org>
Date: 06/24/2007 19:12:05
Michael van Elst wrote:
> email@example.com (Elad Efrat) writes:
>> 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.