From owner-freebsd-ports@FreeBSD.ORG Sat Jan 25 02:38:40 2014 Return-Path: Delivered-To: freebsd-ports@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 DBE1A3E6; Sat, 25 Jan 2014 02:38:39 +0000 (UTC) Received: from mailout.easydns.com (mailout.easydns.com [64.68.200.141]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 754D012B2; Sat, 25 Jan 2014 02:38:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout.easydns.com (Postfix) with ESMTP id 249C312F7E3; Fri, 24 Jan 2014 21:34:36 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easydns.com Received: from mailout.easydns.com ([127.0.0.1]) by localhost (mailout.easydns.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOmp4bM0S80R; Fri, 24 Jan 2014 21:34:34 -0500 (EST) Received: from ares.hayers.org (cpc20-tilb7-2-0-cust491.20-1.cable.virginm.net [82.34.211.236]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easydns.com (Postfix) with ESMTPSA id B082A13027D; Fri, 24 Jan 2014 21:34:34 -0500 (EST) Received: from ares.hayers.org (ares.hayers.org [127.0.0.1]) by ares.hayers.org (Postfix) with ESMTP id 0D32DB06F68; Sat, 25 Jan 2014 02:33:08 +0000 (GMT) X-Virus-Scanned: HCF-Sophos-SpamAssassin at hayers.org Received: from ares.hayers.org ([127.0.0.1]) by ares.hayers.org (ares.hayers.org [127.0.0.1]) (HCF-Sophos-SpamAssassin, port 10024) with ESMTP id ajLO2-mm9WC7; Sat, 25 Jan 2014 02:32:55 +0000 (GMT) Received: from [192.168.8.105] (gw.hayers.org [82.34.211.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gary) by ares.hayers.org (Postfix) with ESMTPSA id 522F4B05864; Sat, 25 Jan 2014 02:32:55 +0000 (GMT) References: <52E2FA36.5080106@marino.st> <52E303CB.6020304@marino.st> <52E30990.2060903@marino.st> Mime-Version: 1.0 (1.0) In-Reply-To: <52E30990.2060903@marino.st> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <75CD14E1-DF0F-4085-821A-3C461BCF8B72@hayers.org> X-Mailer: iPhone Mail (11B554a) From: "Gary J. Hayers" Subject: Re: What is the problem with ports PR reaction delays? Date: Sat, 25 Jan 2014 02:32:55 +0000 To: "marino@freebsd.org" Cc: Big Lebowski , "marino@freebsd.org" , freebsd-ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 02:38:40 -0000 On 25 Jan 2014, at 00:47, John Marino wrote: >=20 >> On 1/25/2014 01:36, Big Lebowski wrote: >> I was hoping to get some discussion revealing how the work is organized >> around ports PR, perhaps some ideas on improving them and I hoped that >> people who can make decisions and changes would notice it and consider >> them, since as they say, the squeeky wheel gets the grease, that's all. A= t >> no point I insisted on forcing anyone to anything, and I dont think that'= s >> neither only nor a viable solution. >>=20 >> It seems obvious that current process doesnt work very well, then I'd aim= >> at reorganizing that process - it appears that there is no roles specifie= d, >> so the responsibility is blurred, and when everyone is responsible for on= e >> thing, in practice no one is. Perhaps role assignment could be of any hel= p? >=20 > I'm not trying to be a jerk, but surely I'm coming off that way. > Again, nobody is obligated to accept any assignment. They have to > volunteer to do it. The only person that The Big Lebowski can influence > here is himself. >=20 > Thus, are you volunteering for this role? =20 That's a role I would happily volunteer to do.=20 > It's not my call, but if you > really want to do clean out and triage the all PRs on an ongoing basis, > my guess is that would be very welcome and we'd figure out a way to set > that up. It would definitely help, especially for those maintainer that > "approve" patches but the PRs never get opened (or set to a better state > than "open"). Perhaps triage of all new (and existing PRs until caught up) is the way to g= o.=20 > At some point we'll have a new PR system, that fact might be having an > impact on current PRs=20 -- Regards,=20 Gary J. Hayers=20