From owner-freebsd-ports@FreeBSD.ORG Fri Jul 9 20:51:24 2010 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 237DB1065673; Fri, 9 Jul 2010 20:51:24 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 9E57E8FC13; Fri, 9 Jul 2010 20:51:23 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id E803A8A2152; Fri, 9 Jul 2010 22:51:01 +0200 (CEST) Message-ID: <4C378BB5.2080206@bsdforen.de> Date: Fri, 09 Jul 2010 22:51:01 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.10) Gecko/20100627 Thunderbird/3.0.5 MIME-Version: 1.0 To: Shaun Amott References: <4C374B3E.90704@bsdforen.de> <20100709172503.GA22795@charon.picobyte.net> <4C375E47.9020307@bsdforen.de> <20100709200016.GA23404@charon.picobyte.net> In-Reply-To: <20100709200016.GA23404@charon.picobyte.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: Solutions for the PR load problem 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: Fri, 09 Jul 2010 20:51:24 -0000 On 09/07/2010 22:00, Shaun Amott wrote: > On Fri, Jul 09, 2010 at 07:37:11PM +0200, Dominic Fandrey wrote: >> >> On 09/07/2010 19:25, Shaun Amott wrote: >>> On Fri, Jul 09, 2010 at 06:15:58PM +0200, Dominic Fandrey wrote: >>>> >>>> To solve this problem with the current organization, my guess is >>>> that between 15 and 30 new active committers are required. >>>> Because I don't think this is easily achieved I want to suggest >>>> a different approach. And I expect many others also have their >>>> own ideas how this can be solved. >>>> >>>> Proposal: >>>> My idea is that experienced Maintainers get commit permission >>>> for their own ports. I don't even think such a thing needs to >>>> be enforced technically, after all who'd want to risk his >>>> experienced maintainer bit, however this is possible (and people >>>> would probably sleep better). >>>> > > (apologies for my dodgy quoting...) > >>> >>> The whole VCS debate has been had over and over; I think that for the >>> time being it is more constructive to look at changes we can make to our >>> existing processes. Anything that requires switching from CVS isn't >>> going to happen any time soon. >> >> You can also do this with CVS. > > Ok - but how do we define "experienced"? Someone who has submitted 100 > PORTVERSION++ PRs? I'm not convinced we have enough contributors who are > experienced enough to be given commit rights, but not contributing > enough to be offered full access. Well, I don't see a mass recruiting plan in action and the typical response time for a ports PR has dropped from a couple of hours to something around a month following a singular event everyone here probably already knows about. Though there are a lot of committers, there aren't many active committers. The need seems obvious to me and I figured it would be obvious to create some middle ground where the demands from both sides are less. > Cases where other ports need touching (e.g., library bumps), or an > update depends on another port/PR elsewhere could prove to be > problematic. Those are the kind of maintainers that have the commit bit anyway. People who do the major stuff like Xorg, KDE, gnome, autobreak ... I think those are also the people who carry the main burden of Maintainer PRs. They really shouldn't have to, they've got more than enough work. >>> One thing that is sorely missed -- by me, at least -- is the ports >>> tinderbox mini-cluster we had previously (graciously provided by simon >>> and erwin). The major bottleneck in the review/commit process is the >>> testing part (again, I speak for myself). A set of tinderbox machines >>> representing the tier-1 architectures, to which we could grant >>> contributors access, would reduce the burden on committers (if a >>> patch/PR arrives with an accompanying log file). >> >> What needs to be done? (I.e. money, work hours) > > Machine(s), rack-space, someone to maintain said machines to a decent > standard. Possibly money could solve these issues. :-) > > I'm not sure how many non-committers were aware of / given access to tb3 > and tb4 when they were around, but if tinderbox were used as a matter of > course, it would, I believe go some way to speeding things up. > So if I set up a private tinderbox and provide amd64 and i386 6-/7-/8-stable logs with every PR I submit it would hasten the processing of my PRs? If that is so, I'll get me a small quad-core with ~16GB RAM and a huge hard disk just for this purpose (my largest hard disk is the one in my notebook, not sufficient for all the distfiles and packages). Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?