From owner-svn-ports-all@FreeBSD.ORG Mon Dec 2 14:48:41 2013 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 6835C980; Mon, 2 Dec 2013 14:48:41 +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 28DD719D6; Mon, 2 Dec 2013 14:48:41 +0000 (UTC) Received: by huppa.tuxaco.net (Postfix, from userid 1001) id DD30522838; Mon, 2 Dec 2013 15:52:24 +0100 (CET) Date: Mon, 2 Dec 2013 15:52:24 +0100 From: Philippe =?iso-8859-1?Q?Aud=E9oud?= To: marino@freebsd.org Subject: Re: svn commit: r335281 - in head: . audio audio/gnump3d Message-ID: <20131202145224.GH71618@tuxaco.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <529C91F2.6020004@marino.st> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-ports-head@freebsd.org, Rene Ladan , svn-ports-all@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 14:48:41 -0000 On Mon, 02 Dec 2013, John Marino wrote: > On 12/2/2013 14:49, Philippe Aud=E9oud wrote: > >=20 > > Ok, just calm down, every thing gonne be all right... I didn't challenge > > him, but I won't debate anymore, you don't look to be opened to a > > debate. > >=20 > > My personal think is : I was on week-end and i don't use computer on > > week-end. I guess this delete commit could wait 2 days. >=20 >=20 > Why should it? It was the date you defined. > Rene is right to assume that the port maintainer isn't intending to > delete the port in a timely fashion because it almost never happens. > Your desire to delete the port yourself on the expiration date is > exceptional. >=20 >=20 > >> > >> This is the situation today. My position is that this is a bad policy. > >> I say we should not have to wait 2 weeks to unbreak a port and your > >> response is "wait up to 2 weeks to unbreak a port". Perhaps I > >> misunderstood you, but that's what I understood. > >> > >=20 > > And, if rules are not good, i break them? I disagree with highway code, > > and i should break it only because i'm not aware? >=20 >=20 > 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 > 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/polici= es.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. =66rom : http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.= html --=20 Philippe Aud=E9oud=20