From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M4udf-0001Os-1x for garchives@archives.gentoo.org; Fri, 15 May 2009 10:27:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 722C2E0450; Fri, 15 May 2009 10:25:49 +0000 (UTC) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by pigeon.gentoo.org (Postfix) with ESMTP id 5DDF7E0450 for ; Fri, 15 May 2009 10:25:49 +0000 (UTC) Received: from gw.thefreemanclan.net ([68.162.77.227]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KJO0046LKYGZPLN@vms173003.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Fri, 15 May 2009 05:25:29 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 0584C1759C56 for ; Fri, 15 May 2009 06:25:28 -0400 (EDT) Message-id: <4A0D4317.7040702@gentoo.org> Date: Fri, 15 May 2009 06:25:27 -0400 From: Richard Freeman User-Agent: Thunderbird 2.0.0.21 (X11/20090321) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted References: <1242261133.23088.82.camel@localhost> <4A0B738F.3030000@allenjb.me.uk> <4A0C2E6B.1040107@gentoo.org> <200905150943.57830.bangert@gentoo.org> In-reply-to: <200905150943.57830.bangert@gentoo.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: 4eebb19e-0bf1-4057-8091-189a518e304f X-Archives-Hash: 107961896d5b25295bf23282d9c3fea1 Thilo Bangert wrote: > AFAIK, we have never explicitly made this distinction clear. if we had, we > would have to remove stuff from portage which doesnt live up to the > standards. > I'm all for that. In reality we tend to leave them alone until a security issue actually comes up, which is probably a reasonable compromise (since it also takes work to remove them). In any case, failure to completely meet a standard does not automatically imply that the standard is worthless. > it is also not true from a more real world perspective: there are many > packages in portage that have a standard which is much lower than what is > in some overlays. and there are many packages in overlays which live up to > a quality standard way above portage's average. > I don't think anybody has issues with overlays that choose to have higher quality standards than portage. I'm all for that. I'm concerned with the quality level in portage - since that is what we attach our name to. If some other repository wants to do a better job than more power to them! However, Gentoo cannot endorse "all overlays" as being official repositories, because clearly there is no standard for quality when all it takes to have an overlay is to set up an rsync or http server and put some ebuilds on it. > if you want to exaggerate a bit, we have roughly 500 ebuilds in portage > which are maintainer-needed and have only a few users and thats why you > want to keep popular packages out of the tree? > Actually, where any of those ebuilds cause problems I'm fine with getting rid of them. I'm certainly not arguing for inconsistency. I'm just suggesting that we shouldn't make the problem worse. If a package is popular then somebody should volunteer to maintain it (whether by becoming a gentoo dev or by starting their own overlay). If that isn't happening than clearly the package isn't THAT important. This is open source - if you have an itch, then scratch it! Don't just complain that nobody else is scratching YOUR itch (even if it is a popular itch). In any case, my opinion is that for packages to be in portage they should be of a certain level of quality, and a developer should be accountable for the packages they commit. Anybody is welcome to grab ebuilds out of CVS, screen them, and commit them. However, if they cause havoc then the developer can't just say "but it was popular and unmaintained, so I figured I'd just commit something without looking at it." If a developer is willing to commit an appropriate amount of time to QA then they essentially have become a maintainer and the package is no-longer maintainer-wanted.