Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo: State of the Union
Date: Fri, 28 Apr 2006 17:58:23
In Reply to: [gentoo-dev] Gentoo: State of the Union by Ryan Phillips
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 >
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.
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.
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:
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?
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...
64 More details on how Branches and Tags solve the Live Tree problem would
65 be good.
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.
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.
91 >
92 > __Problem: QA Policies__
93 >
94 >
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.
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?
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.
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:
139 A) Many of the GLEPS require someone to do the work.
140 B) No one has volunteered.
142 Can you address these problems?
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 >
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.
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.
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]
178 > [2]
179 --
180 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Gentoo: State of the Union Ryan Phillips <rphillips@g.o>