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 E028A138247 for ; Thu, 14 Nov 2013 12:57:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9FCE7E0AE3; Thu, 14 Nov 2013 12:57:13 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BD37CE0A53 for ; Thu, 14 Nov 2013 12:57:12 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id e14so2666038iej.13 for ; Thu, 14 Nov 2013 04:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=58e4Yc5Z2+TIwI84dLS9DQH+XTZIg5qy1q6jOOrR9Tg=; b=sRfvuCaoFM9+aHfIBv+0h6fA5js0UbrOSb/+LbAlIjkvrVxQZr5mc2+N9KBEdy9xT1 pEtPM+zpJLm1XZdPfZ0ghOQ78mPa+ZAxyNqpPirQ2644mgNWQep/aCR2GnZABwkR4H7G j3xxfzWKadqPyNWgdJvC03fNE7hrVrJ4ySu8ewvSvs3Gj+SBIRqYZq11OOWY+Bvqv1cx ob88yaEd2BQdo0mRIYWBIZcgnXulFUkITM4RqSDC2DWzFeA5ZqyA9Gsf0ets66np3CQn k2TI3K3eVNY4NqDVRKNwi5G7+MRzowDNwIdnayag+2zLJsCpKr6Q09PVusNLg3VCoxl7 ydAw== 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 X-Received: by 10.50.82.41 with SMTP id f9mr1280339igy.26.1384433831970; Thu, 14 Nov 2013 04:57:11 -0800 (PST) Sender: yngwin@gmail.com Received: by 10.64.227.240 with HTTP; Thu, 14 Nov 2013 04:57:11 -0800 (PST) In-Reply-To: References: <20131113151012.04145837@gentoo.org> <5283948F.1000409@gentoo.org> <52841023.9010208@gentoo.org> <20131114061328.09136f6f@gentoo.org> Date: Thu, 14 Nov 2013 20:57:11 +0800 X-Google-Sender-Auth: i0xJ15Bb6KcN7jCZzi4eXOGk-PY Message-ID: Subject: Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask From: Ben de Groot To: gentoo-dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: fd29eb2d-649c-4a34-87c6-c1de9125b111 X-Archives-Hash: 0c3b6a5cd01937d2b19c08ca34c4f8d6 On 14 November 2013 20:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote: >> On 14 November 2013 13:13, Micha=C5=82 G=C3=B3rny wr= ote: >>> >>> And how is it possible to discuss anything properly in Gentoo? >> >> That's because we have no proper leadership. We're an anarchistic >> collection of people working at cross-purposes at the best of times. >> There is no direction, and very little accountability. > > This seems to be an arrangement that everybody likes except when > somebody else does something differently than they would prefer... Seems, maybe. I for one do not like it at all, and I do bring that up from time to time. Others agree with me to various degrees. The problem is that it's so damn hard to change anything structurally in Gentoo. > We have a Council, and any issue can always be escalated there. As it is always happy to point out, Council doesn't see itself as leadership, just as a supreme court of appeal, when everything else seems to have failed. It likes to get involved as little as possible. > We > also have Comrel, which is a better starting point for cases > concerning individuals vs policies. This also displays little real leadership. It concerns itself with conflict resolution, with various degrees of success. (I still have a bad taste in my mouth from my past dealings with that institution.) > However, so far I haven't really seen any real indications of what the > concern is here. 32-bit software on amd64 has always been a kludge, > and if anything the latest multilib eclass seems to be less of a > kludge. I vehemently disagree. The emul-* packages may be a hack, but they work and cover the use cases we need. The new multilib eclass approach is much more intrusive in many packages, introduces new levels of complexity in ebuilds, with resulting new bugs and new behaviour that confuses users, and adding maintenance costs. It does this for very little gain. The great majority of our users doesn't need this functionality. The costs are higher than the benefits, in my opinion. Where are the use cases for this high-cost solution that is being pushed upon us? > Apparently some argue that there is a better solution being > worked on, and that's great to hear. What exactly is the problem? If > the eclass were breaking things that weren't already broken and having > a real impact on ordinary systems I'd consider that a concern. If you'd care to look at the history of bugs due to multilib eclass introduction in various packages, that's what you'd find. > The problem with having top-down leadership in a volunteer-based > organization is that it tends to drive away anybody who doesn't agree > with the leader. If a supreme leader said "mgorny has the right > solution to multilib - everybody is going to work to implement it" > that would probably cause more harm than good. Everybody wants a > supreme leader until the leader backs something they oppose. But what's the alternative? Having a few dozen self-appointed leaders doing whatever they want, and often taking things in opposing directions. It's not top-down leadership, but rule of the strongest. --=20 Cheers, Ben | yngwin Gentoo developer