Grant Goodyear <[EMAIL PROTECTED]> said: > 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?
The first thing that we should acomplish is a different SCM system for the portage tree. This should be our #1 priority. This change would give us more freedom and fix some of the problems I proposed. SCMs: git - terrible with lots of tiny little files darcs - haskel shouldn't be a dependency mercurial - haven't tried it w/ the tree, has anyone? svn - seems like the best candidate for now. 2x drive space isn't a lot. we don't do entire checkouts very often. To reiterate, changing SCMs would allow us to work better. I have not heard of a proposed change, a date to change, etc. I strongly urge that we get something rolling. -ryan
pgpA5lOk14UxX.pgp
Description: PGP signature
