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 1NWbzF-0005da-BK for garchives@archives.gentoo.org; Sun, 17 Jan 2010 20:44:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F34CE062B; Sun, 17 Jan 2010 20:44:23 +0000 (UTC) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by pigeon.gentoo.org (Postfix) with ESMTP id 4B84FE062B for ; Sun, 17 Jan 2010 20:44:23 +0000 (UTC) Received: from gw.thefreemanclan.net ([unknown] [96.245.54.62]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KWE00JS7S9FKQP2@vms173015.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Sun, 17 Jan 2010 14:44:15 -0600 (CST) Received: from [192.168.0.5] (rich.homedns.org [192.168.0.5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gw.thefreemanclan.net (Postfix) with ESMTPS id AD6601759FBF for ; Sun, 17 Jan 2010 15:44:02 -0500 (EST) Message-id: <4B537692.6080200@gentoo.org> Date: Sun, 17 Jan 2010 15:44:02 -0500 From: Richard Freeman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091229 Thunderbird/3.0 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] Re: Last rites: net-nntp/inn References: <201001112305.16532.hwoarang@gentoo.org> <20100115095008.5173fcbf@dante> <201001172120.48648.bangert@gentoo.org> In-reply-to: <201001172120.48648.bangert@gentoo.org> Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: ba80c557-55b7-4f19-b2ed-2aa8c7207bc1 X-Archives-Hash: a96919e3dbb00b4926ec73a6f2eb64d7 On 01/17/2010 03:20 PM, Thilo Bangert wrote: > Ben de Groot said: >> I think we have a bigger problem with packages that have a maintainer, >> at least nominally, but said maintainer does not actually maintain the >> package anymore. > > full ack. i was thinking that maybe we need an 'easy-fix' team, which can > do all the easy fixes, which have been laying around for way too long and > which aparently are "easy to fix" (ie. only waiting for somebody to > commit)... I think this is a good idea. Alternatively, perhaps if we just make a policy that it is acceptable for a dev to touch a package and leave it with QA problems, as long as it ends up with no more QA problems than it started with. Of course, devs are encouraged to fix QA problems whenever they can. This way devs will be more willing to make small fixes that generally improve the distro without being worried about being chewed out because they didn't go through the package with a fine-tooth comb looking for issues. That will at least get poorly-maintained packages trending in the right direction. Along with that I think we need to address the problem of packages that list a maintainer but which aren't maintained. Perhaps a solution would be to have some way to periodically ping maintainers to confirm they're still looking at a package. That could take many forms - a simple one would be to ask the maintainer to touch the metadata.xml file or something like that (obviously the manipulation has to be something that is noticed by CVS). On the other hand we don't want needless churn. Then an automated process can ping maintainers if they haven't done this, and after a delay the package would be set to maintainer-wanted. Actively-maintained projects would be allowed to use automation to keep packages they track marked fresh. However, the project does then become accountable for actually maintaining them. This would go along with an (unwritten but already in place) policy that anybody listed as a maintainer has to actually maintain the package, with consequences for not doing so to some defined standard. This standard would not be zero-bugs, but certainly anything real flagged by repoman or a violation of a written QA policy would be expected to be cleaned up in a timely manner. The goal is to make the maintainer field meaningful. Then we could figure out a policy for maintainer-wanted builds. My feeling is that as long as they build, don't have security issues, and don't have QA issues that genuinely get in the way of some Gentoo initiative, they can stay around. Once any of the above ceases to be the case they're announced on-list and then treecleaned. The bottom line though is that we can write all the rules we want - ultimately Gentoo needs warm bodies to fix bugs. No amount of process will get around that. What process can do for us, however, is to increase visibility of issues so that QA doesn't waste time hunting down inactive devs and so that people running servers or whatever can tell if a package is actively maintained.