From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0151A139694 for ; Mon, 10 Apr 2017 14:57:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9397A21C08A; Mon, 10 Apr 2017 14:57:47 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4AF59E0C3F for ; Mon, 10 Apr 2017 14:57:47 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id CF0ED340988 for ; Mon, 10 Apr 2017 14:57:45 +0000 (UTC) Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions To: gentoo-dev@lists.gentoo.org References: <20170409152002.550f3b4d.dolsen@gentoo.org> <0cf71d18-64f3-821b-e481-9889f5eb1872@gentoo.org> From: Michael Orlitzky Message-ID: <92c75ab2-659b-6c10-d7d3-0da08c1ccc9f@gentoo.org> Date: Mon, 10 Apr 2017 10:57:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 1821fb24-402e-41c2-b6b4-293ad497f196 X-Archives-Hash: 93789a2a8de84373b6b70b53909d381f On 04/09/2017 08:58 PM, William L. Thomson Jr. wrote: > > I am NOT talking about stabilization at all. Simple reducing the burden > of adding targets to ebuild, and users having to fiddle with targets as > they come and go. > You are: when you find out that a stable package doesn't work with the next version of python, you have to figure out who the maintainer of that package is, and file a bug. Then, whenever he decides to fix it, you have to wait 30 days and file a stabilization request. Wait another few months for that to go through, and repeat however many times to fix every broken package. You can either spend months/years doing that for all affected packages and every new version of python, or just commit the new version of python and let things break. Neither option is an improvement over the way things work now. We have it your way for PHP packages, and I wish it was like Python/Ruby instead.