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 <kentfred...@gmail.com> > wrote: >> On 13 March 2012 11:02, Mike Gilbert <flop...@gentoo.org> 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 is these days. It's as if people grew up and learned how to have a reasonable discussion. Meanwhile, I doubt anyone who survived those days wants to relive them, for sure! So let's just agree not to kick that sleeping dog any more than we already have, lest he wake up! The posts are after all archived for those newbies who wish to see for themselves 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 technical merits of the various solutions were, the discussion was simply too politically and interpersonally poisoned to handle in any reasonable way. Gentoo lost some good folks around that time, and if the council had moved forward with ANY of the more forward looking proposals, including g55 but not limited to it, it would have very likely triggered a split of gentoo into at least two, likely three or four different factions, and gentoo as we know it would have gone the way that the zynot fork went... Honestly, as bad as things were at the time and knowing that there ARE unstable folks like Hans Reiser around in the FLOSS community, I wouldn't have been /that/ surprised if someone really DID 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, after the worst of it was over, but it was still too poisoned to deal with in any reasonably sane way. Luckily, the council had the wisdom to more or less punt, voting down g55 AND the other discussed solutions, basically sticking with what we had, with minor tweaks, until things calmed down. It is my opinion that they really did very possibly prevented the rather bad end of gentoo by doing so. But they did leave the door open, calling for further study of the 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 veteran of that era, is that despite all the posts so far, the debate has remained reasonably civil. People are debating hard for their viewpoints, but nobody's crossing the line and making it personal as was the unfortunate norm back then, and people approaching the line are quickly nudged back away from it. I honestly don't know if it's something that can be reasonably dealt with, yet. I honestly don't know how pressing is the need to deal with it /now/ vs perhaps punting it a couple more years. Either way, the simple fact that we're discussing it as sane humans instead of as a pack of wild dogs, viciously snarling and snapping at each other, is progress. For the record, I agree with someone else, sorry I don't remember who, that said it seems that a lot of folks seem to want glep55 now, just not by that name. Ultimately, I believe at least the one-shot variant, possibly with additional later shots but with each one well debated on its own merits to be SURE about it before moving forward (IOW, not an open-ended forever increasing series), with intermediate updates keeping the same filename structure in between, is about the best choice available. But whether now's the appropriate time for that one-shot, and its details, I don't know. At least our discussion is on sane terms, these days, something I don't believe could be honestly stated, before, and for 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 decision for some time to come, and especially where it has been going on for years, so another year isn't going to be life or death, I have an idea. What about, for such issues, requiring, in effect, that two successive councils approve it, with possibly a 5/7 or even 6/7 override. If the majority is that strong, it's unlikely that a new council would see it differently anyway. If not, conditionally approve a decision, with the condition that the next year's council must also approve it. Between the two approvals, any remaining implementation details can be worked out, and for decisions such as one affecting future EAPIs like this one does, implementation and testing can go into the PMs and if desired/necessary, the alternate tree prepared, but it can't roll-out "live" on the main gentoo tree (and any implementing overlays do so at a known and calculated risk of having to roll-back) until the second council approves the change as well. And the first council's approval must be, say, a minimum of three months before council turnover. No hasty post-election lame-duck sessions ramming stuff thru so the new council can in just weeks finalize things, tho of course the supermajority override still could, when really seen to be necessary by /that/ many council members. That way, devs get to vote for a new council in the middle, and if they really dislike an action, they can simply vote in an opposing council. Obviously, this only works for multi-year projects with multi-year implications, not so well for, say, appeals to council of a forced retirement or the like, but it seems to me that such a mechanism would guard quite well against one council voting something thru with a slim majority that's reverted the next year, for things with the long-term implications something like this obviously has. Based on my reading of the logs, that's actually been a council concern a time or two, for at least a couple members. Formally having the two- successive-councils option for the biggest and longest term issues would remove that concern and allow the initial council to vote on the merits as they saw them, and a second council will have then certainly taken positions (even if it's an official "no position" position) on the issue, either by being reelected after the first vote or by statement, so can vote in confidence knowing that the larger gentoo developer pool backs them in their vote. -- 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
