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 33550138247 for ; Thu, 16 Jan 2014 00:00:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2EC76E0B36; Thu, 16 Jan 2014 00:00:29 +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 2D6F2E0B25 for ; Thu, 16 Jan 2014 00:00:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2B81B33F4CD for ; Thu, 16 Jan 2014 00:00:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5.5 tests=[AWL=-1.139, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.123, 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 8DuS04rktnI0 for ; Thu, 16 Jan 2014 00:00:19 +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 2F88233DA93 for ; Thu, 16 Jan 2014 00:00:17 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W3aNZ-0003Aq-76 for gentoo-dev@gentoo.org; Thu, 16 Jan 2014 01:00:13 +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 ; Thu, 16 Jan 2014 01:00:13 +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 ; Thu, 16 Jan 2014 01:00:13 +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: Wed, 15 Jan 2014 23:59:49 +0000 (UTC) Message-ID: References: <20140114213719.GA2684@laptop.home> <52D5B2CA.5030407@gentoo.org> <20140114223312.GA3337@laptop.home> <52D5BDAD.4030808@gentoo.org> <20140114231113.GA3393@laptop.home> <20140115012809.744114d1@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: 9f6b8834-4a20-4094-ab30-fd685ff0494e X-Archives-Hash: a24706deca7f660845d423c5c3005108 Tom Wijsman posted on Wed, 15 Jan 2014 01:28:09 +0100 as excerpted: >> Another option (and I don't mean to step on any toes or call anyone out >> here, these are just examples) may be to just deprecate stabilizing >> certain software. Packages such as the stuff in app-vim/ or app-emacs/ >> or some games or some scientific software. For the editor plugins, most >> people do not get them from the package manager I feel and a Vim plugin >> requires almost as much arch testing work as a new version of grep, for >> example... > > Sounds like a good idea, but how do we translate that to the user; > always mark them stable, or always mark them unstable? Do we want users > to explicitly accept keywords on these packages? As a ~arch/masked/overlay/live user here (who additionally doesn't even use gentoo kernel ebuilds, preferring direct upstream git and my own scripts), I haven't even checked if it actually happened (looks like gentoo-sources-3.10.x is still stable on x86/amd64, so maybe not), but... There was previous discussion of destable-keywording the kernel. How has that gone? I've always thought that having a stable policy exception that the user actually has to deal with for certain packages, particularly core packages such as the kernel, would be confusing at best. Still, given the upstream development pattern, I couldn't think of a reasonable alternative for the kernel, and agreed with the thread that it may have to be, for packages like that and perhaps google-chrome and firefox, where upstream releases are too close to 30-day and updates are very likely to be security-critical on packages that are net-exposed. So it seemed it had to be, for them, and if that has gone well, perhaps expanding that no-stable policy precedent to things like editor plugins could work better than I might have imagined. The other question then becomes, since ~arch packages are normally masked to stable, how are users exposed to them? What about a file somewhere in profiles that lists all these no-stable packages, such that the PM can (perhaps optionally, I could imagine a setting in make.conf...) list all ~arch versions of those packages on an otherwise stable system as if they were stable, tho possibly marked in some way to indicate that this package isn't a stable-keyword candidate? -- 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