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 1Q41jJ-0005Ru-Tk for garchives@archives.gentoo.org; Mon, 28 Mar 2011 01:58:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 795911C084; Mon, 28 Mar 2011 01:58:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1DA591C076 for ; Mon, 28 Mar 2011 01:58:08 +0000 (UTC) Received: from gentoo.org (174-25-229-142.rstr.qwest.net [174.25.229.142]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dberkholz) by smtp.gentoo.org (Postfix) with ESMTPSA id 0EC201B4054; Mon, 28 Mar 2011 01:58:06 +0000 (UTC) Date: Sun, 27 Mar 2011 20:58:06 -0500 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Cc: Rich Freeman Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml Message-ID: <20110328015805.GA27772@comet> References: <20110326055210.E906D20054@flycatcher.gentoo.org> <4D8EC104.4090503@gentoo.org> <4D8F3BE8.5050300@gentoo.org> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: 06ca14eb35223a0190a661ca17403c78 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02:39 Mon 28 Mar , Nirbheek Chauhan wrote: > Where did this come from? My entire argument was based around the fact > that unmaintained packages that may or may not be broken fundamentally > constitute a *bad* experience for the user. If we cannot guarantee > that bugs for a package will be fixed, we should not take up the > responsibility of the package! >=20 > Which is worse? Suddenly pulling a package from underneath the feet of > users when it inevitably breaks or telling them upfront that it's > *completely not* supported by us so they can do something about it > before it breaks? Here's the key point: "may or may not." Arbitrary criteria with no=20 relevance to whether a package works for users are not helpful. The mere existence of a maintainer-needed package doesn't mean it should=20 be removed. The existence of the same thing with numerous serious,=20 unfixed bugs or tinderbox errors means something much different. We have the ability to do these kinds of intersections today, since our=20 wonderful bug wranglers normally insert the $CAT/$PN into summaries and=20 Diego has tinderbox bugs filed. --=20 Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk2P6y0ACgkQXVaO67S1rttOPQCZAfZ8l60uqzrx7oOFoCslrgz6 BqMAoP9IY4QEnnLuraDy/8AgFevDwesY =CH6s -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK--