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 718EE138247 for ; Thu, 16 Jan 2014 05:49:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BD215E0ABF; Thu, 16 Jan 2014 05:49:39 +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 CB522E0AA1 for ; Thu, 16 Jan 2014 05:49:38 +0000 (UTC) Received: from [192.168.11.61] (cpe-72-177-217-176.satx.res.rr.com [72.177.217.176]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: steev) by smtp.gentoo.org (Postfix) with ESMTPSA id D9EF733F795 for ; Thu, 16 Jan 2014 05:49:37 +0000 (UTC) Message-ID: <1389851236.20022.12.camel@oswin.hackershack.net> Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy From: Steev Klimaszewski To: gentoo-dev@lists.gentoo.org Date: Wed, 15 Jan 2014 23:47:16 -0600 In-Reply-To: References: <20140114213719.GA2684@laptop.home> <52D6D489.9030302@gentoo.org> <20140115190744.GA2645@laptop.home> <1389833907.20022.7.camel@oswin.hackershack.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 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-Transfer-Encoding: 7bit X-Archives-Salt: 7b430cfb-03aa-4bdb-8abf-6597e997bb76 X-Archives-Hash: 2fff206661753e8d871fb070c201de82 On Thu, 2014-01-16 at 02:32 +0000, Robin H. Johnson wrote: > > In my testing, one known issue was that git on uclibc did (and still > > doesn't) work properly starting with git 1.8 - so I noted in the bug > > that this was the case, and to NOT stable it for arm. Unfortunately, > > someone else on the ARM team disregarded the note and stabled the new > > git, then the git maintainers dropped the old versions. Now on arm > > uclibc, git is entirely broken and unusable. > Ugh, this does suck. > It does, though it's specific to arm uclibc, as it works fine on amd64/x86 uclibc. And unfortunately, it seems like this type of thing is what people are proposing we move towards. Instead of working but old, not having access to the software at all. I know it's not the norm, nor is it typical, but the chance of this happening does exist, and I can't see how anyone would say, well, that's just the chance that people should take, unless they've never been bitten by a bug like this. > Wasn't there a proposal years ago to include the libc in the keyword? > There may have been, I'm not sure that's really the right step either though.