cvs commit: src/sys/conf Makefile.amd64 Makefile.arm Makefile.i386 Makefile.ia64 Makefile.pc98 Makefile.powerpc Makefile.sparc64 Makefile.sun4v src/usr.sbin/config configvers.h

[Wojciech A. Koszek]

On Sun, May 13, 2007 at 01:19:39PM +0100, Robert Watson wrote:
> 
> On Sun, 13 May 2007, Wojciech A. Koszek wrote:
> 
> > Log:
> > Bump config(8) version and build requirement for config(8) to 600006. This
> > is caused by my latest changes to config(8). You're supposed to install 
> > new
> > config(8) in order to prevent yourself from seeing a warning about old
> > version of that tool.
> >
> > You should configure the kernel with a new config(8) then.
> >
> > Oked by:        rwatson, cognet (mentor)
> 
> In typical FreeBSD parlance, we use one or both of:
> 
> Reviewed by:	whomever
> Approved by:	whomever
> 
> The former states that the persons(s) in question have at least read, and 
> possibly also tested, the changes, and is vouching for their reasonableness.
> 
> The latter states that the person(s) in question have authorized a commit, 
> typically in the role of a subsystem maintainer, mentor, release engineer, 
> or security officer.  Sometimes it comes in the form:
> 
> Approved by:	re (whomever)
> Approved by:	security-officer (whomever)
> Approved by:	whomever (mentor)
> 
> I don't claim that this is consistent. :-)
> 
> I've noticed an increasing number of "OKed" commits lately -- I'd prefer it 
> if we stuck to our existing nomenclature with respect to how we annotate 
> changes with respect to review and approval.  Among other things, it makes 
> the commit messages more mechanically parseable, and avoids ambiguity.

Good suggestion. In the past I matched those rules and I plan to follow
them in the future. Thanks for pointing this out.

-- 
Wojciech A. Koszek
wkoszek at FreeBSD.org
http://FreeBSD.czest.pl/dunstan/