Gentoo Archives: gentoo-dev

From: Ryan Phillips <rphillips@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Gentoo: State of the Union
Date: Fri, 28 Apr 2006 17:19:22
1 This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and
2 seemant's letter on herds, teams, and projects.
4 I believe the way Gentoo is doing things is broken. There I have said it. The
5 entire project has reached a level of being too political and trying to solve
6 certain problems in the wrong way.
8 Some of these problems are intermixed. Please consider them starting points
9 for discussion.
11 __Problem: Developer Growth__
13 I find that developer growth as being a problem. Adding a developer to gentoo
14 should be as easy as 1. has the user contributed numerous (~5+) patches that
15 helps the project move forward. If yes, then commit access should be given.
16 Adding a developer is usually quite a chore. There are numerous reasons why
17 this is a problem: having a live tree, taking a test, and not defining within
18 policy when a person could possibly get commit access.
20 All these reasons leave the project stagnant and lacking developers.
22 Why do people have to take a test? Is it to make sure they won't break the
23 tree? If it is, then the solution of a test is wrong. We do want to make sure
24 our developers understand gentoo, but I argue that the bugtracker is all we
25 need. As long as a person is adding value to gentoo and they have "proven"
26 themselves, then they *should* have commit access.
28 Perhaps its because of a live tree...
30 __Problem: Live Tree__
32 Having a live tree requires people to be perfect. People are not perfect and
33 requiring it is ridiculous. I love having commits in my local tree within the
34 hour, but having a stable and unstable branch makes a lot of sense.
36 CVS doesn't do branching nor tags very well...
38 __Problem: CVS__
40 CVS is one of the worst application ever created. The portage tree needs to
41 move to subversion. A lot of the problems within the project would be solved
42 by using a better SCM system. The previous problems regarding the Live Tree
43 and Developer Growth would be solved, IMHO, by just switching. Branches Work.
44 Tags Work. Reverts work. Moves work. I don't see any reason not to use it.
45 It just plain works.
47 Projects (gentoo/bsd, embedded, hardened) could choose to keep their own
48 branches of the portage tree and merge with trunk as needed. Projects could
49 stick to traditional solutions like profiles if they so wished.
51 Some will probably ask who will merge between branches. We can do that easily
52 ourselves. If I think a package is good to go, then svn merge -r1123:1124 to
53 the branch.
55 Huge projects like Apache, GCC, and KDE already use SVN.
57 __Problem: QA Policies__
61 It seems that the QA Policies are a product of a Live Tree, and going partially
62 non-live would solve the problems listed.
64 Everyone here is on the same team. There will be some breakages in the tree
65 and those can be dealt with. Like Seemant [1] said, herds are just groups of
66 like *packages*. The QA Policy is wrong when it says cross-team assistance; we
67 are all on the *same* team. The tree should naturally work. If it doesn't
68 then that is a bug for all of us.
70 Conflict resolution should not be a subproject. It should *not* exist at all.
71 Rules need to be in place to avoid conflict. Having some sort of voting
72 structure for all the developers (this doesn't mean requiring everyone to vote)
73 and not just the council or devrel makes a lot of sense for most things. If I
74 don't like how someone is acting within the project there should be a vote and
75 then see if that person is kicked out. No trial, no anything besides a vote.
76 And if I lose I have to deal with it. Either stay with the project, or find
77 something else. This solution just works.
79 Gentoo should be a fun environment. The previous paragraph should be taken as
80 a last resort.
82 __Problem: GLEPs__
84 I dislike GLEPs. Usually they sit on the website for a long long time not
85 doing anything. My vote (+1) is get rid of gleps and do everything by email
86 and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea.
87 It stifles things from getting done, and there is no ownership of who is going
88 to implement the idea.
90 A new idea proposal should be mailed to a mailinglist (-innovation?) with
91 details of timeline to completion, impact, and who is doing the implementation.
92 If it sounds like a good one, then there is a vote and things proceed. I like
93 progress.
95 __Problem: Voting__
97 Gentoo has over 200 developers. People are generally against the voting idea,
98 but I'm not sure why. I think voting should work like this: if 30 developers
99 (or someother specified number) vote yes to an idea then that idea passes. It
100 doesn't require everyone to vote, be at home, be on the computer, and not be on
101 vacation.
103 The Apache Foundation already has a decent page regarding this:
106 The Apache Foundation has over 1300 developers; they must be doing something
107 right.
109 If someone misses a vote, too bad. You weren't there and progress has been
110 made. I equate this to leaving on vacation from work. My input is missed
111 while away, but decisions have been made in my absence.
113 =-=-=-=-=-
115 What is interesting is that Source Mage Linux has already voted on a proposal
116 similar to mine[2]. I truly think that making some changes in the "gentoo way"
117 would benefit us and make gentoo a truly better distribution.
119 Ryan
120 Gentoo Developer
122 [1]
123 [2]