From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-project+bounces-4216-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 20B54138A1A
	for <garchives@archives.gentoo.org>; Wed, 21 Jan 2015 11:39:44 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id A406EE07F7;
	Wed, 21 Jan 2015 11:39:41 +0000 (UTC)
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 13FB5E07F4
	for <gentoo-project@lists.gentoo.org>; Wed, 21 Jan 2015 11:39:40 +0000 (UTC)
Received: by mail-pd0-f179.google.com with SMTP id v10so31112315pde.10
        for <gentoo-project@lists.gentoo.org>; Wed, 21 Jan 2015 03:39:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date:message-id:subject
         :from:to:content-type;
        bh=JPfno3f1ByNjhFmzlqKFZYWzt+1Dk9zfKfnJRCQvcio=;
        b=aKzp/0ORInDGEljQO/Nvy+mWcxhgeqNR0teR0lujOlvT+AiBvMqZEYq4spE9FGnJxD
         48KrjTjwOAylagQAgX5N7lWbKCzLdzST8B8VyLImTsZXx/q7AE3mDl8efUbRMw/2IgNm
         JWddchjo5yE7XCCALmrT9A0wITESt+gO6qNUP0BFpl6e/7Y5zMnFH/WreLXe6LSeX93a
         IVBeePiKZKWgzfp/B6hdTH13yUYocxQ+ntVqIF4sysOmIU0SrvOOUw+2DiYLNwDoP+2g
         IqoAHIMfVYd3PmFVpiR0sO64fcHNjxl1+tiFWjg94p4sznwXKTVx673LIVnSmOD2RNu5
         bvdw==
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.66.65.75 with SMTP id v11mr34558965pas.81.1421840380025;
 Wed, 21 Jan 2015 03:39:40 -0800 (PST)
Sender: freemanrich@gmail.com
Received: by 10.70.1.103 with HTTP; Wed, 21 Jan 2015 03:39:39 -0800 (PST)
In-Reply-To: <54BF2444.20106@gentoo.org>
References: <20150114034323.GA22358@comet.hsd1.mn.comcast.net>
	<54B7D189.1000108@gentoo.org>
	<20150115191001.GD22358@comet.hsd1.mn.comcast.net>
	<54BF2444.20106@gentoo.org>
Date: Wed, 21 Jan 2015 06:39:39 -0500
X-Google-Sender-Auth: l3U7SVKHP48QtBvvB_4i01WM_D8
Message-ID: <CAGfcS_kpiT89FUK6QJBb_0P3TQRxRiumSX8f15_Mk02F=Xr6MQ@mail.gmail.com>
Subject: Re: [gentoo-project] Some focus for Gentoo
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-project@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: ce95e1bf-cbab-4bb7-81af-65c025c35b4f
X-Archives-Hash: 5abff8cfe8b8aaf420ac1be16ca8993d

On Tue, Jan 20, 2015 at 11:00 PM, hasufell <hasufell@gentoo.org> wrote:
> 2. Make gentoo more decentralized and reduce the number of core-devs to
> allow conflicting ideas which is one of the main points of GLEP 39, IMO.
> But now make this idea actually possible on the technical and
> methodology level.

You've talked about the first sentence in this suggestion before, but
not really about the second.  Just what does making this possible from
a technical level look like, other than how things work today?  How
can we have both games.eclass and no games.eclass but due to a
technical/methodology change there are now less problems?  Ditto for
the two multilib implementations?

It seems to me that your #2 and #1 are really the same thing - having
fewer core devs actually eliminates conflicting ideas and increases
focus, simply by virtue of the fact that there are fewer people left
to disagree.  It is nice to speak of having your cake and eating it
too, but saying it doesn't make it happen, and I don't want a
bait-and-switch where we sell everybody on a concept but then say,
"well, there was no way this was ever going to work out like we talked
about..."

My main concern with this approach is that it seems reasonably likely
to just result in having zero devs.  When I've seen big shakeups in
other organizations with the goal of revitalizing things the result is
often that the organization just disbands.  The chances of a new
person becoming committed tends to be low, while the chance of an
existing contributor remaining committed is much higher.  Anytime you
shake things up you tend to have far more to lose than to gain as a
result.

I think that a major shakeup only makes sense if we can actually
demonstrate a new model in operation, and it actually solves our
problems.

-- 
Rich