Re: [gentoo-dev] Gentoo Council Elections Results for term 2009/2010
On 01-07-2009 22:00:23 +0100, Roy Bamford wrote: > On behalf of the Elections project, the next Gentoo Council will be > composed of:- > > Ned Ludd (solar) > Petteri Räty (betelgeuse) > Denis Dupeyron(calchan) > Tobias Scherbaum (dertobi123) > Ulrich Müller (ulm) > Mart Raudsepp (leio) > Luca Barbato (lu_zero) A big surprise! (is it a birthday present?) Congratulations to all of you! -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Re: New eselect news item for kdeprefix
If there are no further objections, and if I have the OK from Jorge i'll commit the following tonight (name: 2009-07-02-kdeprefix+monolithics.en.txt). Btw is it possible the following message to be uploaded in gentoo.org main site as well? Also, you can send me translations, see http://www.gentoo.org/proj/en/glep/glep-0042.html for additional information. Thanks Title: kdeprefix and monolithic ebuilds issues Author: Theo Chatzimichos Content-Type: text/plain Posted: 2009-07-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Team
[gentoo-dev] Re: New eselect news item for kdeprefix
Hallo, Theo Chatzimichos : > If there are no further objections, and if I have the OK from Jorge > i'll commit the following tonight Fine by me. > Also, you can send me translations So you will provide Greek I assume. Here comes German. > Title: kdeprefix and monolithic ebuilds issues Probleme mit kdeprefix und monolithischen Ebuilds > Author: Theo Chatzimichos Translator: Christian Faulhammer > Content-Type: text/plain > Posted: 2009-07-02 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: New eselect news item for kdeprefix
On Thursday 02 July 2009 11:27:34 Christian Faulhammer wrote: > Hallo, > > Theo Chatzimichos : > > If there are no further objections, and if I have the OK from Jorge > > i'll commit the following tonight > > Fine by me. > > > Also, you can send me translations > > So you will provide Greek I assume. Here comes German. > > > Title: kdeprefix and monolithic ebuilds issues > > Probleme mit kdeprefix und monolithischen Ebuilds > > > Author: Theo Chatzimichos > > Translator: Christian Faulhammer > > > Content-Type: text/plain > > Posted: 2009-07-02 > > Revision: 1 > > News-Item-Format: 1.0 > > Display-If-Installed: > Die Anleitung für KDE in Gentoo wurde überarbeitet und deckt nun die > zwei wichtigsten Problemfelder für KDE-Benutzer ab: > > 1.) Maskierung des kdeprefix USE-Flags für KDE 4-Benutzer und > 2.) die Aktualisierung auf KDE 3.5.10 und KOffice 1.6.3_p20090204 für > die Benutzer der monolithischen Ebuilds. > > Die Anleitung [0] enthält alle Anweisungen zur Behebung dieser Probleme. > [0] http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml > > V-Li Danke. Hopefully I don't have to translate it to greek. I called all 5 gentoo users in Greece. 1 of them was a long time gnome user, two of them stopped using KDE before this incident and the other two after the incident. -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Team
Re: [gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Doug Goldstein wrote: On Wed, Jul 1, 2009 at 9:33 PM, Ned Ludd wrote: 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. Thank you again. I tried the +m/+v thing a year ago and received a few pieces of hate e-mail from mostly non-developer people. Please do go to +m. I usually just read council summaries - when I've tried to read the actual logs it is a COMPLETE mess. In most organizational board-like bodies the board meeting is NOT the place to have open discussion on topics. The open discussion happens everywhere BUT the board meeting. It happens on the phone, on mailing lists, in newspapers, on TV, on talk radio, etc. During the board meeting people who want to make a statement can do so within a limited amount of time, and then the board casts its vote. 95% of the time the way the vote will go is known before the meeting happens. The meeting is just a formality. If there is to be a 300 line argument over proposal-A vs proposal-B, do it on the mailing lists, or on IRC. Council votes should be straightforward matters. If we want to have more interaction - how about this idea: Formal council meetings happen once per month, and they are the ONLY place votes take place. However, the council will try to meet more often for less formal discussion. +m/+v may be imposed at any time if there is a large turnout just to keep things somewhat orderly. Attendance is not mandatory for these meetings, but is encouraged. You could also schedule them at a variety of times - again, you're not missing any votes so if only 1/3rd of the council makes any particular meeting it isn't a big deal. As far as having two council members temporarily approve items goes - it isn't a bad thing to have in general, but it should really only be used in emergency situations. I'm not sure if we even need it - I suspect that groups like infra will "do the right thing" most of the time if there is an emergency (dev starts committing "rm -rf /*" scripts all over the portage tree - infra suspends cvs access first and finds devrel later). Maybe a quick way to assess developer opinions on issues would be forum polls? The votify system is potentially good as well, but I'm not sure how much work it requires on the part of infra to gather/tally the votes. We really don't need the full rigor of votify for most issues (though it probably should be used if there are true referendums on serious matters). And, of course, there is always the "measure the noise on the mailing list" approach, but I'm not a big fan of that (though I am a fan of lists in general).
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
There's a lot of good stuff to think about here. For what it's worth, some initial comments. On Wed, 2009-07-01 at 19:33 -0700, Ned Ludd wrote: > The dev population is quite a strange beast. I never expected to win. > Why would you vote for somebody who did not even publish a manifesto? > I don't know but I love you for it. My only intention was to help offset > dev-zero being able force the will of outside forces upon us. > Well that has been accomplished for now (w00t). But I > never ever expected to be ranked so high. "/me blushes" So that means you > guys/gals expect stuff from me. Well as I never wrote a manifesto but > you still voted for me, I guess I should share some of my ideas on what > I'd like to see happen over the following year. > > 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 could provide for a recall vote, but I don't like that idea. Discussion in channel is ideal if there is some way/someone to help keep it civil enough to be useful. > 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. Portage is > still the official package manager of Gentoo. Granted it's good to > accommodate others to an extent and I've always kept an open mind on other > tools. > Alternatives are good as there is always the right tool for the task at hand. > But > the council really should not be getting involved most of the time unless > there > is a conflict which can't be worked out among the masses and those trying to > get > portage to adopt new features. If the dev body wants it otherwise then > I'd like to turn my vote over to you the devs. Each and every time the > council wants/has to vote on an EAPI/PMS feature then I'll happily put my > vote in your hands. You fire up that old votify system and use my vote > as yours. Not a bad idea if votify is agile enough. > Note however that zmedico is not in favor of his time being > wasted on deciding what PMS/EAPI features are good. He simply likes bugs > and solving those. He likes giving us new features and tends to be more in > favor of the devs and community figuring out what is best for us. > An EAPI review committee could work well also. As long as we could get > non bias people in there. > EAPI review committee --- please do. I agree that council meetings are not the place to do detail EAPI work. > The council should be more about community vs technical issues only. > We have lots of top level projects within Gentoo which have simply given > up on the council as being an outlet to accomplish anything useful. > It should be our job to look at the projects in Gentoo. Look at the ones > that have a healthy community and encourage and promote them in ways. > Agreed. > 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? > > 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? > Dump it. > 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. > Probably a good idea. I don't much care for biweekly free-for-alls either. > 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. > > I'm not subsc
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Ned Ludd wrote: > 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. I'm not sure about that, but we can easily give it a try. 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 Also I'd like to require commit messages to gleps (and especially glep 39) being useful and denote based on which decision by whom that change got made. For example the following commit message I'd consider quite useless (at least two or three years ago): "Add the one person one vote clause to GLEP 39 as agreed." [1] Who did agree? Where is that noted down? ... and so on. > 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. > The council should be more about community vs technical issues only. > We have lots of top level projects within Gentoo which have simply given > up on the council as being an outlet to accomplish anything useful. > It should be our job to look at the projects in Gentoo. Look at the ones > that have a healthy community and encourage and promote them in ways. ack > 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? prefix is a really good example, yeah. Nearly noone knows it, but it's really cool to have for example a virtualized windows machine running on a linux host. The windows box then runs prefix in interix. Not that it's really useful at all (hey, it's slow as hell) - but it's very interesting that such things are possible and it's definitively an eyecatcher on expos. prefix is one of Gentoo's most underrated projects. As for Sunrise I do think that's what we already do - but: getting users more actively involved in Sunrise makes them happy, plus it's easier for us to recruit new developers. Therefore: push Sunrise! I very much disliked how the Sunrise project has been started some years ago, but in the end we do need to integrate it a tad better to make it even more useful for both users and developers. > 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? It's quite much power in quite a few hands, but in the end that's some kind of "last resort rule". All council members should be smart enough (and i do consider all of us being smart enough) to know when that "last resort" becomes active. Therefore I think it doesn't hurt to have such a rule 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. > > 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. I'm all for going back to monthly meetings and make them a tad more organized. As I summarized in the last few minutes of our last council meeting - we do have rules in place to keep our meetings organized, we just need to follow them. A
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
On Thu, Jul 2, 2009 at 7:54 AM, Tobias Scherbaum wrote: > Ned Ludd wrote: >> 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. > > I'm not sure about that, but we can easily give it a try. > > 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 Just FYI, Gentoo is lucky if 1/2 of the devs vote; so I assume here you mean large majority of the people who actually voted. > > Also I'd like to require commit messages to gleps (and especially glep > 39) being useful and denote based on which decision by whom that change > got made. For example the following commit message I'd consider quite > useless (at least two or three years ago): > > "Add the one person one vote clause to GLEP 39 as agreed." [1] > > Who did agree? Where is that noted down? ... and so on. > >> 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. > >> The council should be more about community vs technical issues only. >> We have lots of top level projects within Gentoo which have simply given >> up on the council as being an outlet to accomplish anything useful. >> It should be our job to look at the projects in Gentoo. Look at the ones >> that have a healthy community and encourage and promote them in ways. > > ack > >> 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? > > prefix is a really good example, yeah. Nearly noone knows it, but it's > really cool to have for example a virtualized windows machine running on > a linux host. The windows box then runs prefix in interix. Not that it's > really useful at all (hey, it's slow as hell) - but it's very > interesting that such things are possible and it's definitively an > eyecatcher on expos. prefix is one of Gentoo's most underrated projects. > > As for Sunrise I do think that's what we already do - but: getting users > more actively involved in Sunrise makes them happy, plus it's easier for > us to recruit new developers. Therefore: push Sunrise! I very much > disliked how the Sunrise project has been started some years ago, but in > the end we do need to integrate it a tad better to make it even more > useful for both users and developers. > >> 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? > > It's quite much power in quite a few hands, but in the end that's some > kind of "last resort rule". All council members should be smart enough > (and i do consider all of us being smart enough) to know when that "last > resort" becomes active. Therefore I think it doesn't hurt to have such a > rule 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. >> >> 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 >>
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Alec Warner wrote: > > 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 > > Just FYI, Gentoo is lucky if 1/2 of the devs vote; so I assume here > you mean large majority of the people who actually voted. Uhrm, yeah ... of course. - Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
Mike Frysinger wrote: > here's an item that should be relatively quick to address: fix the typo in > GLEP 39 where this line is missing (it's been in the council homepage > forever): > Only Gentoo developers may be nominated I'd like to add that requirement for proxies as well. Varied interpretations of common sense seems to make that necessary. - Tobias
Re: [gentoo-dev] A Little Council Reform Anyone?
Ned Ludd a écrit : [snip, lots of insightful stuff I either agree with or don't really understand] So lets have some damn fun again !...@#$ _That_ I whole heartedly agree with. Please, all of you in the new council, try to keep this in mind :) Thanks Rémi
[gentoo-dev] Re: Gentoo Council Elections Results for term 2009/2010
* Roy Bamford : > The full ranked list of candidates, in order, is:- > > solar > betelgeuse > calchan > dertobi123 > ulm > leio > lu_zero > patrick > dev-zero > ssuominen > scarabeus > gentoofan23 > peper > _reopen_nominations Can you please publish the full ranking output?
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
On Thursday 02 July 2009 11:02:45 Tobias Scherbaum wrote: > Mike Frysinger wrote: > > here's an item that should be relatively quick to address: fix the typo > > in GLEP 39 where this line is missing (it's been in the council homepage > > forever): > > Only Gentoo developers may be nominated > > I'd like to add that requirement for proxies as well. Varied > interpretations of common sense seems to make that necessary. i'd keep them as sep topics as the first should go through quickly without discussion. the latter i'm not terribly sold on -- the understanding is that a council member should have the good sense to only pick an appropriate proxy. the definition of "appropriate" is of course up for grabs. ignoring the tools, there is the possibility of bringing non-devs further into the Gentoo fold (assuming the proxy is well versed in the topics at hand and not just "another body") ... then again, looking at the 4 year history, this has never happened, so it's doubtful it will happen. guess the proposal is fine. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
On Thursday 02 July 2009 10:54:05 Tobias Scherbaum wrote: > Ned Ludd wrote: > > 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. > > I'm not sure about that, but we can easily give it a try. > > What I'd like to see for sure is a formal rule on who can decide to > modify or change parts of glep 39. we already have a formal method: - change is proposed ahead of time like any other business for council to review (which means the community sees it) - council votes and assuming it passed - the dev/council lists are notified of changes (see previous summaries for example) - if there is still no problems, then the project page/GLEP is amended officially if the dev community has a problem, then it should have come up like any other issue along the way. if the only way to resolve the greater dev concerns is with a vote, then that is how it goes. needing a full community vote all the time is a huge time waste for absolutely no gain. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
I'll have things to say about this but I'm still in the woods with dialup until monday. So either I can get close to a fatter pipe later today or tomorrow, or I'll do it on monday night from home. Denis.
Re: [gentoo-dev] A Little Council Reform Anyone?
On Wed, 01 Jul 2009 19:33:52 -0700 Ned Ludd wrote: > My only intention was to help offset > dev-zero being able force the will of outside forces upon us. > Well that has been accomplished for now (w00t). What is this all about? Did I miss something? Was Gentoo threatened with takeover? Cheers, -- |\ /|| | ~ ~ | \/ ||---| `|` ? ||ichael | |iggins\^ / michael.higgins[at]evolone[dot]org
Re: [gentoo-dev] Exim and Sendmail need a maintainer
On 24-06-2009 13:51:37 +, Torsten Veller wrote: > | mail-mta/exim. I'm looking for users that want to help maintaining Exim. Especially if you feel like becoming a Gentoo developer at some time, contact me directly. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] A Little Council Reform Anyone?
On Thursday 02 July 2009 13:47:45 Michael Higgins wrote: > On Wed, 01 Jul 2009 19:33:52 -0700 Ned Ludd wrote: > > My only intention was to help offset > > dev-zero being able force the will of outside forces upon us. > > Well that has been accomplished for now (w00t). > > What is this all about? Did I miss something? Was Gentoo threatened with > takeover? please review the current/last week threads. as a general statement, you cant ignore recent threads on the mailing list and then respond to newer ones going "what is this all about". -mike signature.asc Description: This is a digitally signed message part.
[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 : > 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 http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode 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 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 : > On Thu, 2 Jul 2009 22:14:25 +0200 > Christian Faulhammer 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 http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode 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 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
Re: [gentoo-dev] Exim and Sendmail need a maintainer
Fabian Groffen wrote: On 24-06-2009 13:51:37 +, Torsten Veller wrote: | mail-mta/exim. I'm looking for users that want to help maintaining Exim. Especially if you feel like becoming a Gentoo developer at some time, contact me directly. I recommend you post this to planet, the forums, maybe the -user mailing list and Gentoo's Newsletter... oh wait! Maybe not the newsletter then. =P It might be useful to include a summary of what you expect the users to do, what knowledge they need and what help is available (Don't forget that what's obvious to you may not be obvious to them!) More than 2 users might actually see it then =P AllenJB
[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 : > > 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 Gentoo Linux
Re: [gentoo-dev] Re: New eselect news item for kdeprefix
commited, thank you all for the suggestions and the translations. I'll have to ask again though, is it possible to have it in the main site as well? in fact, who is in charge for the main site? gdp maybe? On Thursday 02 July 2009 11:50:29 Theo Chatzimichos wrote: > On Thursday 02 July 2009 11:27:34 Christian Faulhammer wrote: > > Hallo, > > > > Theo Chatzimichos : > > > If there are no further objections, and if I have the OK from Jorge > > > i'll commit the following tonight > > > > Fine by me. > > > > > Also, you can send me translations > > > > So you will provide Greek I assume. Here comes German. > > > > > Title: kdeprefix and monolithic ebuilds issues > > > > Probleme mit kdeprefix und monolithischen Ebuilds > > > > > Author: Theo Chatzimichos > > > > Translator: Christian Faulhammer > > > > > Content-Type: text/plain > > > Posted: 2009-07-02 > > > Revision: 1 > > > News-Item-Format: 1.0 > > > Display-If-Installed: > > > Die Anleitung für KDE in Gentoo wurde überarbeitet und deckt nun die > > zwei wichtigsten Problemfelder für KDE-Benutzer ab: > > > > 1.) Maskierung des kdeprefix USE-Flags für KDE 4-Benutzer und > > 2.) die Aktualisierung auf KDE 3.5.10 und KOffice 1.6.3_p20090204 für > > die Benutzer der monolithischen Ebuilds. > > > > Die Anleitung [0] enthält alle Anweisungen zur Behebung dieser Probleme. > > [0] http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml > > > > V-Li > > Danke. > Hopefully I don't have to translate it to greek. I called all 5 gentoo > users in Greece. 1 of them was a long time gnome user, two of them stopped > using KDE before this incident and the other two after the incident. -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Team
[gentoo-dev] Re: [gentoo-commits] gentoo-news r11 - in 2009: . 07 07/2009-07-02-kdeprefix+monolithics
Hi, "Theo Chatzimichos (tampakrap)" : > +[0] http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml > \ No newline at end of file You should configure your editor correctly. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Tobias Scherbaum wrote: > Alec Warner wrote: >>> 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 >> Just FYI, Gentoo is lucky if 1/2 of the devs vote; so I assume here >> you mean large majority of the people who actually voted. > > Uhrm, yeah ... of course. 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. > - Tobias -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE
[gentoo-dev] Re: A Little Council Reform Anyone?
Tobias Scherbaum 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 wo
[gentoo-dev] Re: A Little Council Reform Anyone?
"Jorge Manuel B. S. Vicetto" 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] Gentoo Council Elections Results for term 2009/2010
I'm forwarding Roy's email to the dev-announce ml for reaching the wider community and for future reference. Roy Bamford wrote: > All, > > On behalf of the Elections project, the next Gentoo Council will be > composed of:- > > Ned Ludd (solar) > Petteri Räty (betelgeuse) > Denis Dupeyron(calchan) > Tobias Scherbaum (dertobi123) > Ulrich Müller (ulm) > Mart Raudsepp (leio) > Luca Barbato (lu_zero) > > The full ranked list of candidates, in order, is:- > > solar > betelgeuse > calchan > dertobi123 > ulm > leio > lu_zero > patrick > dev-zero > ssuominen > scarabeus > gentoofan23 > peper > _reopen_nominations > > The details will be posted on the elections page shortly. We've restructured the council page results in the elections project space. The master ballot[1] and the results[2] have now been added. The nominees[3] page was moved. We plan to add some index pages with links to the elections files and some general pages with documents about the organization of an election soon. [1] - http://www.gentoo.org/proj/en/elections/council/2009/master-council200906.txt [2] - http://www.gentoo.org/proj/en/elections/council/2009/council200906-results.txt [3] - http://www.gentoo.org/proj/en/elections/council/2009/council-200906-nominees.xml > All voting members of the electorate should have received their ID by > now. The master ballot file is attached to enable voters to check that > their vote was counted. There were 124 votes casted for this election out of a total of 248 eligible developers, meaning we had an even 50% turnout. > Anyone who has not received their ID or whos vote is missing from the > attached master ballot file should contact elections@ as soon as > possible. > -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE - confirmation 2743 - betelgeuse calchan gentoofan23 patrick dertobi123 scarabeus dev-zero lu_zero _reopen_nominations peper leio ssuominen ulm solar - confirmation 2854 - solar leio scarabeus dev-zero gentoofan23 patrick calchan peper lu_zero ulm dertobi123 ssuominen betelgeuse _reopen_nominations - confirmation 2e50 - patrick solar lu_zero ulm leio scarabeus ssuominen _reopen_nominations calchan dertobi123 betelgeuse dev-zero gentoofan23 peper - confirmation 3133 - betelgeuse calchan dertobi123 ssuominen solar lu_zero dev-zero ulm leio peper gentoofan23 patrick scarabeus - confirmation 3303 - calchan betelgeuse ssuominen ulm leio lu_zero solar dertobi123 _reopen_nominations peper scarabeus gentoofan23 dev-zero patrick - confirmation 338c - ulm dertobi123 calchan leio patrick solar lu_zero _reopen_nominations ssuominen scarabeus betelgeuse dev-zero peper gentoofan23 - confirmation 3ac6 - leio gentoofan23 scarabeus calchan ssuominen patrick betelgeuse dev-zero solar peper lu_zero dertobi123 ulm _reopen_nominations - confirmation 3e1f - dertobi123 dev-zero ulm solar betelgeuse lu_zero scarabeus patrick calchan leio ssuominen gentoofan23 peper - confirmation 3e2c - leio betelgeuse calchan solar dertobi123 lu_zero ssuominen ulm scarabeus patrick _reopen_nominations dev-zero gentoofan23 peper - confirmation 3f35 - leio betelgeuse calchan lu_zero solar patrick ssuominen gentoofan23 scarabeus peper ulm dertobi123 dev-zero - confirmation 0657 - dev-zero dertobi123 betelgeuse gentoofan23 ulm peper calchan scarabeus ssuominen _reopen_nominations lu_zero leio patrick solar - confirmation 460a - dev-zero betelgeuse scarabeus dertobi123 calchan ulm gentoofan23 lu_zero leio peper ssuominen solar patrick _reopen_nominations - confirmation 46ec - ssuominen leio gentoofan23 lu_zero betelgeuse solar ulm dev-zero scarabeus peper calchan dertobi123 _reopen_nominations patrick - confirmation 4e08 - lu_zero dev-zero leio ulm dertobi123 betelgeuse calchan solar ssuominen gentoofan23 peper patrick scarabeus _reopen_nominations - confirmation 514d - ulm gentoofan23 dertobi123 scarabeus betelgeuse calchan ssuominen leio peper lu_zero _reopen_nominations dev-zero patrick solar - confirmation 52f9 - leio betelgeuse dev-zero solar ssuominen lu_zero gentoofan23 ulm scarabeus patrick peper calchan dertobi123 - confirmation 53aa - dertobi123 betelgeuse ulm solar patrick lu_zero leio _reopen_nominations peper gentoofan23 ssuominen calchan scarabeus dev-zero - confirmation 08a7 - _reopen_nominations dev-zero betelgeuse calchan lu_zero leio solar ulm gentoofan23 peper patrick ssuominen dertobi123 scarabeus - confirmation 5da6 - solar lu_zero dev-zero dertobi123 ulm calchan leio ssuominen patrick betelgeuse scarabeus gentoofan23 peper - confirmation 5e53 -
[gentoo-dev] Manifesto archive
* "Jorge Manuel B. S. Vicetto" : > http://www.gentoo.org/proj/en/elections/council/2009/council-200906-nominees.xml Please archive the manifestos somewhere under the project space like it was done the last years. Looking back at the 2005 list of nominees, all external links are dead. Only the archived parts are still available. I can help if needed. Thanks
