[gentoo-dev] Re: RFD : .ebuild is only bash

[Duncan]

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 <kentfredric@×××××.com>
> wrote:
>> On 13 March 2012 11:02, Mike Gilbert <floppym@g.o> 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