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 1S7LHl-000570-4H for garchives@archives.gentoo.org; Tue, 13 Mar 2012 06:32:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5CD8E0E18; Tue, 13 Mar 2012 06:32:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 2BB5EE0DF5 for ; Tue, 13 Mar 2012 06:31:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B1E8864273 for ; Tue, 13 Mar 2012 06:31:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5.5 tests=[AWL=-1.963, BAYES_50=0.8, 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 mubtgHBbDxhB for ; Tue, 13 Mar 2012 06:31:31 +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 6636064776 for ; Tue, 13 Mar 2012 06:31:29 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S7LGV-0002Ii-Cg for gentoo-dev@gentoo.org; Tue, 13 Mar 2012 07:31:23 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Mar 2012 07:31:23 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Mar 2012 07:31:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: RFD : .ebuild is only bash Date: Tue, 13 Mar 2012 06:31:14 +0000 (UTC) Message-ID: References: <4F5E30F1.2010500@gentoo.org> <20318.14784.69603.177708@a1i15.kph.uni-mainz.de> <20120312180424.26ad103b@googlemail.com> <20318.15803.361859.738914@a1i15.kph.uni-mainz.de> <20120312182815.2d73c8df@googlemail.com> <20318.17788.250811.141624@a1i15.kph.uni-mainz.de> <4F5E4739.8040409@gentoo.org> <20120312190130.0170e01a@googlemail.com> <20318.21314.5988.317980@a1i15.kph.uni-mainz.de> <20120312201007.68dbb551@googlemail.com> <20318.26438.217413.826801@a1i15.kph.uni-mainz.de> 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=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.136 (I'm far too busy being delicious; GIT 0efefbf /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f2c1ecb9-e4e9-41ce-b75a-eda4d54af61c X-Archives-Hash: eef10a6a881e3239bcc82b504f884a5e Alec Warner posted on Mon, 12 Mar 2012 15:53:58 -0700 as excerpted: > On Mon, Mar 12, 2012 at 3:37 PM, Kent Fredric > wrote: >> On 13 March 2012 11:02, Mike Gilbert wrote: >>>> The previous council's decision does not prevent this same glep from >>>> going to the council again (decisions are not forever.) [...] >>>> Having the full notes would be helpful in determining why >>>> it was turned down back then; I'm sure a copy of the notes exist. >>> >>> http://www.gentoo.org/proj/en/council/ >>> http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt >>> >>> >> Well that was insightful. As suspected,, there was a lot of people >> saying "Yeaahh, I don't like it", and concluding there were problems >> with it, but the actual technical issues still haven't been presented >> to us. >> Can somebody present a real ( or even theoretical ) problem that could >> arise from having the EAPI in the filename that isn't some abstract >> hand-waving? > In general there was the 'I don't like it crowd (I was one of these, I > care less these days ;p)' > There was the 'it is Ciaran crowd.' This concept is difficult to > describe without a fair bit of context in how the community was being > run at the time. Sometimes I wonder at how much more pleasant the dev-list in particular=20 is these days. It's as if people grew up and learned how to have a=20 reasonable discussion. Meanwhile, I doubt anyone who survived those days= =20 wants to relive them, for sure! So let's just agree not to kick that=20 sleeping dog any more than we already have, lest he wake up! The posts=20 are after all archived for those newbies who wish to see for themselves=20 what the veterans of the era would rather leave well enough alone. > None of the above reasons are what I would term 'technical merits.' > However now (as then) not all decisions are made on their technical > merits. We have adopted (and continue to adopt) solutions that are > imperfect, technically silly, or otherwise lots of work because they > meet some goal we are trying to accomplish. I don't think Gentoo is > alone in this aspect of management. IMO the real reason for the g55 "no" back then, was that whatever the=20 technical merits of the various solutions were, the discussion was simply= =20 too politically and interpersonally poisoned to handle in any reasonable=20 way. Gentoo lost some good folks around that time, and if the council=20 had moved forward with ANY of the more forward looking proposals,=20 including g55 but not limited to it, it would have very likely triggered=20 a split of gentoo into at least two, likely three or four different=20 factions, and gentoo as we know it would have gone the way that the zynot= =20 fork went... Honestly, as bad as things were at the time and knowing=20 that there ARE unstable folks like Hans Reiser around in the FLOSS=20 community, I wouldn't have been /that/ surprised if someone really DID=20 take it too far. Yes, things were THAT bad! Tho it's worth noting that the 2010 date of the log above was, I think,=20 after the worst of it was over, but it was still too poisoned to deal=20 with in any reasonably sane way. Luckily, the council had the wisdom to more or less punt, voting down g55= =20 AND the other discussed solutions, basically sticking with what we had,=20 with minor tweaks, until things calmed down. It is my opinion that they=20 really did very possibly prevented the rather bad end of gentoo by doing=20 so. But they did leave the door open, calling for further study of the=20 issues. When I saw this thread start, I wondered if enough time had passed... The most encouraging thing about this current discussion for me as a list= =20 veteran of that era, is that despite all the posts so far, the debate has= =20 remained reasonably civil. People are debating hard for their=20 viewpoints, but nobody's crossing the line and making it personal as was=20 the unfortunate norm back then, and people approaching the line are=20 quickly nudged back away from it. I honestly don't know if it's something that can be reasonably dealt=20 with, yet. I honestly don't know how pressing is the need to deal with=20 it /now/ vs perhaps punting it a couple more years. Either way, the simple fact that we're discussing it as sane humans=20 instead of as a pack of wild dogs, viciously snarling and snapping at=20 each other, is progress. For the record, I agree with someone else, sorry I don't remember who,=20 that said it seems that a lot of folks seem to want glep55 now, just not=20 by that name. Ultimately, I believe at least the one-shot variant,=20 possibly with additional later shots but with each one well debated on=20 its own merits to be SURE about it before moving forward (IOW, not an=20 open-ended forever increasing series), with intermediate updates keeping=20 the same filename structure in between, is about the best choice=20 available. But whether now's the appropriate time for that one-shot, and its=20 details, I don't know. At least our discussion is on sane terms, these=20 days, something I don't believe could be honestly stated, before, and for= =20 that reason, I 100% agree with the council's rejection of it back then. Meanwhile, for issues such as this, where we'll be living with the=20 decision for some time to come, and especially where it has been going on= =20 for years, so another year isn't going to be life or death, I have an=20 idea. What about, for such issues, requiring, in effect, that two successive=20 councils approve it, with possibly a 5/7 or even 6/7 override. If the=20 majority is that strong, it's unlikely that a new council would see it=20 differently anyway. If not, conditionally approve a decision, with the=20 condition that the next year's council must also approve it. Between the two approvals, any remaining implementation details can be=20 worked out, and for decisions such as one affecting future EAPIs like=20 this one does, implementation and testing can go into the PMs and if=20 desired/necessary, the alternate tree prepared, but it can't roll-out=20 "live" on the main gentoo tree (and any implementing overlays do so at a=20 known and calculated risk of having to roll-back) until the second=20 council approves the change as well. And the first council's approval=20 must be, say, a minimum of three months before council turnover. No=20 hasty post-election lame-duck sessions ramming stuff thru so the new=20 council can in just weeks finalize things, tho of course the supermajorit= y=20 override still could, when really seen to be necessary by /that/ many=20 council members. That way, devs get to vote for a new council in the middle, and if they=20 really dislike an action, they can simply vote in an opposing council. Obviously, this only works for multi-year projects with multi-year=20 implications, not so well for, say, appeals to council of a forced=20 retirement or the like, but it seems to me that such a mechanism would=20 guard quite well against one council voting something thru with a slim=20 majority that's reverted the next year, for things with the long-term=20 implications something like this obviously has. Based on my reading of the logs, that's actually been a council concern a= =20 time or two, for at least a couple members. Formally having the two- successive-councils option for the biggest and longest term issues would=20 remove that concern and allow the initial council to vote on the merits=20 as they saw them, and a second council will have then certainly taken=20 positions (even if it's an official "no position" position) on the issue,= =20 either by being reelected after the first vote or by statement, so can=20 vote in confidence knowing that the larger gentoo developer pool backs=20 them in their vote. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman