Ryan Phillips wrote: [Fri Apr 28 2006, 12:14:53PM CDT] > __Problem: Developer Growth__
I've seen suggestions before that one of the things limiting Gentoo's growth right now is the hurdles involved in becoming a dev. I don't really think the dev quiz is all that onerous, but I'm willing to listen to arguments there. > __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. Does it? How does having a stable and unstable branch differ from having stable and unstable keywords? On older idea was peer review. Any dev could commit to the not-yet-ready-for-primetime branch, but those commits would have to be peer-reviewed before being added to the user tree. It's a great idea, except (a) nobody wants to do the reviewing job and (b) it would be a full time job. > > CVS doesn't do branching nor tags very well... > > __Problem: CVS__ > > CVS is one of the worst application ever created. The portage tree > needs to move to subversion. A lot of the problems within the project > would be solved by using a better SCM system. The previous problems > regarding the Live Tree and Developer Growth would be solved, IMHO, by > just switching. Branches Work. Tags Work. Reverts work. Moves > work. I don't see any reason not to use it. It just plain works. Have you tried using SVN for the portage tree? I don't know if anybody has recently, but in the past when people tried there were two significant problems: SVN requires at least 2x the tree size for storage on the local machine, and checkouts take something akin to an order of magnitude longer than CVS. The former is annoying, but liveable, but the latter is a deal-breaker. > __Problem: QA Policies__ > > http://article.gmane.org/gmane.linux.gentoo.devel/37544 > > It seems that the QA Policies are a product of a Live Tree, and going > partially non-live would solve the problems listed. QA does help with fixing broken packages, but in my view their most important mandate is to help devs fix bad habits in writing ebuilds. Repoman and lists of best-practices help in this regard, but the QA team tends to be much better at explaining why something is a bad idea. > Conflict resolution should not be a subproject. It should *not* exist > at all. 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. It's worth noting that with the exception of kicking people out of Gentoo, much of our practices do, in fact, work just this way, although without the formality of a vote. That's what happens when somebody posts to -dev with an idea, it gets kicked around, and some sort of consensus is either reached, or it isn't. In the latter case it's not ready for prime time, most likely. > __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. > A new idea proposal should be mailed to a mailinglist (-innovation?) > with details of timeline to completion, impact, and who is doing the > implementation. If it sounds like a good one, then there is a vote > and things proceed. I like progress. It's not quite true that the Council votes on GLEPs, but that's not really germane to your overall point. Despite being the person who created GLEPs in the first place, I'm quite willing to admit that the concept doesn't seem to work as well as I had hoped. I'm not sure that your idea would work better, however, since the only real difference would be in the approval process. Presumably you would still expect to see the sort of iterative refinement of proposals/innovations on -dev that we have now, and I believe that part of the project works reasonably well. The problem, in my view, is that eventually the proposal is approved, and the folks involved are told, in essence, "great idea, go to it", and then it stalls because implementation is _hard_, in general. As an aside, the large number of moribund GLEPs was always an intended outcome. They represent ideas that never got any traction, and thus went nowhere. By having them publicly available we help reduce the number of "hey, what about this bad idea" posts to -dev. > __Problem: Voting__ > > Gentoo has over 200 developers. People are generally against the > voting idea, but I'm not sure why. I think voting should work like > this: if 30 developers (or someother specified number) vote yes to an > idea then that idea passes. It doesn't require everyone to vote, be > at home, be on the computer, and not be on vacation. *Shrug* I don't really have a problem w/ trying some sort of voting. At the same time, it's not clear to me that the outcome will be all that different from what we have now, with the possible exception that debate might get cut off sooner when some sort of threshold vote is reached. > What is interesting is that Source Mage Linux has already voted on a > proposal similar to mine[2]. I truly think that making some changes > in the "gentoo way" would benefit us and make gentoo a truly better > distribution. I tend to agree that our current system is suboptimal, but I'm not quite convinced that the proposed changes would actually improve things. There's a lot here, but perhaps we can streamline things a tad. What's the major problem that you're looking to solve? Is it the shortage of developers, or the lack of progress in a certain area, or the (perceived?) difficulty in getting "foo" accomplished? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
pgpJ8lPd6LqVq.pgp
Description: PGP signature
