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 6DF7E1380DC for ; Thu, 6 Feb 2014 01:50:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6101BE0BFD; Thu, 6 Feb 2014 01:50:09 +0000 (UTC) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7F096E0BE4 for ; Thu, 6 Feb 2014 01:50:08 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so2077751qcy.25 for ; Wed, 05 Feb 2014 17:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=hrcR5OwrNXVvn2qmLjZLiqcgg+AZqKKhJzyJJLBiW6Y=; b=SK6QXKzPlfgdOpSjD+p+Fy5HfIwAuyjqU8j72BPW3T7aqsZyUVoaU+ogfjMu+gLKZz Tg4NmnHJpQLt/DPnGlh1UASUyG1zRJj06T3MER/2WNczvi0cztyt3EzE/Fzib+zhTf8U cVW5B+6dQ2so2FEZKcx1Hrw4bPsc+/HFmoZOuF3hRb786b7erlmnO55DwTZsCiLzJzEM zF2JsVAUi4qt7qaYgjTP6s3o6Xm3b+iAX8sp4fsO2Ad5FCRvtSt+HXYNHDXxWvot+3hZ BehCIvQXfwsXo1cWNlSfq3dShZ7B+0438LPXD0adcfx8Lg6giMP2XzMQDepVLhsjKF// Y9nQ== 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 X-Received: by 10.140.39.212 with SMTP id v78mr7588001qgv.77.1391651407796; Wed, 05 Feb 2014 17:50:07 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.140.49.233 with HTTP; Wed, 5 Feb 2014 17:50:07 -0800 (PST) In-Reply-To: <52F2DEB9.2000901@gentoo.org> References: <52E7DBC1.5020102@gentoo.org> <20140128182304.7d458a17@marga.jer-c2.orkz.net> <20140203062524.GA7467@rathaus.eclipse.co.uk> <20140203104341.2add2760@TOMWIJ-GENTOO> <20140204210319.GA1935@rathaus.eclipse.co.uk> <20140205010833.1bcf8dca@TOMWIJ-GENTOO> <1391559808.3520.2.camel@oswin.hackershack.net> <20140205020742.048cef9f@TOMWIJ-GENTOO> <1391564122.3520.4.camel@oswin.hackershack.net> <20140205024806.7d08cb63@TOMWIJ-GENTOO> <1391570147.3520.7.camel@oswin.hackershack.net> <20140205055544.6c3affea@TOMWIJ-GENTOO> <1391616442.3160.6.camel@oswin.hackershack.net> <20140205224815.70832b2d@TOMWIJ-GENTOO> <52F2B594.5050500@gentoo.org> <20140206014838.054be1ab@TOMWIJ-GENTOO> <52F2DEB9.2000901@gentoo.org> Date: Wed, 5 Feb 2014 20:50:07 -0500 X-Google-Sender-Auth: MqxOpkwMXYLtQkplOdXDMzyv4ro Message-ID: Subject: Re: [gentoo-dev] Re: Re: dropping redundant stable keywords From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 4d949c98-6746-4a17-8f42-0b29d959a544 X-Archives-Hash: 800795636ad8e5e1119d927ddae57250 On Wed, Feb 5, 2014 at 8:00 PM, Rick "Zero_Chaos" Farina wrote: > On 02/05/2014 07:48 PM, Tom Wijsman wrote: >> >> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies >> > That policy doesn't permit removal of keywords/ebuilds without following > gentoo standard policy, standard policy is available here: > https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html So, I realize I'm repeating myself, but the purpose of the mailing list isn't to keep reposting the same arguments back and forth until everybody agrees. Post your argument once, and once it gets dull by all means appeal to QA/council/whatever but the bickering really doesn't add any value. For my part I promise not to let it be a whoever-makes-the-most-noise-sets-the-policy thing. I appreciate the concerns, arguments, and alternatives that were raised - they're helpful the first time they come up. To add something new, can the QA team please figure out what policy they actually intended to make and just communicate it? Having QA team members and everybody else openly speculating about what the policy is supposed to be on the list also adds no value. If the new policy does not in fact override the standard policy then I'm not really sure what it is trying to say since it only speaks to things that were already spoken to before, just in a different way. Thanks for updating the policy webpage with the note that the policy shouldn't be followed until clarified. One thing I haven't really seen in this thread is a better understanding of the demand for old version removal. I can understand the hypothetical issues having old versions creates, but is just WONTFIXing a bunch of old bugs a large burden in practice? Before we create new problems by fixing old problems, I'd like to get a sense for whether the old problems are actually problems. I imagine this becomes a matter of degree - keeping a package around for an extra 6-12 months probably isn't a big deal, but when half the tree contains 6-year-old versions it is a problem. Rich