1 |
On Fri, Apr 28, 2006 at 11:22:05AM -0700, Ryan Phillips wrote: |
2 |
> Jon Portnoy <avenj@g.o> said: |
3 |
> > On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote: |
4 |
> > > |
5 |
> > > I find that developer growth as being a problem. Adding a developer to gentoo |
6 |
> > > should be as easy as 1. has the user contributed numerous (~5+) patches that |
7 |
> > > helps the project move forward. If yes, then commit access should be given. |
8 |
> > > Adding a developer is usually quite a chore. There are numerous reasons why |
9 |
> > > this is a problem: having a live tree, taking a test, and not defining within |
10 |
> > > policy when a person could possibly get commit access. |
11 |
> > > |
12 |
> > > All these reasons leave the project stagnant and lacking developers. |
13 |
> > > |
14 |
> > |
15 |
> > Maybe certain projects are (and maybe there are a lot of undermaintained |
16 |
> > packages) but overall I would say we are not really lacking developers; |
17 |
> > what areas would you say we're lacking devs in exactly? |
18 |
> > |
19 |
> > The recruitment process should be tightened further to ensure we have a |
20 |
> > solid, educated dev base. This isn't about shutting people out, it's |
21 |
> > about ensuring that anyone with commit access is well-versed in how we |
22 |
> > do things. |
23 |
> |
24 |
> I believe we have a problem enticing new devlopers to join. It |
25 |
> shouldn't be difficult in learning how to commit changes to a tree. |
26 |
> |
27 |
> What is "well versed"? Understanding the ways on how to break the tree? If that |
28 |
> is the case, then we are doing something wrong. |
29 |
> |
30 |
I come from a different background being a recruiter and having done |
31 |
most, if not all, the work to clean up the current developer base so |
32 |
far. |
33 |
|
34 |
And from what I'm seeing we have to make it *harder* to become a gentoo |
35 |
developer if we want to keep any quality at all. It's not that we don't |
36 |
get lots of new developers but looking back at all the developers I've |
37 |
been retiring due to inactivity it's fairly clear that a huge part of |
38 |
them never did more than 5 commits or so.. And it takes a good deal more |
39 |
than 5 commits before you know all the intricacies of portage/gentoo and |
40 |
are able to do quality work on a consistent basis. |
41 |
|
42 |
I've mentored quite a few developers myself and I believe I did a fairly |
43 |
good job as a mentor but there's still quite some difference between |
44 |
first few commits and later commits from those devs as they gain |
45 |
experience. |
46 |
|
47 |
Personally, I don't want Gentoo to be characterised by "revolving door" |
48 |
developers and I'd expect users would be fairly unhappy with that as |
49 |
well. |
50 |
|
51 |
> > > Why do people have to take a test? Is it to make sure they won't break the |
52 |
> > > tree? If it is, then the solution of a test is wrong. We do want to make sure |
53 |
> > > our developers understand gentoo, but I argue that the bugtracker is all we |
54 |
> > > need. As long as a person is adding value to gentoo and they have "proven" |
55 |
> > > themselves, then they *should* have commit access. |
56 |
> > > |
57 |
> > |
58 |
> > Many people with useful contributions can commit garbage due to not |
59 |
> > quite knowing what they're doing. |
60 |
> > The quiz process is an attempt to address that. We used to recruit the |
61 |
> > way you suggest and it worked for years; we've since outgrown that. |
62 |
> > "Testing" recruits provides further education. |
63 |
> > |
64 |
> > Admittedly the quiz as it stands is archaic and needs reworking. I |
65 |
> > believe the recruiters team is working on addressing that. |
66 |
> |
67 |
> I am arguing that we don't need testing of potential developers. It |
68 |
> is bad for the community. It is saying that we don't have any faith |
69 |
> with our recruiting process. If we only only worried about tree breakage, |
70 |
> then this is the wrong solution. |
71 |
The Arch Tester / Herd Tester projects solves many of the current |
72 |
problems but I very much believe we need something akin to the current |
73 |
tests. We *will* try to improve those tests but I'm going to fight |
74 |
"making it easier to become a developer" hard as that's a very bad |
75 |
direction from my point of view. |
76 |
> |
77 |
> > > Everyone here is on the same team. There will be some breakages in the tree |
78 |
> > > and those can be dealt with. Like Seemant [1] said, herds are just groups of |
79 |
> > > like *packages*. The QA Policy is wrong when it says cross-team assistance; we |
80 |
> > > are all on the *same* team. The tree should naturally work. If it doesn't |
81 |
> > > then that is a bug for all of us. |
82 |
> > > |
83 |
> > |
84 |
> > OK, well, realistically we are composed of projects working on various |
85 |
> > areas of Gentoo that must work together with one another to form a |
86 |
> > whole. Gentoo is not and should not be one big amorphous blob. |
87 |
> |
88 |
> I agree. The mentality should be one project, even if the herds are |
89 |
> split into more project. I do not like when people say that someone |
90 |
> has stepped on their toes when committing a change to another herd.. |
91 |
> Typically people are trying to help. If there is a breakage then it |
92 |
> is a problem for Gentoo, not just a herd. Having a live tree just |
93 |
> adds to this problem. |
94 |
> |
95 |
> > > Conflict resolution should not be a subproject. It should *not* exist at all. |
96 |
> > > Rules need to be in place to avoid conflict. Having some sort of voting |
97 |
> > > structure for all the developers (this doesn't mean requiring everyone to vote) |
98 |
> > > and not just the council or devrel makes a lot of sense for most things. |
99 |
> > > If I |
100 |
> > > don't like how someone is acting within the project there should be a vote and |
101 |
> > > then see if that person is kicked out. No trial, no anything besides a vote. |
102 |
> > > And if I lose I have to deal with it. Either stay with the project, or find |
103 |
> > > something else. This solution just works. |
104 |
> > |
105 |
> > Why should conflict resolution be a popularity contest? |
106 |
> |
107 |
> It isn't. It is how a job works. If someone isn't getting along with |
108 |
> the team, they are fired. Same principle. |
109 |
You know, I could probably swing a few votes if I wanted to and so could |
110 |
many other devs.. I'd call that a popularity contest as opposed to the |
111 |
currently proposed (see gentoo-devrel ML) conflict resolution policy |
112 |
that have developers interested in conflict resolution working out the |
113 |
solution (as opposed to a large but random selection of developers who |
114 |
could probably care less). |
115 |
> |
116 |
> > > |
117 |
> > > Gentoo should be a fun environment. The previous paragraph should be taken as |
118 |
> > > a last resort. |
119 |
> > > |
120 |
> > > __Problem: GLEPs__ |
121 |
> > > |
122 |
> > > I dislike GLEPs. Usually they sit on the website for a long long time not |
123 |
> > > doing anything. My vote (+1) is get rid of gleps and do everything by email |
124 |
> > > and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. |
125 |
> > > It stifles things from getting done, and there is no ownership of who is going |
126 |
> > > to implement the idea. |
127 |
> > > |
128 |
> > > A new idea proposal should be mailed to a mailinglist (-innovation?) with |
129 |
> > > details of timeline to completion, impact, and who is doing the implementation. |
130 |
> > > If it sounds like a good one, then there is a vote and things proceed. I like |
131 |
> > > progress. |
132 |
> > |
133 |
> > Well, I think we all like progress. The council votes on GLEPs; I don't |
134 |
> > see how extending voting to include _all of Gentoo_ would speed things |
135 |
> > up or contribute to progress... this is why we elect representatives. |
136 |
> > |
137 |
> > Overall I think this would be a regression. |
138 |
> |
139 |
> The council should not vote on gleps are provide policy. They should |
140 |
> be there to handle the money and world-wide problems. |
141 |
> |
142 |
> The developers should drive innovation; not the council. |
143 |
> |
144 |
> As in all democracies things get done slowly. We don't need a |
145 |
> democracy within Gentoo, just a clear way of creating progress. |
146 |
> |
147 |
> -Ryan |
148 |
|
149 |
The developers (and many users) *are* driving innovation but we still |
150 |
need some kind of checks and balances in a 300+ group of developers. If |
151 |
we were only 20 developers this would probably come naturally from irc |
152 |
discussions but we're no longer a small, tightly nit group of |
153 |
developers. As part of "growing up" we (naturally) need more |
154 |
communication between developers before running off with the newest, |
155 |
crazy idea. |
156 |
|
157 |
Gentoo is no longer a playground - we have some 10k+ packages in the |
158 |
tree and 100k+ users at least afaik. We *need* to take our |
159 |
responsibility seriously and not play hazard with all those |
160 |
users/system. |
161 |
|
162 |
So.. What can we do to improve things? There's lots of things that can |
163 |
be improved in my opinion. Developer relations is currently pushing out |
164 |
a new proposed conflict resolution policy for public discussion on the |
165 |
gentoo-devrel ML. It's been out for a couple days already and I have yet |
166 |
to see a single comment on it. |
167 |
|
168 |
Likewise, we're trying to come up with a proposal for improving |
169 |
recruitment / quizzes. |
170 |
|
171 |
I'd love to see people (both users and developers) get involved in these |
172 |
discussions instead of posting general rants on the current state of |
173 |
gentoo. Working on small corners of gentoo can make a big difference (in |
174 |
a short amount of time) and I'm sure I'm not the only one who'd love to |
175 |
see that :) |
176 |
|
177 |
Regards, |
178 |
Bryan Østergaard |
179 |
-- |
180 |
gentoo-dev@g.o mailing list |