1 |
Ryan Phillips wrote: |
2 |
> This is a follow up to Mark's (halcy0n's) thread regarding QA Policies and |
3 |
> seemant's letter on herds, teams, and projects. |
4 |
> |
5 |
> I believe the way Gentoo is doing things is broken. There I have said it. The |
6 |
> entire project has reached a level of being too political and trying to solve |
7 |
> certain problems in the wrong way. |
8 |
> |
9 |
> Some of these problems are intermixed. Please consider them starting points |
10 |
> for discussion. |
11 |
> |
12 |
> __Problem: Developer Growth__ |
13 |
> |
14 |
> I find that developer growth as being a problem. Adding a developer to gentoo |
15 |
> should be as easy as 1. has the user contributed numerous (~5+) patches that |
16 |
> helps the project move forward. If yes, then commit access should be given. |
17 |
> Adding a developer is usually quite a chore. There are numerous reasons why |
18 |
> this is a problem: having a live tree, taking a test, and not defining within |
19 |
> policy when a person could possibly get commit access. |
20 |
> |
21 |
> All these reasons leave the project stagnant and lacking developers. |
22 |
> |
23 |
> Why do people have to take a test? Is it to make sure they won't break the |
24 |
> tree? If it is, then the solution of a test is wrong. We do want to make sure |
25 |
> our developers understand gentoo, but I argue that the bugtracker is all we |
26 |
> need. As long as a person is adding value to gentoo and they have "proven" |
27 |
> themselves, then they *should* have commit access. |
28 |
> |
29 |
> Perhaps its because of a live tree... |
30 |
> |
31 |
|
32 |
I am relatively new, I lurked for quite some time on IRC ( a yearish ) |
33 |
before finally becoming a dev, and the quiz was not particularly |
34 |
difficult, and the questions I didn't know, I asked my Mentor about. I |
35 |
think Mentors in general don't do a very good job ( not complaining |
36 |
about mine, mind, just in general ). I think in some cases, people are |
37 |
afraid to ask questions. |
38 |
|
39 |
We have the madly successful AT project, and a new Herd Tester project |
40 |
is in the works. I find both of these to be very good ideas and have |
41 |
aided in developer growth. |
42 |
|
43 |
As for your suggestion, with a "Live Tree" you cannot give random users |
44 |
who contribute "5 patches" commit access. Commiting comes with it an |
45 |
inherit responsibility. The following is an example only: |
46 |
|
47 |
I can go in right now and commit something that destroys anyone's box |
48 |
not running SElinux, just bump portage and then watch anyone that uses |
49 |
the new version destroy their machine. Part of this involves having a |
50 |
reputation based system. IMHO this is part of our own tree security. |
51 |
I have worked hard in the community to become a developer, and throwing |
52 |
that all away to ruin some boxes is silly. Sure once my changes are |
53 |
found they can be revert and a new portage thrown into the tree, but how |
54 |
many boxes were ruined first? What if my commit was unintentional? |
55 |
|
56 |
> __Problem: Live Tree__ |
57 |
> |
58 |
> Having a live tree requires people to be perfect. People are not perfect and |
59 |
> requiring it is ridiculous. I love having commits in my local tree within the |
60 |
> hour, but having a stable and unstable branch makes a lot of sense. |
61 |
> |
62 |
> CVS doesn't do branching nor tags very well... |
63 |
|
64 |
More details on how Branches and Tags solve the Live Tree problem would |
65 |
be good. |
66 |
|
67 |
> |
68 |
> __Problem: CVS__ |
69 |
> |
70 |
> CVS is one of the worst application ever created. The portage tree needs to |
71 |
> move to subversion. A lot of the problems within the project would be solved |
72 |
> by using a better SCM system. The previous problems regarding the Live Tree |
73 |
> and Developer Growth would be solved, IMHO, by just switching. Branches Work. |
74 |
> Tags Work. Reverts work. Moves work. I don't see any reason not to use it. |
75 |
> It just plain works. |
76 |
> |
77 |
> Projects (gentoo/bsd, embedded, hardened) could choose to keep their own |
78 |
> branches of the portage tree and merge with trunk as needed. Projects could |
79 |
> stick to traditional solutions like profiles if they so wished. |
80 |
> |
81 |
> Some will probably ask who will merge between branches. We can do that easily |
82 |
> ourselves. If I think a package is good to go, then svn merge -r1123:1124 to |
83 |
> the branch. |
84 |
> |
85 |
> Huge projects like Apache, GCC, and KDE already use SVN. |
86 |
|
87 |
We have people looking into this. Once more testing is done it will |
88 |
probably be proposed in an official capacity, for now I think a test svn |
89 |
with the whole tree plus tools porting from cvs to svn is the priority. |
90 |
|
91 |
> |
92 |
> __Problem: QA Policies__ |
93 |
> |
94 |
> http://article.gmane.org/gmane.linux.gentoo.devel/37544 |
95 |
> |
96 |
> It seems that the QA Policies are a product of a Live Tree, and going partially |
97 |
> non-live would solve the problems listed. |
98 |
> |
99 |
> Everyone here is on the same team. There will be some breakages in the tree |
100 |
> and those can be dealt with. Like Seemant [1] said, herds are just groups of |
101 |
> like *packages*. The QA Policy is wrong when it says cross-team assistance; we |
102 |
> are all on the *same* team. The tree should naturally work. If it doesn't |
103 |
> then that is a bug for all of us. |
104 |
> |
105 |
> Conflict resolution should not be a subproject. It should *not* exist at all. |
106 |
> Rules need to be in place to avoid conflict. Having some sort of voting |
107 |
> structure for all the developers (this doesn't mean requiring everyone to vote) |
108 |
> and not just the council or devrel makes a lot of sense for most things. If I |
109 |
> don't like how someone is acting within the project there should be a vote and |
110 |
> then see if that person is kicked out. No trial, no anything besides a vote. |
111 |
> And if I lose I have to deal with it. Either stay with the project, or find |
112 |
> something else. This solution just works. |
113 |
|
114 |
How many people are going to actively vote? What keeps "Me n' my |
115 |
Posse'" from just voting out random people we hate; assuming my Posse' |
116 |
is large enough to do so? |
117 |
|
118 |
> |
119 |
> Gentoo should be a fun environment. The previous paragraph should be taken as |
120 |
> a last resort. |
121 |
> |
122 |
> __Problem: GLEPs__ |
123 |
> |
124 |
> I dislike GLEPs. Usually they sit on the website for a long long time not |
125 |
> doing anything. My vote (+1) is get rid of gleps and do everything by email |
126 |
> and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. |
127 |
> It stifles things from getting done, and there is no ownership of who is going |
128 |
> to implement the idea. |
129 |
> |
130 |
> A new idea proposal should be mailed to a mailinglist (-innovation?) with |
131 |
> details of timeline to completion, impact, and who is doing the implementation. |
132 |
> If it sounds like a good one, then there is a vote and things proceed. I like |
133 |
> progress. |
134 |
|
135 |
Uhhh Your E-mail basically states what a GLEP is, aside from the fact |
136 |
that it's on the web instead of being done via E-mail. The problem we |
137 |
currently have is: |
138 |
|
139 |
A) Many of the GLEPS require someone to do the work. |
140 |
B) No one has volunteered. |
141 |
|
142 |
Can you address these problems? |
143 |
|
144 |
> |
145 |
> __Problem: Voting__ |
146 |
> |
147 |
> Gentoo has over 200 developers. People are generally against the voting idea, |
148 |
> but I'm not sure why. I think voting should work like this: if 30 developers |
149 |
> (or someother specified number) vote yes to an idea then that idea passes. It |
150 |
> doesn't require everyone to vote, be at home, be on the computer, and not be on |
151 |
> vacation. |
152 |
> |
153 |
> The Apache Foundation already has a decent page regarding this: |
154 |
> http://www.apache.org/foundation/voting.html |
155 |
> |
156 |
> The Apache Foundation has over 1300 developers; they must be doing something |
157 |
> right. |
158 |
> |
159 |
> If someone misses a vote, too bad. You weren't there and progress has been |
160 |
> made. I equate this to leaving on vacation from work. My input is missed |
161 |
> while away, but decisions have been made in my absence. |
162 |
|
163 |
I could do with a shorter voting period where we vote on more things. |
164 |
I'd like to see at least a few issues voted on at least to see how many |
165 |
people actually show up and vote. |
166 |
|
167 |
> |
168 |
> =-=-=-=-=- |
169 |
> |
170 |
> What is interesting is that Source Mage Linux has already voted on a proposal |
171 |
> similar to mine[2]. I truly think that making some changes in the "gentoo way" |
172 |
> would benefit us and make gentoo a truly better distribution. |
173 |
> |
174 |
> Ryan |
175 |
> Gentoo Developer |
176 |
> |
177 |
> [1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 |
178 |
> [2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html |
179 |
-- |
180 |
gentoo-dev@g.o mailing list |