From owner-svn-ports-head@FreeBSD.ORG Mon Dec 2 15:04:42 2013 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6DC6DD4; Mon, 2 Dec 2013 15:04:42 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 885651AE5; Mon, 2 Dec 2013 15:04:41 +0000 (UTC) Received: from [10.31.10.22] (unknown [213.225.137.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id AD2D6438BD; Mon, 2 Dec 2013 09:04:26 -0600 (CST) Message-ID: <529CA16C.2060000@marino.st> Date: Mon, 02 Dec 2013 16:04:12 +0100 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Philippe_Aud=E9oud?= Subject: Re: svn commit: r335281 - in head: . audio audio/gnump3d References: <201311301102.rAUB2I21004889@svn.freebsd.org> <20131202093409.GA71618@tuxaco.net> <529C5F05.6020706@marino.st> <20131202104324.GB71618@tuxaco.net> <529C689B.9050902@marino.st> <20131202131244.GC71618@tuxaco.net> <529C8C1F.7050802@marino.st> <20131202134921.GD71618@tuxaco.net> <529C91F2.6020004@marino.st> <20131202145224.GH71618@tuxaco.net> In-Reply-To: <20131202145224.GH71618@tuxaco.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: svn-ports-head@freebsd.org, Rene Ladan , svn-ports-all@freebsd.org, marino@freebsd.org, ports-committers@freebsd.org X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:04:42 -0000 On 12/2/2013 15:52, Philippe Audéoud wrote: > On Mon, 02 Dec 2013, John Marino wrote: >> >> You are misrepresenting me. I follow the rules, but they are crappy >> rules so I'm complaining about them. Rene did not break any rules that >> I am aware of. (You conveniently did not show me where this "rule" is >> documented, nor why you think port maintenance privilege extends past >> the expire deadline). > > 4. Respect existing maintainers if listed. > > Many parts of FreeBSD are not "owned" in the sense that any specific > individual will jump up and yell if you commit a change to "their" area, > but it still pays to check first. One convention we use is to put a > maintainer line in the Makefile for any package or subtree which is > being actively maintained by one or more people; see > http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html > for documentation on this. Where sections of code have several > maintainers, commits to affected areas by one maintainer need to be > reviewed by at least one other maintainer. In cases where the > "maintainer-ship" of something is not clear, you can also look at the > repository logs for the file(s) in question and see if someone has been > working recently or predominantly in that area. > > Other areas of FreeBSD fall under the control of someone who manages an > overall category of FreeBSD evolution, such as internationalization or > networking. See http://www.FreeBSD.org/administration.html for more > information on this. > > from : > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.html > 1. Clearly it does not address port deletion specifically. 2. I openly questioned whether or not the MAINTAINER line expired with the port. I believe it should. After the expiry date, it should be treated as if MAINTAINER=ports@freebsd.org (meaning anybody at all can delete it if they feel like it.) 3. This is the clause that needs updating. It gives too much power to the listed MAINTAINER. It could and should allow others to fix the port if it restores the port to how the maintainer intended. People are abusing this clause and the result is that ports that could be fixed correctly on the spot are not fixed in a timely fashion (sometimes delaying weeks or months or perhaps never getting fixed). Some of this "power" needs to be clawed back. I will fully support any maintainer who is angry at another committer than "fixes" their port incorrectly though. I think the benefits of allowing others to fix ports-with-listed-maintainers outweighs the negatives by a lot. John