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. |
3 |
|
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. |
7 |
|
8 |
Some of these problems are intermixed. Please consider them starting points |
9 |
for discussion. |
10 |
|
11 |
__Problem: Developer Growth__ |
12 |
|
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. |
19 |
|
20 |
All these reasons leave the project stagnant and lacking developers. |
21 |
|
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. |
27 |
|
28 |
Perhaps its because of a live tree... |
29 |
|
30 |
__Problem: Live Tree__ |
31 |
|
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. |
35 |
|
36 |
CVS doesn't do branching nor tags very well... |
37 |
|
38 |
__Problem: CVS__ |
39 |
|
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. |
46 |
|
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. |
50 |
|
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. |
54 |
|
55 |
Huge projects like Apache, GCC, and KDE already use SVN. |
56 |
|
57 |
__Problem: QA Policies__ |
58 |
|
59 |
http://article.gmane.org/gmane.linux.gentoo.devel/37544 |
60 |
|
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. |
63 |
|
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. |
69 |
|
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. |
78 |
|
79 |
Gentoo should be a fun environment. The previous paragraph should be taken as |
80 |
a last resort. |
81 |
|
82 |
__Problem: GLEPs__ |
83 |
|
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. |
89 |
|
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. |
94 |
|
95 |
__Problem: Voting__ |
96 |
|
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. |
102 |
|
103 |
The Apache Foundation already has a decent page regarding this: |
104 |
http://www.apache.org/foundation/voting.html |
105 |
|
106 |
The Apache Foundation has over 1300 developers; they must be doing something |
107 |
right. |
108 |
|
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. |
112 |
|
113 |
=-=-=-=-=- |
114 |
|
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. |
118 |
|
119 |
Ryan |
120 |
Gentoo Developer |
121 |
|
122 |
[1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 |
123 |
[2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html |