Re: [gentoo-dev] Council meeting 19 April 2010
On 04/09/2010 05:51 PM, Dror Levin wrote: On Wed, Apr 7, 2010 at 21:05, Denis Dupeyron calc...@gentoo.org wrote: On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot yng...@gentoo.org wrote: So all I'm asking is to do your job and make decisions on issues that affect all of Gentoo. The issues I brought up are wider than a single individual project. And almost 100% of the time this needs to run through a GLEP, which is the case here. Then the council will do all the things you've pasted from GLEP 39 I thought the council was a body that should be capable of action, not merely one that gives a stamp of approval for stuff other people do. Was I wrong? It's capable of action if the members want to take it. Reading all your manifestos from the elections shows you all had things you wanted to do, things you wanted to change (git migration, forming a group of experts to discuss technical issues, QA propagation, just to name a few). Where did all that go to? If all the council is currently able to do is get everybody involved in bureaucracy (e.g. writing GLEPs for centralizing documentation instead of putting a page full of links) just so it could meet once a month to decide on bugzilla resolutions, then something is wrong. Let's see my manifesto: - EAPIs: council is not the blocker - Meetings: there will be a web application most likely in GSoC All council members not only volunteered for that position, but also had other people voting for them. Didn't you do that so you could have a larger influence? So you could make Gentoo better? How do you plan to achieve that if you just wait for other people to do it? I don't see why there is such strong opposition by your side to actually do something, after all, that's what you're there for. I said in my manifesto that Gentoo is not my first priority so you get what you vote for :) Ben raised some very painful issues which hurt Gentoo daily but are not being addressed for a long time. The way I see it, the council's job is to lead Gentoo, and that includes things that individual members may not find interesting. These are global issues which are under the council's responsibility. Gentoo's best interest should be in mind, not personal interests, and so the council should strive to achieve all those things so that Gentoo may benefit from it. That's what leadership is, and that's what your job is. Many of the points Ben raised are doable by any single developer who wants to do the work. Just show up with the code/patches. Let's take redesigning the homepage as an example. Our website has the same design since at least 2002, and to users it looks dead. This is seriously hurting Gentoo, and its inability to fix the situation has become a laughing stock. Clearly, Gentoo as a whole suffers and it's the council's responsibility to address this issue. Now, I'm not saying that council members should sit around all day playing with CSS, but this issue should be one of their top priorities. Maybe ask for users to help, reward a volunteer to do it with funds from the foundation, heck maybe even pay some company to do it, but just do something, even though you may not think dealing with this is interesting, but a response like if you want it then work on it and make it happen is unacceptable. Just petition the trustees to spend money on it. I guess Debian is dying too then: http://web.archive.org/web/20020124014701/http://www.debian.org/ Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting 19 April 2010
I was asked on #gentoo-council to respond to this post so I will. It should also be noted council members usually speak as individual members instead of for the council as a whole. On 04/07/2010 06:00 PM, Denis Dupeyron wrote: On Wed, Apr 7, 2010 at 8:23 AM, Ben de Groot yng...@gentoo.org wrote: 1. reconsider metadata changepolicies proposal == [...] Can council please decide to honor the wish from developers to implement this? The council will be glad to vote on a GLEP when ready. From GLEP 1, GLEPs are the primary mechanisms for proposing significant new features, for collecting community input on an issue, and for documenting the design decisions. So use them. Also, you might want to check the log and summary of the last meeting to find out why the council may end up voting no to such a GLEP. This doesn't exclude council members themselves from working on such a GLEP if they think it's needed. 2. website redesign === [...] Can council assure that a team will be assembled that can effectively tackle this issue? You want the council to aim their collective gun at volunteer developers and force them to assemble in a team and work on something they might not want to work on? In other words, if you want it then work on it and make it happen. This is and has always been the Gentoo way. Council can't assure it will happen, they can only encourage and work towards such a goal. 3. manpower and recruitment issues == Another recurring theme is the lack of manpower in certain areas, the recruitment bottleneck and the quizzes. There are some initiatives but more decisive leadership is needed. Can council decide to actively pursue solutions for these structural problems? The only way to solve this is to address these issues where they are. That means joining the recruiters team and helping them with that. Another thing you might want to do is properly mentor recruits. Because one reason recruiting takes so long, and thus why there is a backlog, is (to put is simply) that mentors suck at mentoring. As said Council is not needed. Recruiters as a project can handle improving it just fine. I think I have pinged gentoo-core quite a few times to try get new people in, would it make a difference if I pinged as a council representative instead of as the Recruiting lead? Good news is that I have two people in training nowadays. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting 19 April 2010
On Thu, Apr 8, 2010 at 5:02 AM, Brian Harring ferri...@gmail.com wrote: On Wed, Apr 07, 2010 at 11:05:34AM +0200, Ulrich Mueller wrote: Next monthly council meeting will be at 19 April 2010, 18:00 UTC in #gentoo-council. If you have any topics you want us to discuss or even vote about, simply followup to this message. Wrote it up as a glep- http://dev.gentoo.org/~ferringb/gleps/required_use.html Longer term, I'd like to see all EAPI related changed proposed as Glep's so the discussion and logic for a feature is properly documented, including alternatives and counter proposals to it. Basically the same thing Python does with their Python Enhancement Proposals (Peps, which is where Glep's came from). Thanks, ~harring
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 7, 2010 at 21:05, Denis Dupeyron calc...@gentoo.org wrote: On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot yng...@gentoo.org wrote: So all I'm asking is to do your job and make decisions on issues that affect all of Gentoo. The issues I brought up are wider than a single individual project. And almost 100% of the time this needs to run through a GLEP, which is the case here. Then the council will do all the things you've pasted from GLEP 39 I thought the council was a body that should be capable of action, not merely one that gives a stamp of approval for stuff other people do. Was I wrong? Reading all your manifestos from the elections shows you all had things you wanted to do, things you wanted to change (git migration, forming a group of experts to discuss technical issues, QA propagation, just to name a few). Where did all that go to? If all the council is currently able to do is get everybody involved in bureaucracy (e.g. writing GLEPs for centralizing documentation instead of putting a page full of links) just so it could meet once a month to decide on bugzilla resolutions, then something is wrong. All council members not only volunteered for that position, but also had other people voting for them. Didn't you do that so you could have a larger influence? So you could make Gentoo better? How do you plan to achieve that if you just wait for other people to do it? I don't see why there is such strong opposition by your side to actually do something, after all, that's what you're there for. As I've seen in the last few days, the common reaction to this is, Well, what do you want us to do? Force people to do stuff?. Why did you want to be a council member if you have no idea how to accomplish the things you wanted to do? How did you think you were going to achieve all those things written in your manifesto? Being in the council is a responsibility, and one which you took upon yourself willingly. All we're now requesting is that you all stand up to that responsibility and use your authority to make changes to how Gentoo work, not point fingers and ask rhetorical questions. Ben raised some very painful issues which hurt Gentoo daily but are not being addressed for a long time. The way I see it, the council's job is to lead Gentoo, and that includes things that individual members may not find interesting. These are global issues which are under the council's responsibility. Gentoo's best interest should be in mind, not personal interests, and so the council should strive to achieve all those things so that Gentoo may benefit from it. That's what leadership is, and that's what your job is. Let's take redesigning the homepage as an example. Our website has the same design since at least 2002, and to users it looks dead. This is seriously hurting Gentoo, and its inability to fix the situation has become a laughing stock. Clearly, Gentoo as a whole suffers and it's the council's responsibility to address this issue. Now, I'm not saying that council members should sit around all day playing with CSS, but this issue should be one of their top priorities. Maybe ask for users to help, reward a volunteer to do it with funds from the foundation, heck maybe even pay some company to do it, but just do something, even though you may not think dealing with this is interesting, but a response like if you want it then work on it and make it happen is unacceptable. Note that all that is said here is not pointed at any specific member of the council, but at the council as a whole. I did not intend to hurt anybody, but am genuinely concerned for Gentoo's well being. Dror Levin
Re: [gentoo-dev] Council meeting 19 April 2010
On 04/07/2010 12:05 PM, Ulrich Mueller wrote: Next monthly council meeting will be at 19 April 2010, 18:00 UTC in #gentoo-council. If you have any topics you want us to discuss or even vote about, simply followup to this message. Ulrich Two things already discussed on this mailing list but I don't see a definite consensus so taking for a spin through council. 1. Keywording bugs with a single arch: http://archives.gentoo.org/gentoo-dev/msg_3f8603c9bc97b7b0bcf59782848c2650.xml Options to vote in order: After the maintainer has accepted that a package is good for stable (by being the assignee or reporter). a) The preferred way is to assign the bug to the single arch in question b) The bug can be either assigned to the arch or the arch can be CCed and the maintainer is the assignee c) The maintainer is the assignee and the arch is CCed 2. Bugzilla resolutions http://archives.gentoo.org/gentoo-dev/msg_9cb8abe1d6608e4fb4e525833eea897b.xml Vote on: - Remove LATER and REMIND from resolutions - Add LATER as a KEYWORD - Add resolution OBSOLETE Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 07, 2010 at 11:05:34AM +0200, Ulrich Mueller wrote: Next monthly council meeting will be at 19 April 2010, 18:00 UTC in #gentoo-council. If you have any topics you want us to discuss or even vote about, simply followup to this message. VALID_USE- http://archives.gentoo.org/gentoo-dev/msg_b0e868626019f497eba47194c34e5421.xml Historically, no PMS change has been glep'ified, but if the council wants PMS changes to start being glep'd I'd be willing to guinea pig this one- earliest I'd have the glep out the door is saturday also. Few additional notes to the proposal- 1) few has offered up his time patch wise. 2) if he backs out, I'll throw in a gurantee of having it done prior to the next council meeting (realistically I can do it faster, I just have other fish I'd like to be frying). 3) dev feedback generally has been positive, exempting ciaran's views on it- please review those (if you'd like a summation I can provide one). 4) if there are questions re: use cycle breaking or other bits, feel free to ask prior please- council meeting times unfortunately right now intersect badly with my paying work so it's hard to be online to answer questions during the meeting (that said per the norm I'll try). 5) final reminder- part of the impetus of this is that if this is punted till EAPI5, it forces pkg_pretend as the interim use constraint checking- this has some nasty implications on the use cycle breaking intentions since it would require everyone to upgrade their ebuilds to EAPI5 if they've got use state constraints. Basically screws things up a bit and requires a potentially pointless EAPI bump for the sake of trying to knock EAPI4 out the door now (regardless of how long it takes to stable portage for it) rather than adding a few weeks in. Thanks- ~harring pgppE5c5febGm.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting 19 April 2010
On Thu, 8 Apr 2010 05:02:25 -0700 Brian Harring ferri...@gmail.com wrote: 4) if there are questions re: use cycle breaking or other bits, feel free to ask prior please- council meeting times unfortunately right now intersect badly with my paying work so it's hard to be online to answer questions during the meeting (that said per the norm I'll try). Please detail your cycle breaking algorithm that works in such a way that it's guaranteed not to toggle flags that will break a system, but that does not require any changes to be made to ebuilds etc telling the package manager what those flags are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting 19 April 2010
On 04/08/10 15:29, Ciaran McCreesh wrote: On Thu, 8 Apr 2010 05:02:25 -0700 Brian Harring ferri...@gmail.com wrote: 4) if there are questions re: use cycle breaking or other bits, feel free to ask prior please- council meeting times unfortunately right now intersect badly with my paying work so it's hard to be online to answer questions during the meeting (that said per the norm I'll try). Please detail your cycle breaking algorithm that works in such a way that it's guaranteed not to toggle flags that will break a system, but that does not require any changes to be made to ebuilds etc telling the package manager what those flags are. That would violate the Entscheidungsproblem. But why would you make the cycle breaking depend on an oracle? Once we have the method in place we can find the two special cases and think of ways to fix them. Abandoning the idea as a whole just because there may be a corner case that isn't as easy appears quite silly to me. Brian's proposal is the only one I've seen that is deterministic and sane, so I think we should figure out if we can improve it instead of giving up at the first bump in the road.
Re: [gentoo-dev] Council meeting 19 April 2010
On Thu, 08 Apr 2010 16:08:57 +0200 Patrick Lauer patr...@gentoo.org wrote: Please detail your cycle breaking algorithm that works in such a way that it's guaranteed not to toggle flags that will break a system, but that does not require any changes to be made to ebuilds etc telling the package manager what those flags are. That would violate the Entscheidungsproblem. But why would you make the cycle breaking depend on an oracle? Once we have the method in place we can find the two special cases and think of ways to fix them. The problem is, the special cases where it goes horribly wrong aren't rare. As soon as you start looking for cycles, you find flags like 'build', 'bootstrap' and 'acl'. Abandoning the idea as a whole just because there may be a corner case that isn't as easy appears quite silly to me. I'm not after abandoning the idea. I'm after doing it properly, and doing it properly starts by handling the problematic cases rather than pretending they don't exist. We've already seen repeatedly what goes wrong when you start with the assumption it'll probably work and then pile on special exceptions every time someone gets screwed over by something you didn't think of. Why don't we go with we'll only do it for things where we know it'll work instead this time? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Council meeting 19 April 2010
Next monthly council meeting will be at 19 April 2010, 18:00 UTC in #gentoo-council. If you have any topics you want us to discuss or even vote about, simply followup to this message. Ulrich
Re: [gentoo-dev] Council meeting 19 April 2010
On 7 April 2010 11:05, Ulrich Mueller u...@gentoo.org wrote: Next monthly council meeting will be at 19 April 2010, 18:00 UTC in #gentoo-council. If you have any topics you want us to discuss or even vote about, simply followup to this message. 1. reconsider metadata changepolicies proposal == The fact is there is a spectrum from ebuild maintainers' side about how desirable it is for non-maintainers to step in, ranging from don't touch this ever to please do touch this. There may be very valid reasons for this (in some cases intimate knowledge of the package may be required, for example, or on the opposite side someone might not have the time or motivation to do much about that specific package) that have little to do with territoriality. While there is a need for basic policies to be made more explicit, it is also obvious that there is no good one policy fits all approach. The metadata changepolicies proposal beautifully captured this spectrum and has wide support from developers. While this information isn't directly useful to users, the argument that it would bloat the file for no good reason is false, because there are very good reasons: to facilitate cooperation between devs as well as a better overall quality of the tree. This benefits users, so I'm quite sure they don't mind we use metadata.xml for that. Can council please decide to honor the wish from developers to implement this? 2. website redesign === This is a recurring theme in discussions about Gentoo's shortcomings. While there have been some minor improvements in recent years, the resign project itself failed miserably, but is still as needed as ever. We should have one elegant design that will be consistently applied to all official Gentoo websites. A look at znurt.org should convince anyone of what can be done. Also our frontpage needs to be more focussed on communicating the things users and new visitors are looking for. Can council assure that a team will be assembled that can effectively tackle this issue? 3. manpower and recruitment issues == Another recurring theme is the lack of manpower in certain areas, the recruitment bottleneck and the quizzes. There are some initiatives but more decisive leadership is needed. Can council decide to actively pursue solutions for these structural problems? 4. devrel ineffectiveness = What can be done to assure that conflicts are addressed in a timely and effective manner by DevRel? What can be done to remove poisonous people from Gentoo and its communication channels more decisively and effectively? The fact that many people indicate they do not want to become a developer for this exact reason, should be cause for concern. Can council make a statement that they share these concerns and are actively looking to address them? 5. centralize developer documentation = Currently the documentation a developer needs to effectively write ebuilds and maintain packages is scattered all over the place. We have the (incomplete) devmanual, the developer handbook, various guides and policies in individual projects, the GLEPs, council decisions, and a legacy of unwritten rules or poorly documented policies. It would be very helpful to centralize all that information, and work on properly documenting our policies. At the very least there should be one page that funtions as a portal to all existing relevant information. Even better would be to have as much of that relevant information as possible consolidated into one place, so that everyone knows where to go to look that up. Can council decide to see this implemented? Thanks, -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 7, 2010 at 8:23 AM, Ben de Groot yng...@gentoo.org wrote: 1. reconsider metadata changepolicies proposal == [...] Can council please decide to honor the wish from developers to implement this? The council will be glad to vote on a GLEP when ready. From GLEP 1, GLEPs are the primary mechanisms for proposing significant new features, for collecting community input on an issue, and for documenting the design decisions. So use them. Also, you might want to check the log and summary of the last meeting to find out why the council may end up voting no to such a GLEP. 2. website redesign === [...] Can council assure that a team will be assembled that can effectively tackle this issue? You want the council to aim their collective gun at volunteer developers and force them to assemble in a team and work on something they might not want to work on? In other words, if you want it then work on it and make it happen. This is and has always been the Gentoo way. 3. manpower and recruitment issues == Another recurring theme is the lack of manpower in certain areas, the recruitment bottleneck and the quizzes. There are some initiatives but more decisive leadership is needed. Can council decide to actively pursue solutions for these structural problems? The only way to solve this is to address these issues where they are. That means joining the recruiters team and helping them with that. Another thing you might want to do is properly mentor recruits. Because one reason recruiting takes so long, and thus why there is a backlog, is (to put is simply) that mentors suck at mentoring. 4. devrel ineffectiveness = In case you haven't noticed there was a recent change of devrel lead. This means it is urgent to wait for the results of the change. Because you never know, it might just be that the change of lead was intended to solve such things at a perceived devrel ineffectiveness. 5. centralize developer documentation = This is an interesting idea which I believe I have seen discussed on irc at some point. Feel free to work on a GLEP to address that. Before we go any further, let me make the following PA announcement: 1 - If you want to improve a project or subproject the best (and often only) thing to do is to join it. 2 - The council isn't a super-nanny metaproject with enough magical powers to solve each and every of your oh-so-annoying problems. We do have magic wands but you don't want to see them. Denis.
Re: [gentoo-dev] Council meeting 19 April 2010
On 7 April 2010 17:00, Denis Dupeyron calc...@gentoo.org wrote: Before we go any further, let me make the following PA announcement: 1 - If you want to improve a project or subproject the best (and often only) thing to do is to join it. 2 - The council isn't a super-nanny metaproject with enough magical powers to solve each and every of your oh-so-annoying problems. We do have magic wands but you don't want to see them. Gentoo Council project page http://www.gentoo.org/proj/en/council/: 1. Project Description The elected Gentoo Council decides on global issues and policies that affect multiple projects in Gentoo. GLEP 39 also says Global issues will be decided by an elected Gentoo council. So all I'm asking is to do your job and make decisions on issues that affect all of Gentoo. The issues I brought up are wider than a single individual project. Thanks, -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot yng...@gentoo.org wrote: So all I'm asking is to do your job and make decisions on issues that affect all of Gentoo. The issues I brought up are wider than a single individual project. And almost 100% of the time this needs to run through a GLEP, which is the case here. Then the council will do all the things you've pasted from GLEP 39. Denis.
Re: [gentoo-dev] Council meeting 19 April 2010
On 7 April 2010 20:05, Denis Dupeyron calc...@gentoo.org wrote: On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot yng...@gentoo.org wrote: So all I'm asking is to do your job and make decisions on issues that affect all of Gentoo. The issues I brought up are wider than a single individual project. And almost 100% of the time this needs to run through a GLEP Where is that policy documented? -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
Re: [gentoo-dev] Council meeting 19 April 2010
Hi Ben, On 7 April 2010 22:44, Ben de Groot yng...@gentoo.org wrote: [...] 1. Project Description The elected Gentoo Council decides on global issues and policies that affect multiple projects in Gentoo. GLEP 39 also says Global issues will be decided by an elected Gentoo council. So all I'm asking is to do your job and make decisions on issues that affect all of Gentoo. The issues I brought up are wider than a single individual project. I don't understand what you expect the council to do in some of these cases. Taking the website redesign or consolidation of documentation as examples, do you want them to: a) Decide that this should be done? b) Call for volunteers? (they obviously cannot force anyone to do it) c) Do it themselves? d) What you probably mean that I fail to see Regards, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Council meeting 19 April 2010
On 7 April 2010 23:02, Arun Raghavan ford_pref...@gentoo.org wrote: I don't understand what you expect the council to do in some of these cases. Taking the website redesign or consolidation of documentation as examples, do you want them to: a) Decide that this should be done? b) Call for volunteers? (they obviously cannot force anyone to do it) c) Do it themselves? d) What you probably mean that I fail to see Mostly, I want them to show leadership. I want the council to affirm that these are important goals, to raise awareness of where our weak areas are, and what needs to be done to improve things. And yes, I want the council to call for volunteers, and where necessary to recruit people who are able to help. -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
Re: [gentoo-dev] Council meeting 19 April 2010
On 04/07/2010 11:00 AM, Denis Dupeyron wrote: 5. centralize developer documentation = This is an interesting idea which I believe I have seen discussed on irc at some point. Feel free to work on a GLEP to address that. To be honest, this doesn't even need a GLEP so much as a website or something. If somebody consolidated all this stuff into a reasonable format, I bet that half the devs would pitch in and make their contributions. The only thing that might warrant a GLEP is a policy decision that all development policies must be documented or linked from that site to be binding, or something like that. I don't think that for the council to make a policy decision that there needs to be a GLEP. Sure, it is the best way to make big changes, or changes that require some level of formality. However, the council can still show leadership in affirming their agreement on issues even if it isn't a formal affair. I'm sure every other town government in the Western World has taken a vote in support of their troops or something like that without going through the official lawmaking process and all that - it is just a gesture. I don't have the time to create such a website although I would agree that it is sorely needed. Hence, I will try to be careful in throwing around criticism - it is much easier to bring problems to the table than solutions... Rich
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 7, 2010 at 4:30 PM, Richard Freeman ri...@gentoo.org wrote: Sure, it is the best way to make big changes Why then use anything else than the best tool when you can use the best tool? I didn't say that he should work on a GLEP though, but that he should feel free to do so, which is different. That meant that if he thought there was a point to it, was willing to do it, etc... Just a note about this. The council could for example make the decision to centralize all the documentation in a wiki, force the doc team to use tools they haven't chosen or even take that responsibility out of their hands. Basically step on their toes. Nice way to show respect for all the hard work they've done for years. Or this could be discussed on the relevant mailing-list(s) by everybody who feels concerned, input from the whole community (including the doc team) could be gathered, council members could chime in (I usually do), dissenting opinions could be documented, a consensus could be reached and then design decisions could be documented. See GLEP 1 for more information on that work flow. Gentoo has been driven by consensus since Daniel left, for better or for worse. You might not like this way to work, but that's OK. I didn't say I thought it was optimal either. All I know is I'm going by the book, but it allows me to rewrite some pages when I don't like them. The good news is that during the last meeting the council has decided to initiate an overhaul of GLEP 39. I'm still gathering material from various sources to start the discussions open to all users and developers. At that point you'll have the opportunity to suggest anything you think may improve the way the council works. However, the council can still show leadership in affirming their agreement on issues even if it isn't a formal affair. We don't need a meeting for that. We can show leadership on the mailing-lists everyday. What do you think I'm doing right now for example? And by the way I don't believe that issuing a statement along the lines of Yep, we agree shows any leadership at all. Additionally, leadership is not about doing your job. You may want to peruse the council meeting logs and summaries for examples of leadership, and vote for real leaders next time if you think we suck. I'm sure every other town government in the Western World has taken a vote in support of their troops or something like that without going through the official lawmaking process and all that - it is just a gesture. We've been down that road many times before, but let me say it again: Gentoo is not a government, so any comparison to one is pointless. I don't have the time to create such a website although I would agree that it is sorely needed. Hence, I will try to be careful in throwing around criticism - it is much easier to bring problems to the table than solutions... Wise words, although constructive criticism is always welcome. In order to be really constructive however, criticism needs among other things to take into account goals, resources, history and rules. Denis.
