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 1Q3rSD-0004Xo-KY for garchives@archives.gentoo.org; Sun, 27 Mar 2011 15:00:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 213D61C0F9; Sun, 27 Mar 2011 15:00:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7BF8E1C0C6 for ; Sun, 27 Mar 2011 15:00:00 +0000 (UTC) Received: from [192.168.1.3] (ip-94-112-147-25.net.upcbroadband.cz [94.112.147.25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: scarabeus) by smtp.gentoo.org (Postfix) with ESMTPSA id 9164A1B401A for ; Sun, 27 Mar 2011 14:59:59 +0000 (UTC) Message-ID: <4D8F4F93.6030507@gentoo.org> Date: Sun, 27 Mar 2011 16:54:11 +0200 From: =?windows-1252?Q?Tom=E1=9A_Chv=E1tal?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110323 Lightning/1.0b3pre Thunderbird/3.1.9 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: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml References: <20110326055210.E906D20054@flycatcher.gentoo.org> <4D8EC104.4090503@gentoo.org> <4D8F3BE8.5050300@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: X-Archives-Hash: d238dd955629646f62af82a42f4676b8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 27.3.2011 15:44, Rich Freeman napsal(a): > On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa wrote: >> On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: >>>> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: >>> I propose that we should be more aggressive about package.masking (for >>> removal) all maintainer-needed packages from the tree by doing that >>> one month after they become maintainer-needed. If someone doesn't >>> volunteer to take care of it, it probably wasn't important anyway. >>> >> >> That is abit extreme for me (read: I don't have motivation to fight the >> flames), but I wouldn't complain if someone else did it to be honest. >> > > So, I'd like to propose that somewhere between adding stuff to the > tree that nobody has any intent to look after, and removing stuff that > has been around a long time with no clear problems, there is a happy > medium. > > How about this - if you add a package to the tree, you are responsible > for it for at least a year. If you can get somebody else to take it > then that is fine. If it has problems QA can flame you (privately at > first) for it, and you should feel appropriately embarrassed and fix > it, or remove it. > > After a year, it can go maintainer-needed. Before a year, it cannot, > and you either need to actually maintain it, or remove it. Developers > should not be adding packages they have no interest in whatsoever, or > that have so many QA issues initially that they're high-maintenance > right from the start. If a dev gets a package from a proxy-maintainer > and they disappear then they can nurse it along or remove it as makes > sense - we should be nice to these devs but we shouldn't just cut the > packages loose. > > Packages that are maintainer-needed stay around as long as they're not > making trouble. If they get lots of complaints they get announced on > -dev, and after two weeks they get masked if not picked up. If they > end up blocking something then likewise they get announced and then > masked. That basically is the current practice anyway. > > I don't see a need to remove m-n packages wholesale just to say that > we did it, or to punish users for not becoming devs or whatever. > > And of course, the usual long-term solutions like making > proxy-maintaining easier should be pursued. > > Rich > And how exactly you want to track the level of failure for the package? Since nobody is watching them already we usually don't know how much they fail until somebody tries to emerge them from dev team or notify QA by adding as CC to bug... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2PT5MACgkQHB6c3gNBRYdepgCfYUo00PKNQFoa+ZaqGoPTHOuv Dd8Ani+d1sa/jIHvrWyZrwOF3UUkESl8 =k1EI -----END PGP SIGNATURE-----