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 BD940138C48 for ; Mon, 6 Apr 2015 20:52:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 243B9E0866; Mon, 6 Apr 2015 20:52:34 +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 9A026E084D for ; Mon, 6 Apr 2015 20:52:33 +0000 (UTC) Received: from [192.168.1.33] (unknown [80.31.245.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 50EDB340619 for ; Mon, 6 Apr 2015 20:52:30 +0000 (UTC) Message-ID: <1428353540.2041.11.camel@gentoo.org> Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items From: Pacho Ramos To: gentoo-project@lists.gentoo.org Date: Mon, 06 Apr 2015 22:52:20 +0200 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: f9d4e1f5-4e43-4357-82bc-a97e7a71c8ea X-Archives-Hash: fa1704ee3eb0b9ddd4538007f3a0ff96 El dom, 05-04-2015 a las 20:47 -0400, Rich Freeman escribió: > On Sun, Apr 5, 2015 at 7:05 PM, Patrick Lauer wrote: > > > > How git is relevant I don't really see, you'd still have to re-test all > > involved packages, so the effort is mostly in testing and not in running > > ekeyword in a loop. > > > > If you removed stable keywords from 300 packages, they would be in a > single git commit. That means you can restore those keywords in a > single command once you've checked that the new library can be made > stable. The benefit of git is that tree-wide operations are atomic. > > Generally speaking arch teams do not test EVERY reverse dependency of > a library with the stable branch before stabilizing it. Certainly > arch teams that can't even keep up with stable requests will not do > so. > > I'm not saying I'm in favor of breaking the stable depgraph. I just > think that we need to think through the effects of removing hundreds > of keywords on users (as bircoph points out in his reply). Neither > option is terribly great. > >From my point of view, I think we should *for now* focus on the affected arches instead of trying to find a completely general policy to fit all arches. For instance, in this topic I haven't seen any comment from alpha/ia64/sparc arch teams... I think those would be the fist candidates for moving to testing only. On the other hand, Blueness has multiple times replied for trying to handle ppc* (I also joined those teams to try to help... I try but I don't have enough time for handling all, in summary, when I have time, I am able then to do amd64, x86, ppc and ppc64 at the same time, but not much more sadly :(. Maybe for ppc* would be much more feasible to try to shrink their stable tree but still keep a stable tree. Also, for HPPA and ARM I have no complaints for now, then, I am unsure if a general policy for all arches is really needed (or needs to block the move to testing of, for example, ia64 and alpha) That is the reason why I suggest at this stage to start suggesting to move alpha/ia64/sparc to testing. Once the current arch team members are then able to focus on remaining arches (as some of them won't need to spend time on alpha/ia64/sparc anymore and, then, they should then have more time for the others), we can re-evaluate then the situation of remaining arches and try to handle them in the near future if needed. But that is only my opinion of course :)