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 1FZZn4-00073Y-6I for garchives@archives.gentoo.org; Fri, 28 Apr 2006 20:42:14 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k3SKe0T0007898; Fri, 28 Apr 2006 20:40:00 GMT Received: from watcher.kimaker.com (c-67-169-29-182.hsd1.ca.comcast.net [67.169.29.182]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k3SKZXlu031703 for ; Fri, 28 Apr 2006 20:35:33 GMT Received: by watcher.kimaker.com (Postfix, from userid 1002) id 4082075858D; Fri, 28 Apr 2006 13:35:33 -0700 (PDT) Date: Fri, 28 Apr 2006 13:35:33 -0700 From: Ryan Phillips To: gentoo-dev@lists.gentoo.org, Ryan Phillips Subject: Re: [gentoo-dev] Gentoo: State of the Union Message-ID: <20060428203533.GC63263@watcher.kimaker.com> Mail-Followup-To: Ryan Phillips , gentoo-dev@lists.gentoo.org References: <20060428171453.GB62035@watcher.kimaker.com> <20060428185501.GA22506@dst.grantgoodyear.org> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline In-Reply-To: <20060428185501.GA22506@dst.grantgoodyear.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: 27acba56-44fc-4d17-97cf-cfcff86a0ac6 X-Archives-Hash: e9dadb93443d3cc336e32f1b03066566 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Grant Goodyear said: > Ryan Phillips wrote: [Fri Apr 28 2006, 12:14:53PM CDT] > > __Problem: Developer Growth__ >=20 > 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. >=20 > > __Problem: Live Tree__ > >=20 > > 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. =20 >=20 > Does it? How does having a stable and unstable branch differ from > having stable and unstable keywords? >=20 > 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. >=20 > >=20 > > CVS doesn't do branching nor tags very well...=20 > >=20 > > __Problem: CVS__ > >=20 > > 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. >=20 > 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. >=20 > > __Problem: QA Policies__=20 > >=20 > > http://article.gmane.org/gmane.linux.gentoo.devel/37544 > >=20 > > It seems that the QA Policies are a product of a Live Tree, and going > > partially non-live would solve the problems listed.=20 >=20 > 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. >=20 > > 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. >=20 > 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. >=20 > > __Problem: GLEPs__ > >=20 > > 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. >=20 > > 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. >=20 > 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. >=20 > 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. >=20 > > __Problem: Voting__ > >=20 > > 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. >=20 > *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. >=20 > > 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. >=20 > I tend to agree that our current system is suboptimal, but I'm not quite > convinced that the proposed changes would actually improve things. >=20 > 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 --/e2eDi0V/xtL+Mc8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEUnyU6cLeDQrpxL8RAleNAJ4l3M7+Vj6AJCTtE6+VW2koBldShACfcO3w FVvb5PlxxTNS35/32AB21Ms= =TnSw -----END PGP SIGNATURE----- --/e2eDi0V/xtL+Mc8-- -- gentoo-dev@gentoo.org mailing list