From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SLsnX-0000rF-LB for garchives@archives.gentoo.org; Sun, 22 Apr 2012 09:09:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 868BEE0C63; Sun, 22 Apr 2012 09:09:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 44482E0BFB for ; Sun, 22 Apr 2012 09:08:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id CE53A1B4003 for ; Sun, 22 Apr 2012 09:08:17 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5.5 tests=[AWL=-0.943, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckalqemV3z6Q for ; Sun, 22 Apr 2012 09:08:11 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id DAC521B408B for ; Sun, 22 Apr 2012 09:08:09 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SLsm5-0004F8-Qx for gentoo-dev@gentoo.org; Sun, 22 Apr 2012 11:08:05 +0200 Received: from 109.176.201.97 ([109.176.201.97]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 11:08:05 +0200 Received: from slong by 109.176.201.97 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 11:08:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Sun, 22 Apr 2012 10:11:54 +0100 Organization: Friendly-Coders Message-ID: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> <4F833687.4040004@gentoo.org> <4F8503DF.1010802@gentoo.org> <4F85E21C.4060106@gentoo.org> 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-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.201.97 X-Archives-Salt: bead6e2e-9bdf-48a1-8b54-9b1406a41a30 X-Archives-Hash: 25c29728f6e7217d58719db0623dd386 Mike Gilbert wrote: > On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long wrote: >> And again, I ask: if it were *not* about running udev without an >> initramfs, then why would anyone even be discussing the possibility of >> patching or forking? >> > > Here is my interpretation: the council voted on the following question: > > The question is: "Decide on whether a separate /usr is still a > supported > configuration." > > It did not decide the method that would be used to accomplish this. A > few council members (Chainsaw mainly) expressed a desire to do it > without an initramfs, but an official stance on this was not put > forward. > While I agree it would be better if the vote had specified "without an initramfs" it seems clear to me that that was what was under discussion, since a) Chainsaw was asked to describe the issue and specifically turned down an initramfs, and b) udev with an initramfs already supports a separate /usr partition, so why would the Council need to vote on it? It's already supported if you use an initramfs, so there isn't anything to discuss, nor vote on as technical policy. > You are reading into it more that you should. Well two of the votes specifically mention initramfs: As long as there is no automated help for people to automatically get initramfs I vote yes i vote no, because diverting from upstream is not an ideal option for me If it were not about supporting users without an initramfs, why would a yes vote mean diverging from upstream? At this point, I'd like the Council to clarify. I really don't see what else could have required a vote, and the whole discussion was about not using an initramfs, who would maintain any patches needed, and what the potential consequences might be. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)