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 1NUm6i-0002lp-0l for garchives@archives.gentoo.org; Tue, 12 Jan 2010 19:08:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CF8DAE0963; Tue, 12 Jan 2010 19:07:56 +0000 (UTC) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by pigeon.gentoo.org (Postfix) with ESMTP id B97C9E0963 for ; Tue, 12 Jan 2010 19:07:56 +0000 (UTC) Received: from gw.thefreemanclan.net ([unknown] [96.245.54.62]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KW500I1PEGRUAA6@vms173017.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Tue, 12 Jan 2010 13:07:39 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gw.thefreemanclan.net (Postfix) with ESMTPS id 97642175AADF for ; Tue, 12 Jan 2010 14:07:38 -0500 (EST) Message-id: <4B4CC87A.80503@gentoo.org> Date: Tue, 12 Jan 2010 14:07:38 -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> <201001121832.11523.hwoarang@gentoo.org> <20100112192159.0fa03cd1@epia.jer-c2.orkz.net> <201001122030.27164.hwoarang@gentoo.org> In-reply-to: <201001122030.27164.hwoarang@gentoo.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: 91103b77-c1ec-419d-a27f-8b81d76dbaf4 X-Archives-Hash: 73d5df028f5afce65b7859f1b0f967e1 On 01/12/2010 01:30 PM, Markos Chandras wrote: > IMHO ( this is not a treecleaners@ opinion, i m just talking for my > self ), announcing and masking a package is a good way to inform and wake up > everybody to take care of this package if they really really want to stay on > portage. I agree with the announce part, and the THREAT of masking. I just don't think that the masking should happen at the same time as the announcement. > Having open bugs for months isn't a way to let everybody know that this > package is broken for long time, so it is a valid candidate for removal? > Should we send that via e-mail as well? I don't think an open bug constitutes notice. It is valid notice to the maintainer of the package, but not to the larger community. I probably have 100-200 packages installed, and I'd probably be annoyed if any of them went away (I'm still missing kdirstat, but that isn't really the kde team's fault). If an important one was about to go away I might step in to maintain it, and I'm sure a lot of other people feel the same way. At the same time, I can't monitor the bugs on 100-200 packages - that is the reason for having a maintainer. I think the concern is that some maintainers don't respond in a timely manner. Now, I don't know that maintainers have an obligation to fix every bug within a certain timeframe - some packages are problematic and I'm not sure that we should discard a 98% solution in favor of a 0% one because we don't have a 100% one. However, serious issues should be in scope for treecleaners, but the first goal should be to find a maintainer, and only if that fails should we consider masking. Also - if a maintainer can't be found we might also try to coordinate with the Sunrise folks to see if they're willing to take it over. We should also solicit proxy-maintainers among the user community when we announce pending removals. That could be very helpful with something like inn: I use it VERY lightly and I'm not a news guru, but I am a dev. I bet we have users who are news gurus and who care about inn, but they aren't Gentoo devs. Together we could probably cover the gaps and I'm sure devs would be more willing to pick up a package if they knew they had some help with the nuances of the package itself. If that falls apart later, at least an active dev is assigned to the package, and they can always decide to try to find a new maintainer or kill the package (saving treecleaners the work of doing so). In short - treecleaners should be about getting packages back into the mainstream maintenance model, with removal being the fallback option if that doesn't work. They shouldn't have to go out of their way to do this, but an advance announcement and some coordination is probably a good idea. Rich