cvs commit: ports/net Makefile ports/net/opendpi Makefile distinfo pkg-descr pkg-plist

[Alexey Dokuchaev]

On Wed, Nov 18, 2009 at 04:55:07PM +0200, Ion-Mihai Tetcu wrote:
> On Tue, 17 Nov 2009 20:46:49 +0000
> Alexey Dokuchaev <danfe at FreeBSD.org> wrote:
> > On Tue, Nov 17, 2009 at 09:13:12AM +0000, Martin Wilke wrote:
> > > miwi        2009-11-17 09:13:12 UTC
> > >   
> > >   PR:             ports/140539
> > >   Submitted by:   fernandotcl
> > 
> > $ finger fernandotcl at freebsd.org
> > [freebsd.org]
> > Trying 2001:4f8:fff6::28...
> > finger: socket(28, 1, 6): Protocol not supported
> > Trying 69.147.83.40...
> > finger: fernandotcl: no such user
> 
> This is the reason I argue in favor of writing committer names
> followed by an '@'

Actually, I usually follow these simple guidelines:

1. If one must reference a committer in log, use freefall login name;
   using full name and address should be avoided: it is both redundant
   and worsens the time required to read/comprehend commit message.

2. Committer login name (entity) should be followed by `@' to
   distinguish from other words in a sentence; with one exception: when
   used in standard tags like "Submitted/Reviewed/Approved/etc. by" --
   it is fairly obvious that "foobar" is foobar at FreeBSD.org here.  Non-
   FQPI (person identity) must not be used; i.e. if PR submitter did not
   reveal their full name, "Submitted by" tag should be dropped; PR
   number is sufficient enough to get the details (should it be required
   to contact submitter) and to give proper credit.

3. When FQPI is available and looks good[1], it can be recorded in the
   commit log, with the following restrictions:

   a. Quotation marks must be dropped around full name and/or address;
      while they can be useful in email headers, they are not in commit
      log;
   b. Names must be properly capitalized; redundant whitespace must be
      trimmed;
   c. Only pure ASCII characters should be used; it is silly to think
      that everyone uses your 8-bit code page for the second part of the
      table.

4. Simple spam-prevention techniques (e.g. obfuscating `@' in email
   addressen) can be used, but not required.

5. Use common sense.  :-)

./danfe

[1] E.g. it is not something like "uNDe4D kRaZZ`/ HaXXoR" or
"shitload at kernel.org".