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 4E0481381F3 for ; Thu, 29 Aug 2013 17:49:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 52DC1E0BC9; Thu, 29 Aug 2013 17:49:35 +0000 (UTC) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AA4EDE0BBF for ; Thu, 29 Aug 2013 17:49:34 +0000 (UTC) Received: by mail-vb0-f48.google.com with SMTP id w16so549750vbf.21 for ; Thu, 29 Aug 2013 10:49:33 -0700 (PDT) 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=XCRDSzaO48YZjIZfGdxJucBtJrpJz0LJCju4t5bFQF4=; b=NgfHQoTD23yR/PUvNiynRVyDrkA3eBGojsPwH9e8eGvE2ToB+HJeooks9POW13jFJO 281N0J37Hs5cdkF4i6QlVFldnrR/Qo/qn38garYdD/IwZFN+jw/Y2xmJGshHHW9LajfN 6lGtbftasYQhknNZdLUo2CxTudTjYzyU4zA109BAwutlcAXmN9/vrzZj+Y2sY8hn1k// BDNzbRNpC9icDrmUpaBGyWQD3f3FNQu3L5uFPO96NJxnOBUDpb4GlfubqycxxxrdZ6P5 breABASs28vhmHJfnJ60EB0zz3j3Q54JB3IJpPj6lEqw7x2OrFKvjUirsWLqAZBIP8RV uSZw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.220.10.194 with SMTP id q2mr3923008vcq.2.1377798573787; Thu, 29 Aug 2013 10:49:33 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.187.68 with HTTP; Thu, 29 Aug 2013 10:49:33 -0700 (PDT) In-Reply-To: <26510047.28Cxrb1Hqk@kailua> References: <21020.30575.805569.383992@a1i15.kph.uni-mainz.de> <20130829152248.GA3432@shimane.bonyari.local> <26510047.28Cxrb1Hqk@kailua> Date: Thu, 29 Aug 2013 13:49:33 -0400 X-Google-Sender-Auth: XwP6DEse5z6z4Ue28G20wczgpfs Message-ID: Subject: Re: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10 From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: e70ef100-3b32-4a2f-9be8-a9e23d4f089d X-Archives-Hash: 2363f35cf721f95ce41f662d640d1f50 On Thu, Aug 29, 2013 at 12:06 PM, Andreas K. Huettel wrote: > > Sounds reasonable, but then you get just abused by Mr_Bones for breaking the > deptree. The solution to that is to either ignore the abuse, or drop the stable keywords on all reverse deps as well. Dropping individual package keywords shouldn't happen much, since the fact that it is happening is a good sign that the whole arch should be dropped. If an arch team can't keep up with a single package they should remove the stable keywords themselves so that this can be done in an orderly manner. > > Anyway, how about when the arch has not even responded to the (much older) > KEYWORDREQ for that package? :| I see this as less of an issue - maybe the maintainer just drops themselves from the bug to be added-back by the arch team only if needed. If the maintainer logged it they can also cancel it if they don't care to see it open. The only people affected by a pending KEYWORDREQ are the users of that arch. They're at the mercy of the arch team no matter what - if the package matters that much to them they should step up to arch test. Please don't interpret anything I'm saying as a lack of care for small archs. I'd just rather see them define their goals in terms of things they can actually accomplish and then accomplish those. Having a bunch of ancient stable versions that are just weighing down the rest of the distro isn't really a good measure of success. That was why I suggested the possible @system-only compromise - it might be a way to capture some of the value of having stable keywords while greatly reducing the amount of work involved. Better to do less but do it properly. That said, I'd also encourage maintainers to leave around old versions as long as they aren't actually maintenance burdens. If they become such, well, time to prune if the STABLEREQ is stale. Rich