From owner-freebsd-ports@FreeBSD.ORG Wed Jul 18 11:00:20 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE5BF106566B; Wed, 18 Jul 2012 11:00:19 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 953EC8FC19; Wed, 18 Jul 2012 11:00:19 +0000 (UTC) Received: from [192.168.0.225] (atoulouse-256-1-130-170.w90-45.abo.wanadoo.fr [90.45.57.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 0068243BA3; Wed, 18 Jul 2012 06:00:17 -0500 (CDT) Message-ID: <50069739.3090607@marino.st> Date: Wed, 18 Jul 2012 13:00:09 +0200 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org, Chris Rees References: <50017C97.3050200@filez.com> <20120714192119.GA61563@vniz.net> <5001CB97.6070205@filez.com> <50054F6E.9040002@filez.com> <50055293.3010002@FreeBSD.org> <20120717213902.GB21825@lonesome.com> <5005E2AE.3040806@marino.st> <20120717224302.GA26742@lonesome.com> <50065B3B.8040404@marino.st> <500690C9.5080700@marino.st> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: maintainer timeout for FreeBSD commiters X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 11:00:20 -0000 On 7/18/2012 12:40, Chris Rees wrote: > > You are making a good point, but I'm trying to explain that the 'body of > work' for proposing a new developer is no greater than the standard you > suggest. > > We do have developers who only commit to their own ports; while it's > generally hoped that they work on PRs too, it's not a requirement. These > would fall under the category of 'super maintainers' if you like. > > For further reading, Google 'Solutions for the PR load problem'. > A very interesting read and essentially addresses the topic I started, with a different implementation. You've been consistent in your concern, but maybe what I'm getting at is that these "super maintainers" don't need to be held to the same standard as someone with a commit bit. Hopefully they are every bit as capable as a committer, but if they are only interested in maintaining say < 10 ports and those ports aren't in the critical path of more important ports, what's the harm in handing the reins to a slightly less experienced person that wants to do it esp. with a large PR backlog? If it passes lint and tinderbox checks, it's got to have some (acceptable) quality level. Over time and with experience the maintainer will improve anyway, especially if he/she is also directly any PRs against the port. That's another topic -- these super maintainers should be able to close PRs as well on their ports. Speaking for myself, I think I'd make a good super-maintainer and I think the quality would be very high on my ports. I know I'm not alone. John