Gentoo Archives: gentoo-dev

From: Grant Goodyear <g2boojum@g.o>
To: gentoo-dev@l.g.o
Cc: Ryan Phillips <rphillips@g.o>
Subject: Re: [gentoo-dev] Gentoo: State of the Union
Date: Fri, 28 Apr 2006 18:57:49
In Reply to: [gentoo-dev] Gentoo: State of the Union by Ryan Phillips
1 Ryan Phillips wrote: [Fri Apr 28 2006, 12:14:53PM CDT]
2 > __Problem: Developer Growth__
4 I've seen suggestions before that one of the things limiting Gentoo's
5 growth right now is the hurdles involved in becoming a dev. I don't
6 really think the dev quiz is all that onerous, but I'm willing to listen
7 to arguments there.
9 > __Problem: Live Tree__
10 >
11 > Having a live tree requires people to be perfect. People are not
12 > perfect and requiring it is ridiculous. I love having commits in my
13 > local tree within the hour, but having a stable and unstable branch
14 > makes a lot of sense.
16 Does it? How does having a stable and unstable branch differ from
17 having stable and unstable keywords?
19 On older idea was peer review. Any dev could commit to the
20 not-yet-ready-for-primetime branch, but those commits would have to be
21 peer-reviewed before being added to the user tree. It's a great idea,
22 except (a) nobody wants to do the reviewing job and (b) it would be a
23 full time job.
25 >
26 > CVS doesn't do branching nor tags very well...
27 >
28 > __Problem: CVS__
29 >
30 > CVS is one of the worst application ever created. The portage tree
31 > needs to move to subversion. A lot of the problems within the project
32 > would be solved by using a better SCM system. The previous problems
33 > regarding the Live Tree and Developer Growth would be solved, IMHO, by
34 > just switching. Branches Work. Tags Work. Reverts work. Moves
35 > work. I don't see any reason not to use it. It just plain works.
37 Have you tried using SVN for the portage tree? I don't know if anybody
38 has recently, but in the past when people tried there were two
39 significant problems: SVN requires at least 2x the tree size for storage
40 on the local machine, and checkouts take something akin to an order of
41 magnitude longer than CVS. The former is annoying, but liveable, but
42 the latter is a deal-breaker.
44 > __Problem: QA Policies__
45 >
46 >
47 >
48 > It seems that the QA Policies are a product of a Live Tree, and going
49 > partially non-live would solve the problems listed.
51 QA does help with fixing broken packages, but in my view their most
52 important mandate is to help devs fix bad habits in writing ebuilds.
53 Repoman and lists of best-practices help in this regard, but the QA team
54 tends to be much better at explaining why something is a bad idea.
56 > Conflict resolution should not be a subproject. It should *not* exist
57 > at all. Rules need to be in place to avoid conflict. Having some
58 > sort of voting structure for all the developers (this doesn't mean
59 > requiring everyone to vote) and not just the council or devrel makes a
60 > lot of sense for most things. If I don't like how someone is acting
61 > within the project there should be a vote and then see if that person
62 > is kicked out. No trial, no anything besides a vote. And if I lose I
63 > have to deal with it. Either stay with the project, or find something
64 > else. This solution just works.
66 It's worth noting that with the exception of kicking people out of
67 Gentoo, much of our practices do, in fact, work just this way, although
68 without the formality of a vote. That's what happens when somebody
69 posts to -dev with an idea, it gets kicked around, and some sort of
70 consensus is either reached, or it isn't. In the latter case it's not
71 ready for prime time, most likely.
73 > __Problem: GLEPs__
74 >
75 > I dislike GLEPs. Usually they sit on the website for a long long time
76 > not doing anything. My vote (+1) is get rid of gleps and do
77 > everything by email and a vote by the developers. AFAIK, the board
78 > votes on the GLEPs. Bad Idea. It stifles things from getting done,
79 > and there is no ownership of who is going to implement the idea.
81 > A new idea proposal should be mailed to a mailinglist (-innovation?)
82 > with details of timeline to completion, impact, and who is doing the
83 > implementation. If it sounds like a good one, then there is a vote
84 > and things proceed. I like progress.
86 It's not quite true that the Council votes on GLEPs, but that's not
87 really germane to your overall point. Despite being the person who
88 created GLEPs in the first place, I'm quite willing to admit that the
89 concept doesn't seem to work as well as I had hoped. I'm not sure that
90 your idea would work better, however, since the only real difference
91 would be in the approval process. Presumably you would still expect to
92 see the sort of iterative refinement of proposals/innovations on -dev
93 that we have now, and I believe that part of the project works
94 reasonably well. The problem, in my view, is that eventually the
95 proposal is approved, and the folks involved are told, in essence,
96 "great idea, go to it", and then it stalls because implementation is
97 _hard_, in general.
99 As an aside, the large number of moribund GLEPs was always an intended
100 outcome. They represent ideas that never got any traction, and thus
101 went nowhere. By having them publicly available we help reduce the
102 number of "hey, what about this bad idea" posts to -dev.
104 > __Problem: Voting__
105 >
106 > Gentoo has over 200 developers. People are generally against the
107 > voting idea, but I'm not sure why. I think voting should work like
108 > this: if 30 developers (or someother specified number) vote yes to an
109 > idea then that idea passes. It doesn't require everyone to vote, be
110 > at home, be on the computer, and not be on vacation.
112 *Shrug* I don't really have a problem w/ trying some sort of voting.
113 At the same time, it's not clear to me that the outcome will be all that
114 different from what we have now, with the possible exception that debate
115 might get cut off sooner when some sort of threshold vote is reached.
117 > What is interesting is that Source Mage Linux has already voted on a
118 > proposal similar to mine[2]. I truly think that making some changes
119 > in the "gentoo way" would benefit us and make gentoo a truly better
120 > distribution.
122 I tend to agree that our current system is suboptimal, but I'm not quite
123 convinced that the proposed changes would actually improve things.
125 There's a lot here, but perhaps we can streamline things a tad. What's
126 the major problem that you're looking to solve? Is it the shortage of
127 developers, or the lack of progress in a certain area, or the
128 (perceived?) difficulty in getting "foo" accomplished?
130 -g2boojum-
131 --
132 Grant Goodyear
133 Gentoo Developer
134 g2boojum@g.o
136 GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76


Subject Author
Re: [gentoo-dev] Gentoo: State of the Union Grant Goodyear <g2boojum@g.o>
Re: [gentoo-dev] Gentoo: State of the Union (Tim Yamin)
Re: [gentoo-dev] Gentoo: State of the Union Ryan Phillips <rphillips@g.o>