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 46297138A6C for ; Tue, 7 Apr 2015 23:29:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D5D6BE0894; Tue, 7 Apr 2015 23:29:32 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4F1C7E0887 for ; Tue, 7 Apr 2015 23:29:32 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so68630813ied.1 for ; Tue, 07 Apr 2015 16:29:31 -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=J3kqk/lnKRhOPppiOqaikxGEP78uuGNXGgcT4noYJpA=; b=kvU9e7nSTehyC6JFuUFjxTM37eVWo7V5+GERGuKvzD/EngsYHrPJQVTj8CI+P2/ec6 Bud8pnqfEVyY2KjVXEl2qjpaKbL+BI/Qr+VCRoSZLCqH6ESJY9YtvzNgvzzJRTozVdsy a4TLHkz+NGtnoiPJn4ED5qbjONilK+cvVziUBIsOgG08nNpqQEifouk8cOoeI6A4rRkL 2MB1ZnzYogCNiPzYeERHeHKGoROvUXX6Mq8Imvr7ZeMKFvmir93MjqjylgxM1CtOUZby QdQGmERiAI+eE8FJ+sV2k9IX1FKHK+2u3wKdqwPrcR1bNmYUGhgRu9rfMKPjfnf8h9wa rHYQ== 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.107.9.141 with SMTP id 13mr33906403ioj.71.1428449371698; Tue, 07 Apr 2015 16:29:31 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.107.48.198 with HTTP; Tue, 7 Apr 2015 16:29:31 -0700 (PDT) In-Reply-To: <55246753.5060902@gentoo.org> References: <20150402141428.GA31638@oregano.home.lan> <201504032214.01310.dilfridge@gentoo.org> <20150404220205.GA415@linux1> <1428237147.22472.1.camel@gentoo.org> <20150405195044.GA2917@linux1> <20150406002706.4aff7e4dda27a25a5c106b50@gentoo.org> <5521BF9C.5060809@gentoo.org> <1428353540.2041.11.camel@gentoo.org> <55246753.5060902@gentoo.org> Date: Tue, 7 Apr 2015 19:29:31 -0400 X-Google-Sender-Auth: auYwDXuosCR4iDxHvHARjwr6DgM Message-ID: Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: c0878aea-eac7-4ab9-9c63-e8d8fc8de33a X-Archives-Hash: 762b0a2717addc9cada148aba411d4d7 On Tue, Apr 7, 2015 at 7:25 PM, Anthony G. Basile wrote: > On 04/07/15 11:38, Michael Palimaka wrote: >> >> On 07/04/15 08:22, Matt Turner wrote: >>> >>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos wrote: >>>> >>>> For instance, in this topic I haven't seen any comment from >>>> alpha/ia64/sparc arch teams... >>> >>> I haven't commented because I don't honestly believe people care. >>> >>> I'm really disappointed that the discussion is entirely about creating >>> keyword-dropping policies and no one is asking whether there are >>> things we can do to make keyword/stable requests a more streamlined >>> process. But, that kind of thing seems to be par for the course on >>> this list. >> >> We've heard very little from arch teams at all, let alone proposals for >> improving the stabilisation process. That's the main reason this sort of >> topic keeps coming up. > > I don't want my silence to be misinterpreted regarding ppc and ppc64. For > those arches, I'm willing to trim back on stabilization, but I really don't > want to drop to ~ as we did for mips. In fact, I'm thinking of turning mips > itself back into a stable arches with just the @system packages being > candidates for stabilization. The reason I like this approach is when I > build stage3's I can control what I know will build (stable packages) vs the > latest packages added to the tree (~arch). Nothing is more painful than > have to manually intervene in a bunch of catalyst builds. Being able to > control what will be built via stable keywords saves time and effort. > Would you be willing to monitor stablereqs and for ones that you can't keep up with, go ahead and remove stable keywords proactively on your own? The main concern is that this is a lot of hassle for maintainers. If the arch team can keep up with maintainers either by stabilizing packages or unstabilizing them, I think that will satisfy everybody. Alternatively, we can just change the status of the arch in repoman. Then you can keep your stable keywords if you wish, but package maintainers can also break your stable depgraph. -- Rich