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 tampak...@gentoo.org Content-Type: text/plain Posted: 2009-07-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/kdelibs-5 The Gentoo KDE Guide has been updated and now covers the two most serious issues affecting KDE users: 1) masking of the kdeprefix USE flag for KDE 4 users and 2) the upgrade of KDE 3 and koffice 1.6.3 due to stabilisation to KDE 3.5.10 and koffice 1.6.3_p20090204 for users of monolithic ebuilds. Please refer to the guide [0] to solve those issues. [0] 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 tampak...@gentoo.org: 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 tampak...@gentoo.org Translator: Christian Faulhammer fa...@gentoo.org Content-Type: text/plain Posted: 2009-07-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/kdelibs-5 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 -- 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: New eselect news item for kdeprefix
On Thursday 02 July 2009 11:27:34 Christian Faulhammer wrote: Hallo, Theo Chatzimichos tampak...@gentoo.org: 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 tampak...@gentoo.org Translator: Christian Faulhammer fa...@gentoo.org Content-Type: text/plain Posted: 2009-07-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/kdelibs-5 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 Luddso...@gentoo.org 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 subscribed directly to the gentoo-dev mailing list anymore outside of post-only.
[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. As for meeting times we can (that was
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
On Thu, Jul 2, 2009 at 7:54 AM, Tobias Scherbaumdertobi...@gentoo.org 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 they are held currently don't fit well with my work schedule. I'm all for going back to monthly meetings and
[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 neddyseag...@gentoo.org: 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 so...@gentoo.org 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 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
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 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
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 tampak...@gentoo.org: 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 tampak...@gentoo.org Translator: Christian Faulhammer fa...@gentoo.org Content-Type: text/plain Posted: 2009-07-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/kdelibs-5 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) tampak...@gentoo.org: +[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 URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL: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 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
[gentoo-portage-dev] layman: appending overlay list on cmdline
Hi, I'm assuming this is be the right place to discuss layman. If not, please redirect me and ignore the rest. I'm using layman-1.1.1 (not the most-recent). Its -o option appends additional overlays to the list found in layman.cfg. If an overlay appears in both lists, the one from cfg takes precedence. I'm thinking of the -o option as a means to override layman.cfg. Indeed on most applications I've come across, cmdline lets you override persistent configuration. In layman's case, however this is not so, and I'm wondering if that's intended, and if so, what is the reasoning for this. I'm able to workaround this issue by invoking layman with '-c /dev/null'. I'd prefer not to do so, though, as this hides layman.cfg entirely from the program, whereas I only want to override the overlay list. Thanks, Amit
[gentoo-portage-dev] prefix-portage-2.2.00.13734 with --nodeps merges in reverse order
Hi, seems prefix-portage as of r13734, when used with '--nodeps', does merge packages in reverse order than given on cmdline, but I don't believe this is a prefix issue... prefix-portage r13683 does merge in correct order. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-portage-dev] prefix-portage-2.2.00.13734 with --nodeps merges in reverse order
On 02-07-2009 15:31:16 +0200, Michael Haubenwallner wrote: Hi, seems prefix-portage as of r13734, when used with '--nodeps', does merge packages in reverse order than given on cmdline, but I don't believe this is a prefix issue... prefix-portage r13683 does merge in correct order. 13734 is after the _emerge split -- Fabian Groffen Gentoo on a different level
Re: [gentoo-portage-dev] prefix-portage-2.2.00.13734 with --nodeps merges in reverse order
Michael Haubenwallner wrote: Hi, seems prefix-portage as of r13734, when used with '--nodeps', does merge packages in reverse order than given on cmdline, but I don't believe this is a prefix issue... prefix-portage r13683 does merge in correct order. /haubi/ Thanks, fixed in r13757. -- Thanks, Zac
