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 CC9161381F3 for ; Mon, 1 Jul 2013 11:36:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 899A0E0A07; Mon, 1 Jul 2013 11:36:07 +0000 (UTC) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D730DE0A01 for ; Mon, 1 Jul 2013 11:36:06 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id jw11so3599193veb.4 for ; Mon, 01 Jul 2013 04:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=dXvJtucBCLNyP3dcKY80JJfD5WKc5kRfqY5QYQSmrDY=; b=MYyP1S5AqVtIdeX0885+wN8B8KcJZ25Y4DxBP45Ndx7GGE+Wb1KM9as7iTCfJXDmxY Pftlvzv3pXj9hss6fWGRsGM6ythNKv1jFDCeU+VPau66fcnjB0fRjwDh+hTn1ZjLFxjB pQp5uwioyWgYaY7FDhmRENxwuId2aeGEnhf1bIjrJajeDGZe9dzcGRA7fQY/dINtXkhN Dl4xWHgC8wrLGQXDc1NIg5A0OpwCaLOF0/dglYhbUWxuaGXVnXiy+yIBPAkhoHxxD/B/ bD38FgomJ4zwml04cTj+/r3FGfk7HhqNMNaBODvauKhhQWCxS9rgGWtaMog/k/l8ZcBT L7JQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.158.136 with SMTP id wu8mr7955626vdb.33.1372678565890; Mon, 01 Jul 2013 04:36:05 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.163.71 with HTTP; Mon, 1 Jul 2013 04:36:05 -0700 (PDT) In-Reply-To: <51D1650F.5070305@gentoo.org> References: <51BF597B.6060600@gentoo.org> <51CF1759.10903@gentoo.org> <51CF4529.7010307@gentoo.org> <51D011C1.2040606@gentoo.org> <20130630185215.GA968@linux1> <1372625765.17485.18.camel@big_daddy.dol-sen.ca> <20130701005911.GA1936@linux1> <51D14CC1.9080500@gentoo.org> <51D1650F.5070305@gentoo.org> Date: Mon, 1 Jul 2013 07:36:05 -0400 X-Google-Sender-Auth: ZUmWScyvd5S9fYMFBHoUaNxy8UY Message-ID: Subject: Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees) From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 27bf6de6-23a9-4eb7-bbd1-aeb9f247a005 X-Archives-Hash: 0b1cace27f01926ee413cdfc3c16633f On Mon, Jul 1, 2013 at 7:16 AM, Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n wrote: > > I wrote in a previous message that I would reconsider my position if the > amount of forked packages grew to unmanageable proportions. But until > then, if the kids cannot get along they shall play on separate playground= s. As far as I'm concerned, kids who can't get along can go play someplace else. If you want your own apache ebuild that can't be touched by anybody but you, that's what overlays are for. Don't like that, please don't vote for me. I have no issues with real alternate implementations (openrc vs systemd, udev vs eudev, consolekit vs logind, alsa sorta-vs pulseaudio, etc). However, projects that discuss their plans openly, embrace our philosophy of choice, and which properly support their work to our quality standards will be able to take dumps on your packages if you put them in the main tree and there is nothing you'll be able to do about it. Call it tyranny of the majority if it makes you happier, but a distro that gives every developer veto-power over any change is destined for extinction. Innovation will always come from individual developers; the role of the Council is not to try to mandate innovation, but to get the roadblocks out of the way so that it can flourish. Gentoo has never needed internal forks simply because developers cannot get along. I don't see single-text-file additions to packages as a reason that we should start. > But in this hypothetical scenario you have unloaded additional work on > the maintainer. He just wants to bring the latest and greatest version > to his users, and the failing patch prevents him from doing that. Is it more work? Only in the sense that not being able to drop stable versions is. If things get out of hand we'll deal with them, but polluting the package namespace with internal forks is a really ugly technical solution to a really simple people problem. Rich