From owner-svn-ports-head@FreeBSD.ORG Mon Dec 2 13:33:48 2013 Return-Path: Delivered-To: svn-ports-head@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 39806F8D; Mon, 2 Dec 2013 13:33:48 +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 0B3D51393; Mon, 2 Dec 2013 13:33:47 +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 6349343B8C; Mon, 2 Dec 2013 07:33:35 -0600 (CST) Message-ID: <529C8C1F.7050802@marino.st> Date: Mon, 02 Dec 2013 14:33:19 +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> In-Reply-To: <20131202131244.GC71618@tuxaco.net> X-Enigmail-Version: 1.6 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 Reply-To: marino@freebsd.org 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 13:33:48 -0000 On 12/2/2013 14:12, Philippe Audéoud wrote: > On Mon, 02 Dec 2013, John Marino wrote: > >> On 12/2/2013 11:43, Philippe Audéoud wrote: >>> I don't do a big deal but I like the idea to respect others job. If i >>> was known to not update my ports when needed, I can understand that >>> someone is doing my job. >> >> Well, actually you did make a big deal about it, but let's talk about >> the other thing. >> > > Excuse me to tell my opinion! I just asked for an explanation and I didn't > reproach anything. But ok, if you want I'm making a big deal with it. Yes, that's my definition of a big deal. The port was deleted as desired and on-time. The correct thing happened, but Rene was challenged as if he did something wrong. Hundreds of ports have been deleted in the last few months and this is the first challenge I've seen. >>> When i take the maintainership of a port, I interpret it as "I'm taking >>> care of this port and thanks to let me know if you want to do something >>> with". >>> If I follow your idea, ok, let's commit on all maintainer's port without >>> approval. Then, the idea of maintainer is useless. >> >> Let me be clear: If the change is a patch to make it work better, or >> improve the functionality, address options, or basically any change to >> what the maintainer *intended* then of course it needs the permission of >> the maintainer. >> >> However, if it's a missing dependency, or a typographical error, or >> something really REALLY obviously and it's *broken* because of it, then >> no, I don't think those cases should require writing a PR and >> potentially waiting 2 weeks for it to time out. The number of >> non-responsive maintainers vastly outnumbers those that respond quickly >> and that includes those with @freebsd.org addresses. > > Agree but it's not our case. It's not a big issue neither a broken > change. Right, it's even more trivial. > >>> So, again, i don't do a big deal but as an active maintainer, I don't >>> like someone else is doing my job whitout asking. >> >> Port deletion isn't necessarily "your job". The vast majority of ports >> are deleted by someone other than the maintainer. >> > > Deleting a port *I maintain* is my job as to mark it deprecated. I have never seen it documented that port deletion is solely the responsibility of the (previous) port maintainer. Can you point to where this is documented? I'd even argue that after the expiration date, the port is unmaintained by definition. > >> I really hope portmgr@ starts addressing cases where other maintainers >> can help with obvious breakage. Obviously it needs to be written and >> defined clearly so that we have something to point to when the listed >> maintainer gets touchy about it (which they should not be). >> >> Now, I will say that if one dares to touch a port maintained by another, >> the change he or she makes had better be correct! Making the wrong >> change to someone else's port is justification for them getting upset. > > Then, you can send a PR and wait for a time-out. > > Now, to close this debate: I don't care that rene@ deleted this port, I > just think that we (as committer) don't have full right on all ports. > You want a change (minor or major) for a port that you don't maintain and > not in ports@, you have to send a pr except for changes describe in > committer guide. Or maybe you can send an email, communication doesn't > cost but it's good to use it. 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. > Ok, now, can we please stop this debate and work on freebsd? I'm not stopping you, but this is a perfect example of somebody way too protective of their own ports which is to the detriment of the project as a whole (that's my opinion of course, but I know that opinion is shared by others.) The point is that the current policy favors *your* position, I think that's bad as this policy causes a lot on unnecessarily bureaucracy and hurts users with longer-than-needed downtime and I think it needs to be revised. Also assume that there are cases where a port would have been fixed on the spot, but the hoop jumping of writing a PR and waiting too weeks is too substantial and results in that person not fixing the port at all. Nobody wins.