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 A6F93138A6C for ; Tue, 7 Apr 2015 23:48:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A5DF3E08A0; Tue, 7 Apr 2015 23:48:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 267BBE089B for ; Tue, 7 Apr 2015 23:48:48 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 1D1A2340B34 for ; Tue, 7 Apr 2015 23:48:47 +0000 (UTC) Message-ID: <55246D53.8020008@gentoo.org> Date: Tue, 07 Apr 2015 19:50:43 -0400 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 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 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items 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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: d6193603-ff75-4503-b17a-88ba5b21fa1e X-Archives-Hash: 3c6cabeb8f84d5a70da985e4d34952a8 On 04/07/15 19:29, Rich Freeman wrote: > 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. > We had a couple of ideas in this direction. One is a "weak" stabilization criterion for ppc/ppc64. If the package builds for amd64, go ahead and mark ppc/ppc64 stable as well. This is bound to hit problems but we'll catch them after the fact. Another idea was to generate a list of packages we want to target as stable on ppc/ppc64 and drop stable keywords on all but those packages, then continue as we do now. Your idea Rich is actually a variation on this in that we can just unstabilize as we go along rather than generating the list and doing it all at once. That might be workable. What's holding me back right now is that when the ppc/ppc64 team met last year we said we were going to keep going as we have been. I'm hoping ppc/ppc64 can meet again soon and readdress this issue. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA