[gentoo-dev] Re: A Little Council Reform Anyone?
Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org posted 4a4d97d5.10...@gentoo.org, excerpted below, on Fri, 03 Jul 2009 05:32:05 +: I have a few ideas about this that I'll have to put in writing and share later, but let me start by proposing that for such a change we require the support of at least 2/3 of the devs that vote *and* a minimum of 1/3 of all devs. By requiring the support of at least 1/3 of all devs, we can ensure that it won't be possible to have extreme events as getting a policy change approved by 90% of the voting devs which happen to represent 10% of all devs. OTOH, requiring 2/3 of the voting devs might prove to be to hard in an election with a high turnout - afaicr we didn't have 60% turnout in any election in at least the last 2 years. I don't believe that's workable. See for instance the issues getting the Gentoo Foundation's bylaws approved. A 2/3 super-majority of voting devs is fine, but the 1/3 of total devs requirement can be problematic, given that some devs simply aren't interested in politics enough to vote at all, ever. We don't want to be in the situation the Foundation was in. Now, if the total devs requirement was much lower, say 10%, then maybe, but if we're going that low, is it even worth bothering? So I'd say keep it to a 2/3 super-majority of voting devs, and leave it at that. If people don't what 2/3 of say a 10 % voting minority decided, well, they should have voted. (And if /enough/ people don't like it, have another vote and undo it.) For much the same reasons, tho, I favor the council super-majority idea. Certainly, a simple majority changing what is effectively Gentoo's constitution is distressingly unstable, but 5/7 is 71%, and if no more than two council members can be found to oppose a move that needs to be stopped, we're in trouble, regardless. Plus, they ran for the job, so can be considered to be politically active enough to actually vote, unlike devs in the general case. -- 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
Re: [gentoo-dev] Re: A Little Council Reform Anyone?
On Thu, Jul 02, 2009 at 09:43:53PM +0100, Ciaran McCreesh wrote: On Thu, 2 Jul 2009 22:29:39 +0200 Christian Faulhammer fa...@gentoo.org wrote: Which groups who would like to be able to contribute currently feel that they can't, why do they feel that and why haven't they said so? For example people from the other package managers apart from Paludis. Zac's said he's not particularly interested in the deciding upon new features part, and despite that there was considerable Portage influence upon all three new EAPIs. The Pkgcore people haven't tried pushing for anything as far as I know. The option's there for them, but they haven't expressed any interest. Actually pkgcore folk have pushed for stuff. mtime preservation is a simple example of things I've pushed for- at the time implemented by portage/pkgcore, eliminates the orphan potential for .pyc and other generated files (iow, very useful). My personal opinion on what goes into PMS is that it's typically only stuff that paludis supports already (or is a direction paludis wants to go towards). Could be wrong, but that's my opinion of it via watching/involvement in it from it's public inception. In terms of involvement in PMS, frankly it's not worth it from where I'm sitting due to ciarans behaviour. Simplest explanation possible there is that w/ ciaran being effectively the loudest voice PMS wise, combined w/ behaviour involving sitting on bugs in competing managers (including instances where that manager isn't compliant w/ PMS) and popping them out at random times on the ML to rip on the manager, it's not worth dealing with it. It's not a matter of having thicker skin- it's literally a question of worth. Is it worth trying to have a voice if it means exposing yourself to BS behaviour? Via that line of thought y'all should be able to understand my personal choice involvement wise. It's basically a happier existance to just implement the spec, and keep the head down ;) My two cents on it, for what it's worth. ~brian pgpNF1BWasHyA.pgp Description: PGP signature
Re: [gentoo-dev] Re: A Little Council Reform Anyone?
On Fri, 3 Jul 2009 02:08:48 -0700 Brian Harring ferri...@gmail.com wrote: Actually pkgcore folk have pushed for stuff. mtime preservation is a simple example of things I've pushed for- at the time implemented by portage/pkgcore, eliminates the orphan potential for .pyc and other generated files (iow, very useful). The mtime preservation implemented by (recent -- earlier versions mirror what Paludis still does) Portage versions has problems that you're fully aware of. We're looking at fixing it properly, including addressing the problems you're trying to brush under the carpet, for EAPI 4 rather than EAPI 3 simply because the Council chose to freeze EAPI 3 before a full solution had been proposed. My personal opinion on what goes into PMS is that it's typically only stuff that paludis supports already (or is a direction paludis wants to go towards). Could be wrong, but that's my opinion of it via watching/involvement in it from it's public inception. Er, not in the least bit. Out of the 7 features in EAPI 2: * One was a last minute workaround for a Portage behaviour change that broke things. * Five were feature requests from Gentoo developers. * One was a response concocted by Paludis people in response to a common problem described by Gentoo developers. Out of the 18 features in EAPI 3: * 14 were feature requests from Gentoo developers. * 1.5 were directly from Portage. * 1.5 were technicalities worked out based upon real world testing of proposed features by Paludis people. * One was a colaboration between the Portage and Paludis people. Paludis had support for nine of these beforehand. In terms of involvement in PMS, frankly it's not worth it from where I'm sitting due to ciarans behaviour. Simplest explanation possible there is that w/ ciaran being effectively the loudest voice PMS wise, ...because I do most of the work, and I'm not interested in spending weeks discussing proposals I think are a really bad idea with the Council. There's nothing to stop you from doing that if you believe something should be in an EAPI -- you're welcome to champion your own feature requests. Also, I'll remind you that our current rejected patches list is sitting at approximately one item... combined w/ behaviour involving sitting on bugs in competing managers I've given up looking at pkgcore's code or trying to test it. The only bugs I'm aware of in pkgcore are those that've been reported by other people. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: A Little Council Reform Anyone?
Hi, in general you speak about the council but do you have any concrete plans/goals you want to achieve? Ned Ludd so...@gentoo.org: The dev population is quite a strange beast. I never expected to win. Nor did I, especially because you were quite low on my ballot. Congratulations. The devs have a voice one time of the year: when it comes time to vote. But what about the rest of the year? What happens when the person you voted for sucks? You are mostly powerless to do anything other than be really vocal in what seems like a never ending battle. That needs to change. I'm not quite sure how. But I'd like to see the dev body have a year-round voice in the council. Either via quick votes year-round on topics or simply by having discussion in the channel. Devs should have a right to voice their concerns to the council and engage in interactive conversations without being labeled troll. We have the forums for quick votes, votify is too much to get a picture of opinions. So use -dev-announce and forums. Another one of the things I'd like to see and help reform with the council. First off it spends way too much time on EAPI/PMS. There is no reason to make the council an extension of the portage team. As member of the PMS team I agree, we have to reach out to more people. No matter how well Ciaran does the job as editor-in-chief the process needs to be broadened to involve other groups, too. For example prefix comes to mind. It was a project I did not like at first. I'm not even a user. And there are things I surely don't like about it as is. But there is community support and it's the icing on the cake for some. So I'll back the fsck up and give credit where it's due. This is a perfectly good example of a project/fork that needs to come back home. Perhaps it's time to cherry pick some more stuff/people out of Sunrise? Fully agree here, my devhood is a product of Sunrise. desultory points out any two council members can decide to approve anything, and that decision is considered to be equivalent to a full council vote until the next meeting. I vaguely recall that rule. I'm not sure about you, but I think that is a little to much power to put in the hands of a few. Any dev mind if we dump that power? Maybe extend that to three, but leave such a emergency measure in place. Meetings will likely go back to one time per month and be +m with +v be handed out per request with open chat pre/post meetings. The reason for this is to keep the meetings on-track. I won't engage in endless discussions. Facts can be presented. They will be reviewed on merit, technical and social. Agree. The reason the meetings should go back to monthly is to allow those who are council members in Gentoo to accomplish things other than the council only. We all have personal lives and we all have our respective roles we play outside of the council. Another note on meetings. The time they are held currently don't fit well with my work schedule. That you have to discuss with your fellow council members. So lets have some damn fun again !...@#$ Oh yeah! V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A Little Council Reform Anyone?
On Thu, 2 Jul 2009 22:14:25 +0200 Christian Faulhammer fa...@gentoo.org wrote: Another one of the things I'd like to see and help reform with the council. First off it spends way too much time on EAPI/PMS. There is no reason to make the council an extension of the portage team. As member of the PMS team I agree, we have to reach out to more people. No matter how well Ciaran does the job as editor-in-chief the process needs to be broadened to involve other groups, too. Which groups who would like to be able to contribute currently feel that they can't, why do they feel that and why haven't they said so? Really, the only big issues we've had with EAPI work are getting Portage support and working around a Council that wants to both micro-manage every last detail of every last feature and only put in an hour of work every two weeks. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: A Little Council Reform Anyone?
Hi, Ciaran McCreesh ciaran.mccre...@googlemail.com: On Thu, 2 Jul 2009 22:14:25 +0200 Christian Faulhammer fa...@gentoo.org wrote: Another one of the things I'd like to see and help reform with the council. First off it spends way too much time on EAPI/PMS. There is no reason to make the council an extension of the portage team. As member of the PMS team I agree, we have to reach out to more people. No matter how well Ciaran does the job as editor-in-chief the process needs to be broadened to involve other groups, too. Which groups who would like to be able to contribute currently feel that they can't, why do they feel that and why haven't they said so? For example people from the other package managers apart from Paludis. What we need is a more straight forward way for new features...yes, some measures are already being worked out, but there is still work to do. Really, the only big issues we've had with EAPI work are getting Portage support and working around a Council that wants to both micro-manage every last detail of every last feature and only put in an hour of work every two weeks. Discussion of EAPI features took place on the -dev mailing list involving council members, so one hour every two weeks is quite exaggerated. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A Little Council Reform Anyone?
On Thu, 2 Jul 2009 22:29:39 +0200 Christian Faulhammer fa...@gentoo.org wrote: Which groups who would like to be able to contribute currently feel that they can't, why do they feel that and why haven't they said so? For example people from the other package managers apart from Paludis. Zac's said he's not particularly interested in the deciding upon new features part, and despite that there was considerable Portage influence upon all three new EAPIs. The Pkgcore people haven't tried pushing for anything as far as I know. The option's there for them, but they haven't expressed any interest. Incidentally, less than half of the things in EAPI 3 were of an origin that could even remotely be considered Paludisish... What we need is a more straight forward way for new features...yes, some measures are already being worked out, but there is still work to do. Unfortunately much of the complexity comes from the constraints we're forced to work with... Really, the only big issues we've had with EAPI work are getting Portage support and working around a Council that wants to both micro-manage every last detail of every last feature and only put in an hour of work every two weeks. Discussion of EAPI features took place on the -dev mailing list involving council members, so one hour every two weeks is quite exaggerated. Sure, some of the old Council were extremely helpful in providing opinions beforehand, in doing the prep work before meetings and in not springing things at the last second. Others insisted upon not reading what they were asked to vote upon before the meeting (or even before voting upon it), and then raising queries, objections and alternatives that were either already addressed, not at all relevant or obviously unworkable. That's what dragged the process out for so long. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: A Little Council Reform Anyone?
On Thu, 2009-07-02 at 22:14 +0200, Christian Faulhammer wrote: Hi, in general you speak about the council but do you have any concrete plans/goals you want to achieve? I think we are in the information gathering phase right now on how to best proceed. So nothing concrete as of this point. More abstract ideas at this point. Ned Ludd so...@gentoo.org: The dev population is quite a strange beast. I never expected to win. Nor did I, especially because you were quite low on my ballot. Congratulations. The devs have a voice one time of the year: when it comes time to vote. But what about the rest of the year? What happens when the person you voted for sucks? You are mostly powerless to do anything other than be really vocal in what seems like a never ending battle. That needs to change. I'm not quite sure how. But I'd like to see the dev body have a year-round voice in the council. Either via quick votes year-round on topics or simply by having discussion in the channel. Devs should have a right to voice their concerns to the council and engage in interactive conversations without being labeled troll. We have the forums for quick votes, votify is too much to get a picture of opinions. So use -dev-announce and forums. Another one of the things I'd like to see and help reform with the council. First off it spends way too much time on EAPI/PMS. There is no reason to make the council an extension of the portage team. As member of the PMS team I agree, we have to reach out to more people. No matter how well Ciaran does the job as editor-in-chief the process needs to be broadened to involve other groups, too. For example prefix comes to mind. It was a project I did not like at first. I'm not even a user. And there are things I surely don't like about it as is. But there is community support and it's the icing on the cake for some. So I'll back the fsck up and give credit where it's due. This is a perfectly good example of a project/fork that needs to come back home. Perhaps it's time to cherry pick some more stuff/people out of Sunrise? Fully agree here, my devhood is a product of Sunrise. desultory points out any two council members can decide to approve anything, and that decision is considered to be equivalent to a full council vote until the next meeting. I vaguely recall that rule. I'm not sure about you, but I think that is a little to much power to put in the hands of a few. Any dev mind if we dump that power? Maybe extend that to three, but leave such a emergency measure in place. Meetings will likely go back to one time per month and be +m with +v be handed out per request with open chat pre/post meetings. The reason for this is to keep the meetings on-track. I won't engage in endless discussions. Facts can be presented. They will be reviewed on merit, technical and social. Agree. The reason the meetings should go back to monthly is to allow those who are council members in Gentoo to accomplish things other than the council only. We all have personal lives and we all have our respective roles we play outside of the council. Another note on meetings. The time they are held currently don't fit well with my work schedule. That you have to discuss with your fellow council members. So lets have some damn fun again !...@#$ Oh yeah! V-Li -- Ned Ludd so...@gentoo.org Gentoo Linux
[gentoo-dev] Re: A Little Council Reform Anyone?
Tobias Scherbaum dertobi...@gentoo.org posted 1246546445.6186.33.ca...@homer.ob.libexec.de, excerpted below, on Thu, 02 Jul 2009 16:54:05 +0200: Ned Ludd wrote: I'd like to see the dev body have a year-round voice in the council. Either via quick votes year-round on topics or simply by having discussion in the channel. What I'd like to see for sure is a formal rule on who can decide to modify or change parts of glep 39. As it's the council's constitution somehow, we have two options from my pov (besides that a former council did decide the council itself can change it's rules): - a large majority (at least 5 out of 7) of council members needs to ack the change - changes to glep 39 require a vote with all developers participating and a large majority (2/3 or 3/4) needs to ack the suggested change [posting to -devel only, as gmane has council as one-way, appropriately] A vote of all developers is a bit steep, but maybe that's the intent. As already mentioned, tho, it'd have to be a super-majority of those voting. But the 5/7 supermajority rule for council to change its own constitution is a really good idea, IMO. That's a 71% supermajority, and should be enough, IMO. I've always been uncomfortable with the simple majority changing its own constitution or bylaws idea, Gentoo council or elsewhere. It's just too unstable for the constitutional level. An EAPI review committee could work well also. As long as we could get non bias people in there. I was thinking about that for quite some time and as long as we get some non-biased people in there we should try that as well. IMO, the official PM implementation required before final approval serves well enough as a practical cap on things, there. As long as that is understood, and council approves a recommendation, then stamps the final spec when implemented, an EAPI committee can't go entirely renegade, no matter who's on it. Plus, the committee approach was effectively what we did for EAPI-3 already, except that arguably council was too hands-on, and more of the debate happened on the dev list and on council than was perhaps appropriate. We already have a list for EAPI/PMS discussion, and I believe announcements and proposals can be made to dev (and/or council) lists with followups set to dev, for discussion. If we simply use what we have and follow that rule, those interested enough to debate it there, effectively form the committee, regardless of whether there's an official one or not. What remains, then, would be for the council to choose a spokeperson to keep them informed of updates and present the details. That person should be seen as reasonably unbiased in ordered to make it work well for all sides, and they should be given a clear mandate from council that will effectively make them chairman of the committee, since they represent it, whether it's formalized or not. Then let that spokesperson present the recommendation to council, preferably in written form, perhaps with a 10 minute verbal meeting time- limit, with the details hashed out however it gets hashed out on the EAPI/ PMS list (council shouldn't need to interfere there, except by creating the spokesperson position, with said spokeperson serving at the pleasure of the council, so they can be removed and someone else appointed, if deemed necessary), with anyone from that list, or dev, or user, able to present an objection, again preferably in written form, with say a 2- minute verbal argument meeting time-limit. Then after the presentation, vote. As with EAPI-3, do it in two stages, preliminary approval, then after implementation, final approval. Total in-meeting time, x2: 10 minutes for spokesperson verbal presentation of written position, made available X days pre-meeting, 2 minutes x N people for independent support/disagree statements (say two people, 4 minutes), one minute for administrative (transitions, etc), 5 minutes at final approval for portage lead if he wishes, 5 minutes for voting. Total 20 minutes meeting time for preliminary approval, 25 minutes for final approval, 45 minutes over two meetings. If it's voted down, it's sent back for further revisions, and won't be scheduled for another chance at council meeting approval for six months. If the council members haven't done their homework and aren't ready to vote at the meeting, it reflects badly on them. If the EAPI committee spokesperson doesn't have the written presentation ready in time, or can't manage his 10 minute verbal presentation, or if there's more than 2-3 people lining up for their 2-minute slot to oppose it, it reflects badly on him, and the council should consider a different spokesperson. Bottom line, IMO, the resources are already there, as are, to some extent, the rules. All council needs to do is find and approve a single reasonably non-biased person to be a spokesperson, and enforce the rules on its own time, with everyone
