From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FZbdr-0007oa-JF for garchives@archives.gentoo.org; Fri, 28 Apr 2006 22:40:52 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k3SMeF4b026554; Fri, 28 Apr 2006 22:40:15 GMT Received: from buggy.blubb.ch (cable-static-87-245-102-53.shinternet.ch [87.245.102.53]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k3SMaes8013179 for ; Fri, 28 Apr 2006 22:36:40 GMT Received: from chief ([192.168.10.2]) by buggy.blubb.ch with esmtp (Exim 4.54) id 1FZbW4-0002q2-W5; Sat, 29 Apr 2006 00:32:49 +0200 Message-ID: <445298F5.7070407@gentoo.org> Date: Sat, 29 Apr 2006 00:36:37 +0200 From: Simon Stelling User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051023) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org CC: rphillips@gentoo.org Subject: Re: [gentoo-dev] Gentoo: State of the Union References: <20060428171453.GB62035@watcher.kimaker.com> In-Reply-To: <20060428171453.GB62035@watcher.kimaker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: f65da0b8-d9e7-4806-b755-f4aedd37b5fc X-Archives-Hash: 9718978adc5f623796b4920ba25cb52d Hi Ryan, Ryan Phillips wrote: > I believe the way Gentoo is doing things is broken. There I have said it. The > entire project has reached a level of being too political and trying to solve > certain problems in the wrong way. I think it actually works quite well. Yes, there is space for improvement, like always, but the situation is at least not bad. > __Problem: Developer Growth__ > > I find that developer growth as being a problem. Adding a developer to gentoo > should be as easy as 1. has the user contributed numerous (~5+) patches that > helps the project move forward. If yes, then commit access should be given. > Adding a developer is usually quite a chore. There are numerous reasons why > this is a problem: having a live tree, taking a test, and not defining within > policy when a person could possibly get commit access. I can only speak for me here, but the quiz wasn't a barrier at all to me. Instead, it was an interesting way to make sure that I get familiar with all the stuff I have to. I found it a much better way to answer questions about a topic where you have to find the answers than just reading through tons of docs, not knowing whether something is important to you or completely unrelated. Besides that, I think the tree is far too worthy to give it away after 5 patches. Just because I fixed a bunch of compiling errors, that doesn't mean I know how to fix ebuilds. Just because I wrote a few ebuilds, that doesn't mean I understand how eclasses work, which ones to use where and what profile.bashrc is good for. I've seen ebuilds from people who have written quite a bunch of ebuilds and were really interested in understanding how they work, but the work they produced just was awful and hurt my eyes. I don't mean that the mean way, I don't expect anything else, and I was just the same. However, the mentoring process and the quiz have helped me a lot to understand not-so-obvious problems. > All these reasons leave the project stagnant and lacking developers. I wouldn't say so. Just about two weeks or so ago, the recruiters had to defer new requests, because they couldn't deal with them in a timely fashion. You can now tell me that this makes it even worse, but I just see that as the proove of the fact that people are interested in helping us and ready to take the quiz and all the "hassle" involved with becoming a dev. Another good reason to keep the current process is the fact that a lot of people become dev and vanish a week after their mentoring period expired. These people would better contribute to the project in a more distant way IMHO, because it takes up a fair amount of time to clean up these accounts afterwards. If you don't beleave me, ask kloeri. ;) > Perhaps its because of a live tree... That's surely a big factor. > __Problem: Live Tree__ > > Having a live tree requires people to be perfect. People are not perfect and > requiring it is ridiculous. I love having commits in my local tree within the > hour, but having a stable and unstable branch makes a lot of sense. It doesn't require people to be perfect. It requires people to think before commiting. If it really required us to be perfect, we wouldn't exist in the first place, would we? Having a stable and unstable branch doesn't have many advantages over stable and unstable keywords IMHO, but requires a HUUUGE effort to keep them in sync. It would make things more complicated than necessary. You say we're lacking developers. Do you really want to spend [insert random big number here] of these much-needed developer hours to merging an old with a new tree? > __Problem: CVS__ I would like to see us using svn instead of CVS too, but I think that's just a technical detail, not really fitting here. > __Problem: QA Policies__ > Everyone here is on the same team. There will be some breakages in the tree > and those can be dealt with. Like Seemant [1] said, herds are just groups of > like *packages*. The QA Policy is wrong when it says cross-team assistance; we > are all on the *same* team. The tree should naturally work. If it doesn't > then that is a bug for all of us. This sounds romantic. However, Gentoo to me isn't 300 people who are all my friends, all working on a common goal. Gentoo, to me, is a bunch of very nice people that share a goal with me, some big mailing lists with flames every now and then and a big mass of people whose work I use and appreciate but who I don't have a f*cking clue about. I don't know what they are like, they work on other things than I do. But that's not a problem at all. > Conflict resolution should not be a subproject. It should *not* exist at all. You mean conflicts or conflict solution shouldn't exist at all? If the former, that's unrealistic. If the latter, why not? > Rules need to be in place to avoid conflict. Having some sort of voting > structure for all the developers (this doesn't mean requiring everyone to vote) > and not just the council or devrel makes a lot of sense for most things. If I > don't like how someone is acting within the project there should be a vote and > then see if that person is kicked out. No trial, no anything besides a vote. > And if I lose I have to deal with it. Either stay with the project, or find > something else. This solution just works. Do you really think just because 60% of the voting devs agreed on something the other 40% will like it suddenly? Conflicts cannot be avoided, other than shooting down all people which don't share your point of view. > Gentoo should be a fun environment. The previous paragraph should be taken as > a last resort. Gentoo is fun to me. > __Problem: GLEPs__ > > I dislike GLEPs. Usually they sit on the website for a long long time not > doing anything. My vote (+1) is get rid of gleps and do everything by email > and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. > It stifles things from getting done, and there is no ownership of who is going > to implement the idea. I dislike them too. However, you're not addressing the issue IMHO. The problem is not that the council votes on them. The problem is much more that they are proposed to the whole dev community. Yes, you read right. It's mostly a good thing, but it is also a show stopper. I once wrote up a GLEP, sent it to the dev ml. Some people liked it, others wanted this or that changed. I re-submitted it, and they criticised this and that (which is a good thing!). So I fixed all the stuff they pointed out. In the end, I had a GLEP. But what I documented was not the idea I wanted to implement. So I lost interest. The GLEP got approved, but it's still not implemented. I don't know if anybody is working on it, I wont, because it's no longer what I once wanted to push forward. I would like it much more, if the people who are not affected by the GLEP wouldn't read it at all anyway. Whenever something is discussed I'm not involved in or affected by at all, I try to keep my mouth shut. I just trust the guys who submitted it to do their job the right way. And IMHO, this is exactly the point. Trust the others to do their job seriously and well. We don't need a whole dev community voting on an idea. Having everybody vote instead of a 7-headed council won't reduce politicalness. And that was what all your mail was about, in the end. > __Problem: Voting__ Heh, really don't need to comment on that one anymore. ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list