From owner-svn-ports-head@FreeBSD.ORG  Mon Dec  2 10:28:46 2013
Return-Path: <owner-svn-ports-head@FreeBSD.ORG>
Delivered-To: svn-ports-head@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1033)
 id 9A20BE49; Mon,  2 Dec 2013 10:28:46 +0000 (UTC)
Date: Mon, 2 Dec 2013 10:28:46 +0000
From: Alexey Dokuchaev <danfe@FreeBSD.org>
To: marino@freebsd.org
Subject: Re: svn commit: r334598 - head/cad/kicad-devel
Message-ID: <20131202102846.GA73068@FreeBSD.org>
References: <201311221507.rAMF7cFW029817@svn.freebsd.org>
 <20131122155340.GA57808@FreeBSD.org>
 <alpine.WNT.2.00.1312021004480.3396@ux32.win.rm-i.net>
 <529C5DB1.6040800@marino.st>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <529C5DB1.6040800@marino.st>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: svn-ports-head@freebsd.org, mike <mike@reifenberger.com>,
 svn-ports-all@freebsd.org, ports-committers@freebsd.org
X-BeenThere: svn-ports-head@freebsd.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: SVN commit messages for the ports tree for head
 <svn-ports-head.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-ports-head>,
 <mailto:svn-ports-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-ports-head/>
List-Post: <mailto:svn-ports-head@freebsd.org>
List-Help: <mailto:svn-ports-head-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-ports-head>,
 <mailto:svn-ports-head-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 10:28:46 -0000

On Mon, Dec 02, 2013 at 11:15:13AM +0100, John Marino wrote:
> On 12/2/2013 10:12, mike wrote:
> > I assumed that its obvious that a port gets only hardcoded to gcc in the
> > case of a build error with clang.
> > 
> > So the commit line should have been:
> > 
> > Use gcc for now because of an build error with clang.
> 
> That's hardly better.

Right.  It's yet again pretty much obvious that one had to use different
compiler because of the build issues with default one (Clang).

> Why not include the actual error in the commit message?
> That is done often to justify marking it as broken, it could also be
> done to explain the workaround.

Yes, few lines of the build log would be better.  Alternatively, short
analysis can be provided, which should answer questions like "so why it
was not patched instead?" or similar.

The first thing I try when I see unexplained USE_GCC is to fix the port.
If I had the reasoning upfront, I would not waste time of trying to patch
tricky code with lots of nested functions, for example.

> P.S.  To be fair, many folk here offer notoriously bad commit messages,
> frequently.  I'm not sure why, maybe they just don't recognize it.

The only way is: raise the issue, write follow-ups, improve awareness,
lead by example. :)

./danfe