From owner-svn-ports-all@FreeBSD.ORG Mon Dec 2 15:13:04 2013 Return-Path: Delivered-To: svn-ports-all@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 4EDF3327; Mon, 2 Dec 2013 15:13:04 +0000 (UTC) Received: from huppa.tuxaco.net (tuxaco.net [IPv6:2001:41d0:1:66c1::1]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D79D91B8F; Mon, 2 Dec 2013 15:13:03 +0000 (UTC) Received: by huppa.tuxaco.net (Postfix, from userid 1001) id 9416B22838; Mon, 2 Dec 2013 16:16:47 +0100 (CET) Date: Mon, 2 Dec 2013 16:16:46 +0100 From: Philippe =?iso-8859-1?Q?Aud=E9oud?= To: John Marino Subject: Re: svn commit: r335281 - in head: . audio audio/gnump3d Message-ID: <20131202151646.GI71618@tuxaco.net> References: <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> <529CA16C.2060000@marino.st> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <529CA16C.2060000@marino.st> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-ports-head@freebsd.org, Rene Ladan , svn-ports-all@freebsd.org, marino@freebsd.org, ports-committers@freebsd.org X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.17 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: Mon, 02 Dec 2013 15:13:04 -0000 On Mon, 02 Dec 2013, John Marino wrote: > On 12/2/2013 15:52, Philippe Aud=E9oud 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). >=20 > >=20 > > 4. Respect existing maintainers if listed. > >=20 > > 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/po= licies.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. > >=20 > > 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. > >=20 > > from : > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ru= les.html > >=20 >=20 >=20 > 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=3Dports@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). >=20 > 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. >=20 Sure but it has to be written. We are both complaining about this point, maybe we can work together and suggest somes rules/reflexion to portmgr@. --=20 Philippe Aud=E9oud