From owner-freebsd-ports@FreeBSD.ORG Thu Apr 28 18:52:39 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from apollo.emma.line.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D35D61065674 for ; Thu, 28 Apr 2011 18:52:38 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [IPv6:::1] (unknown [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 68BEE25AD7F for ; Thu, 28 Apr 2011 15:42:33 +0200 (CEST) Message-ID: <4DB96EC9.8000506@FreeBSD.org> Date: Thu, 28 Apr 2011 15:42:33 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Mnenhy/0.8.3 Thunderbird/3.1.8 MIME-Version: 1.0 To: freebsd-ports@freebsd.org References: <4DB7B237.7000603@marino.st> <20110427075436.70ae18ac@seibercom.net> In-Reply-To: <20110427075436.70ae18ac@seibercom.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: How are [MAINTAINER] patches handled and why aren't PRs FIFO? 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: Thu, 28 Apr 2011 18:52:39 -0000 Am 27.04.2011 13:54, schrieb Jerry: > Personally, I believe that the current system, if not partially broken, > is far from ideal. I would prefer to see a system where each submitted > PR is assigned a specific number (I believe it is actually) and then > assigned in numeric order to the next available committer. That > committer would then be responsible for either committing the > PR/Port/Whatever within a preset time frame, or informing the original > submitter why the said article was not/could not be approved at the > present time. Allowing a submitter to languish while pondering what has > become of their document certainly does seem justified. Greetings, I know from the times when I wasn't a committer that it was sometimes frustrating if PRs were lingering for weeks. Your idea of assigning ports to committers rests upon the assumption that all port/update submissions were equal with respect to the sub-tasks to be performed by a committer, and/or the required skills. I for one am not knowledgeable about Ada or the related build systems such as GNAT ports, so I'd not usually pick up such a PR - Robert Huff mentioned something similar yesterday. Then there are many more non-trivial commits, with downstream dependencies, or dangerous to other ports, and these require more thorough testing, building downstream ports, possibly an experimental build of ALL ports, the so-called -exp run, documenting updating requirements and so on. These take time, and I've recently returned a port which, thankfully, mentioned "-exp run advised" or similar, that I couldn't tend to due to vacation, lack of time for holiday preparations, never having requested an -exp run before IOW I'd need to get acquainted with the procedures, and all that. > I am sure that the old, "But they are all volunteers", or some such > tirade will erupt. It must be remembered that those who submit items for > approval are also volunteers. They deserve at least as much respect as > those who are actively working on those submitted items. True enough, but I think that committers are not disrespectful. I know that intent and feeling are different matters. I agree that transparency of the "why hasn't my PR been addressed" would be desirable to maintainers, but I don't see a technical solution to that, meaning that it requires manual action by committers. One idea might be to team up maintainers with committers somehow (I don't know how yet), so some kind of who-is-who list that Robert mentioned, might be useful. Providing it's up to date. But it requires setting up and maintenance, too. Again, I don't believe this kind of neglect is deliberate, as frustrating though it may be. Yes, we committers can do better, and it seems we're in some kind of unfreezing before a non-trivial change, and that thinking and talking about *how* to change our procedures has started and looks promising IMHO, and I've also skimmed Charlie-Hester's-stepping-down thread with pity (although I believe some misunderstanding, possibly across language boundaries, on both sides was a major part of that problem) It all will require some work before we will have changed though, procedural changes don't happen in a few days. Not with 20000+ ports and established policies and procedures behind us anyways. So if we can abstract away from the frustration of individual ports not getting addressed to ideas HOW we can PRACTICALLY improve, we may actually achieve that desired improvement. I hope you can bear with us while we ponder the required changes. Best Matthias