From owner-svn-ports-all@FreeBSD.ORG Wed Jul 30 11:06:54 2014 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F8D1D8D; Wed, 30 Jul 2014 11:06:54 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E54262CFD; Wed, 30 Jul 2014 11:06:53 +0000 (UTC) Received: from [192.168.0.21] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 8637D43552; Wed, 30 Jul 2014 06:06:23 -0500 (CDT) Message-ID: <53D8D19E.7090407@marino.st> Date: Wed, 30 Jul 2014 13:06:06 +0200 From: John Marino Reply-To: marino@freebsd.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: olli hauer , marino@freebsd.org, Mathieu Arnold , Max Brazhnikov , Alexey Dokuchaev Subject: Re: svn commit: r363361 - in head/editors/fte: . files References: <201407291646.s6TGkjHH090335@svn.freebsd.org> <41D25BC1-AC62-4280-A342-8A2BDD84B1E0@adamw.org> <20140730070412.GA97692@FreeBSD.org> <3898057.T8DsoXnEEp@mercury.ph.man.ac.uk> <53D89EBF.4080805@marino.st> <2D24420529C9ECAEABB9A791@atuin.in.mat.cc> <53D8A2BB.7090704@marino.st> <53D8CBDE.6050008@gmx.de> In-Reply-To: <53D8CBDE.6050008@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 Jul 2014 11:39:58 +0000 Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, William Grzybowski , Adam Weinberger X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 11:06:54 -0000 On 7/30/2014 12:41, olli hauer wrote: > On 2014-07-30 09:46, John Marino wrote: >> Take a vote. I'd bet the majority of people do not like "__" not >> just "someone". > > I like the `make makepatch' convention, it is simple and you can get > the path directly from the patch name without less/cat ... That implies other conventions don't allow that, which is clearly not true. Danfe's issue is the double underscore for the separator for multiple reasons. Obviously I agree with his reasons. > Using the `make makepatch* command has also the charm every patch follows at > last a simple rule and you don't have to fiddle around with manual > renaming, everyone is able to produce the same patch. The issue isn't about what the tool does, but what naming rule it implemented. You can change the naming rules without discarding the tool. > About pkgsrc, I really don't care because the discussion is about > FreeBSD standards that others can easily adopt and with `make > makepatch' a simple standard and tool was added years ago. I only mentioned pkgsrc in response to the "surprise" shown by mat that somebody wouldn't use makepatch. Pkgsrc has had many superior features to ports, and bapt has borrowed ideas directly from it to reduce the technical gap. Give the project credit where they earned it. In that case I was talking about the tool, not the naming rules (although it does have been naming rules) > > So I welcome the work that was done recently by adjusting the patch > file name. Well, nobody is clamoring for "::" separators which are actually documented illegal so it's not like that was controversial. I do think the negative aspect of these changes weren't considered though: A bunch of PRs probably just broke because of all these name changes and USE_* fixes etc. I was happy with fixing them when the port was touched for other reasons. And I already got burned by in-word changes to cdcat which was affected by these unnecessary commits. For the USE_* fixes, the gain is the remove code from bpm, but these patch renames didn't gain anything and probably broke a ton of diffs to those patches in PRs. John