From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 146F0138010 for ; Sun, 24 Mar 2013 13:52:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9954CE0803; Sun, 24 Mar 2013 13:52:34 +0000 (UTC) Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by pigeon.gentoo.org (Postfix) with ESMTP id 597FAE07D1 for ; Sun, 24 Mar 2013 13:52:33 +0000 (UTC) Received: (qmail 15912 invoked by uid 501); 24 Mar 2013 13:52:32 -0000 Message-ID: <20130324135232.15911.qmail@stuge.se> Date: Sun, 24 Mar 2013 14:52:32 +0100 From: Peter Stuge To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Last rites: app-text/cuneiform Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <514CE32C.7090509@gentoo.org> <20130324132456.13752.qmail@stuge.se> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Archives-Salt: 53410db4-40da-45f4-97e9-0f081ec6ee74 X-Archives-Hash: ca25564ee9417d064878796e0daa8c4c Rich Freeman wrote: > something is bound to break for good sooner or later if things don't change. Certainly. But consider the chain of events: * user is happily using outdated, but working, software without knowing how behind the times upstream really is, because it works * gentoo masks and removes package That looks bad. Masking is a quite invasive UX. It makes a package unavailable by default *before* the package actually stops working. Users who want to fix the problem need to get involved upstream, there is no disagreement about that, but users who have already gotten a package masked by the powers that be are vastly less motivated to do so, because the package has already been masked. Masking communicates that a decision to treeclean has been made. Masking is not at all communicating an opportunity to address the perceived problems. That should be done in a different way. A per-ebuild bug metric would be cool. A kind of health indicator for individual ebuilds, alerting users when some of our installed ebuilds go yellow, so that we have perhaps on the order of six months before the package goes red, at which point it would be fine to mask at will. Does that make sense? (Obviously how many months yellow is depends on what else happens in the tree. It's a ballpark figure.) //Peter