From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PmeOn-0005MT-Tn for garchives@archives.gentoo.org; Tue, 08 Feb 2011 03:37:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C6D69E0B30; Tue, 8 Feb 2011 03:37:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id EF7CDE0B2A for ; Tue, 8 Feb 2011 03:37:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 7885C1B413B for ; Tue, 8 Feb 2011 03:37:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 required=5.5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfxF87ZuqfIW for ; Tue, 8 Feb 2011 03:37:02 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id 7128B1B4039 for ; Tue, 8 Feb 2011 03:37:00 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PmeNs-0003Rr-MH for gentoo-dev@gentoo.org; Tue, 08 Feb 2011 04:36:56 +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 ; Tue, 08 Feb 2011 04:36:56 +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 ; Tue, 08 Feb 2011 04:36:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: avoiding urgent stabilizations Date: Tue, 8 Feb 2011 03:36:36 +0000 (UTC) Message-ID: References: <4D501BA4.6040802@gentoo.org> <4D502114.2060006@gentoo.org> <1297100159.15824.21.camel@localhost.localdomain> <201102071845.15942.dilfridge@gentoo.org> <20110207205059.GA10939@bookie> <4D505DEC.2080608@gentoo.org> 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 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies; GIT 25ed40d branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: e59e9c15e8a8d972f7dd35d1b075c2be Pawe=C5=82 Hajdan, Jr. posted on Mon, 07 Feb 2011 22:02:36 +0100 as excer= pted: > On 2/7/11 9:50 PM, Markos Chandras wrote: >> My suggestion, as I said to fosdem, is to freeze, or take a >> snapshot if you like, of the current tree, stabilize what you need to >> stabilize, test the whole tree ( at least compile wise ) for a couple >> of weeks and then replace the existing stable tree. Of course this >> requires automated script testing, hardware facilities etc etc that we >> don't have so claiming that stable tree is "stable" is quite wrong. >=20 > This more thorough testing sounds really interesting. But do we really > lack hardware resources? Disclaimer: I run ~arch (plus choice unmasks/overlays where ~arch is=20 already unsuitably outdated for my tastes), so this doesn't affect me=20 regardless. That said... The above suggestion sounds to me like increasing the bureaucracy and=20 hassle of stabilizing packages even more. We already have trouble with=20 outdated stable, especially on some archs. Do we /really/ want the=20 reputation of competing with Debian-stal^hble for staleness? Every few years someone comes up with the idea of creating a /truly/=20 stable, aka "enterprise" keyword/branch/whatever. Every few years, it=20 doesn't happen, for both resource and (arguably) philosophical reasons. IMO, that's simply not suitable for or compatible with "mainline" Gentoo=20 and its rolling updates, etc. Yes, it's possible to do it. A lot of=20 things are "possible", but that doesn't mean they're practical. "It's=20 Gentoo, Jim, but not as we know it!" As such, if someone/somegroup does decide to go that route, IMO the best=20 approach would be a separate Gentoo-based distribution, where freezing an= d=20 testing an entire tree for self-consistency and compatibility makes a bit= =20 more sense. There are already a number of Gentoo-based distributions out= =20 there. Certainly, talking to them about the problems they face and the=20 solutions they use, if not using one of them directly, could be a good=20 place to start. Similarly, just as Gentoo has never made any bones about not being a hand= - holding distribution, in many cases, "you break, you get to keep the=20 pieces" (tho users and devs do try to help and devs do try to prevent,=20 where it's "sane" to do so), and it's not uncommon to see people saying=20 that if the install speed of a binary distribution or the centrally=20 controlled decisions of an Ubuntu are what one is after, Gentoo isn't=20 really where you should be looking, I'd say the same applies, to some=20 degree, here. Yes, we can try to keep stable breakage to a minimum, but=20 on a rolling release system, it's /going/ to happen, and I'd argue that=20 the sort of wholesale freeze-and-test discussed above really /would/ be=20 "Gentoo, Jim, but not as we know it", were it to be implemented as such i= n=20 Gentoo. That's not what Gentoo is /about/. The rolling updates are so=20 much a part of what makes Gentoo /Gentoo/, that take them out, as=20 wholesale freeze and test would effectively do, and you no longer have=20 Gentoo, at least as historically known. That being the case, why confuse people about both the new product and=20 Gentoo as it currently is, by calling the new product Gentoo at all? If=20 it's effectively a Gentoo-based distribution that isn't itself Gentoo, at= =20 least as historically considered, call it a Gentoo based distribution. =20 Don't call it Gentoo, thus avoiding the confusion on both sides. JMHO, but I've been around long enough to have seen this discussion cycle= =20 at least twice before... Unfortunately, the result is often the loss of = a=20 few devs. OTOH, if their goal is to make Gentoo a wholesale freeze and=20 test distribution, perhaps it's better for both them and Gentoo that such= =20 efforts get applied somewhere more appropriate to that goal. OTOH, if some big name comes up with suitable big resources to devote to=20 such a project and they like the Gentoo name, perhaps a Gentoo-Enterprise= =20 might indeed be practical. But the resource scaling that's going to=20 require is enough beyond what we're doing today that I'd think seeing=20 someone step up with an offer of such resources before we start seriously= =20 discussing it, is a worthwhile prerequisite. And even then, making Gento= o=20 that dependent on that sort of major sponsorship, regardless of who or=20 what form, would change the historically "community distribution" aspect=20 substantially enough that arguably, that would be "Gentoo, Jim, but not a= s=20 we know it", as well. But at that point I guess it'd be a question for=20 the Gentoo foundation to decide, since they own the name and decide=20 permissions for it in that regard. --=20 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