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 2724E138A1F for ; Sun, 26 Jan 2014 22:57:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DCEABE0D2B; Sun, 26 Jan 2014 22:57:00 +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 D2A2FE0D11 for ; Sun, 26 Jan 2014 22:56:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E325733F6CF for ; Sun, 26 Jan 2014 22:56:58 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5.5 tests=[AWL=-0.919, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.551, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4szcJLAS2t7W for ; Sun, 26 Jan 2014 22:56:52 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 803C233F65A for ; Sun, 26 Jan 2014 22:56:50 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W7YdD-0004To-Qr for gentoo-dev@gentoo.org; Sun, 26 Jan 2014 23:56:47 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Jan 2014 23:56:47 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Jan 2014 23:56:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: revisiting our stabilization policy Date: Sun, 26 Jan 2014 22:56:24 +0000 (UTC) Message-ID: References: <52D5E60A.80600@gentoo.org> <20140115020934.GA3886@laptop.home> <52D5F0BF.3060305@gentoo.org> <20140115024604.GA3952@laptop.home> <20140115232804.1c26beda@kruskal.home.chead.ca> <20140116234442.27c361d1@TOMWIJ-GENTOO> <20140119143157.72fc0e91@kruskal.home.chead.ca> <20140120014713.2cafc257@TOMWIJ-GENTOO> <20140123181242.GA17827@rathaus.eclipse.co.uk> <20140123201333.71e52bfc@TOMWIJ-GENTOO> <20140124104605.GA19957@rathaus.eclipse.co.uk> <20140124192641.5677cc51@TOMWIJ-GENTOO> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 6daf184 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: ebf93bbb-0913-4e50-8cd8-6ed570697a90 X-Archives-Hash: 60fe24ef55af55a9ee206344879fa942 Rich Freeman posted on Sat, 25 Jan 2014 19:59:19 -0500 as excerpted: > On Fri, Jan 24, 2014 at 11:02 PM, Duncan <1i5t5.duncan@cox.net> wrote: >> I've often wondered just how much faster gentoo could move, and how >> much better we could keep up with upstream, if we weren't so focused on >> 30+day outdated stab?le bumping all the time. All that effort... from >> my viewpoint going to waste on something that gentoo really isn't going >> to be that great at anyway, certainly in comparison to other distros >> which REALLY provide a stab?le service, up to a /decade/ outdated, >> supporting often trailing edge software, in an effort to slow down >> progress for people that don't want to move so fast. > > I get what you're saying, and I'm going to use a bit of hyperbole so > don't take this too seriously, but couldn't you just as easily argue > that Gentoo could go much faster if we actually took advantage of the > fact that we DO have a stable tree, and stop being so careful about not > breaking the testing tree? If that was hyperbole it was a bit too subtle for me. =:^) Actually, I'd support something like this too. After all, I've already stated that on some packages I run from the project overlay and/or the live-vcs version. In a way, that's arguably what testing should /be/, tho it'd certainly be a departure from how gentoo handles things now. Basically in my ideal gentoo, what's now stable would disappear entirely, and what's now testing would be the new stable, with what's now hard- masked and/or only available in the overlays being testing. But obviously I recognize that's totally broken for a lot of people who do depend on gentoo stable, and as such, I don't really consider it an entirely practical option... But it'd be nice for me anyway! =:^) So it's far from hyperbole in my world. In my world it's the ideal. =:^) > Honestly, I think both trees represent a pretty decent balance. It is > pretty safe to run ~arch for the packages you really are interested in, > and run stable for the stuff that you don't care so much about, thus > limiting your exposure to problems while getting cutting-edge where you > care for it. Except, well, ~arch is if anything safe enough to be stable, and unfortunately, isn't always that cutting edge after all. One has to run overlays and hard-unmask live-vcs versions to actually get cutting edge testing, which is in my view... unfortunate. > Most of the concern in this thread has been about some minor archs that > struggle to keep up. It seems like the simplest solution in these cases > is to just have them focus on @system packages for the stable tree, and > let users deal with more breakage outside of that set (where it isn't > super-disruptive). If you're running a minor arch chances are that > you're happy to have any support at all, since you sure aren't going to > be running Ubuntu... Agreed. Tho AFAIK both Ubuntu and Fedora have an arm variants... But also AFAIK, due to them being binary distros these variants are closer to the sub-arm- keyword-variants I believe someone else proposed in this thread (??) for gentoo/arm as well, consequently leaving other sub-arch-variants that gentoo/arm supports out in the cold. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman