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 9B4F313827E for ; Fri, 24 Jan 2014 03:55:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CFA0BE0A98; Fri, 24 Jan 2014 03:55:13 +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 C7839E0A8A for ; Fri, 24 Jan 2014 03:55:12 +0000 (UTC) Received: from [192.168.11.20] (cpe-72-177-217-176.satx.res.rr.com [72.177.217.176]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steev) by smtp.gentoo.org (Postfix) with ESMTPSA id B639533ECD6 for ; Fri, 24 Jan 2014 03:55:11 +0000 (UTC) Message-ID: <1390535567.3909.12.camel@oswin.hackershack.net> Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy From: Steev Klimaszewski To: gentoo-dev@lists.gentoo.org Date: Thu, 23 Jan 2014 21:52:47 -0600 In-Reply-To: <20140124040444.058bd7a7@TOMWIJ-GENTOO> References: <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> <1390510534.14914.22.camel@oswin.hackershack.net> <20140123233806.4709abd5@TOMWIJ-GENTOO> <20140123224228.1780.qmail@stuge.se> <20140124005040.350249c9@TOMWIJ-GENTOO> <1390521859.3909.3.camel@oswin.hackershack.net> <20140124040444.058bd7a7@TOMWIJ-GENTOO> 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: 679c9889-7aed-46df-b748-43be3396a3a5 X-Archives-Hash: 7cf30de15dc125c1938d19e859e06a5d On Fri, 2014-01-24 at 04:04 +0100, Tom Wijsman wrote: > On Thu, 23 Jan 2014 18:04:19 -0600 > Steev Klimaszewski wrote: > > > Your "suggestion" was expanding the "arm" keyword to "armv4-linux", > > "armv5-linux", "armv6-linux", "armv6-hardfloat-linux", > > "armv7-softfp-linux", "armv7-hardfloat-linux", > > "armv7-hardfloat-uclibc-linux" - that is nowhere near a good solution. > > We've ran over the reasons and they have appeared as fit for this idea. > > It can be prejudged as "nowhere near a good solution"; but for it to > actually be that, it would need solid reasoning that people agree on. > > Reasoning is also needed to be able to figure out which conditions are > fit for another solution; that way, the other solutions could be shaped > with the help of that feedback to make the other solutions better. > > > The /dev/null comment was about wanting others to do the work and not > > contributing anything more than (imo) a stupid idea > > The idea moves work from one place to another, which yields the same > amount of work; your work statement seems like another topic, which you > are making basic assumptions on. Solutions to the stated actual problem > are neglected, as more time for research and consideration is needed. > > To get on the topic of your work statement; consider that one can find > 7 people whom each have one arm configuration much faster than one can > find 1 person that has all of them. > The idea moves the work around, it doesn't lessen the workload at all. You can easily find 7 people who have an armv7, and even v6, since the rpi is quite popular. Getting them into the arch team and willing to run stable and actually test programs is a whole other story, which lead to you saying: "People that have certain architectures can just add themselves, no extra work again." And that's a show stopper, just randomly adding yourself to an arch team and claiming you've tested it is a nonstarter. Considering if there IS an issue, we then have to track you down and figure out why/what is different in the configuration that it's failing for others. You being on the QA team even offering that up as an option makes it questionable as to why you're on the QA team. That should never even be thought of as an option. What you've thrown out as a possible solution is akin to taking a pile of peas on the plate and moving them around the plate so that the pile doesn't look so big. It doesn't change the amount of work, but you do need to look in more places for the work. Finding people with the hardware is the main issue, and I think I mentioned before, some people are simply unwilling to invest in "slow" hardware, so we have to rely on the people who DO have it. And if that means things take longer to stable, well, why is that an issue? Stable is supposed to be that - stable. > > if you aren't willing to put in the work, don't expect others to. > > If you are unwilling to work towards solutions, don't expect others to. > > > And yes, I see what you mean now re: my reply seeming off - it would > > seem when I hit group reply, for some reason, Evolution is putting > > Peter Stuge into the CC, and not Tom Wijsman (despite hitting group > > reply from your email. Maybe there should have been more testing of > > Gnome 3.8 before it was stabled on x86... > > http://www.unicom.com/pw/reply-to-harmful.html > http://woozle.org/~neale/papers/reply-to-still-harmful.html > I don't care of "reply to" is considered harmful, I care that something that worked with the previous stable is suddenly not working with the new stable. It obviously shows that it wasn't tested properly, and yet was marked stable. So, as QA, shouldn't you be doing something about that, rather than pointing to some URLs on the web, telling me I'm in the wrong for using the option that is supposed to handle that properly in my stable software?