1 |
Jon Portnoy <avenj@g.o> said: |
2 |
> On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote: |
3 |
> > |
4 |
> > I find that developer growth as being a problem. Adding a developer to gentoo |
5 |
> > should be as easy as 1. has the user contributed numerous (~5+) patches that |
6 |
> > helps the project move forward. If yes, then commit access should be given. |
7 |
> > Adding a developer is usually quite a chore. There are numerous reasons why |
8 |
> > this is a problem: having a live tree, taking a test, and not defining within |
9 |
> > policy when a person could possibly get commit access. |
10 |
> > |
11 |
> > All these reasons leave the project stagnant and lacking developers. |
12 |
> > |
13 |
> |
14 |
> Maybe certain projects are (and maybe there are a lot of undermaintained |
15 |
> packages) but overall I would say we are not really lacking developers; |
16 |
> what areas would you say we're lacking devs in exactly? |
17 |
> |
18 |
> The recruitment process should be tightened further to ensure we have a |
19 |
> solid, educated dev base. This isn't about shutting people out, it's |
20 |
> about ensuring that anyone with commit access is well-versed in how we |
21 |
> do things. |
22 |
|
23 |
I believe we have a problem enticing new devlopers to join. It |
24 |
shouldn't be difficult in learning how to commit changes to a tree. |
25 |
|
26 |
What is "well versed"? Understanding the ways on how to break the tree? If that |
27 |
is the case, then we are doing something wrong. |
28 |
|
29 |
> > Why do people have to take a test? Is it to make sure they won't break the |
30 |
> > tree? If it is, then the solution of a test is wrong. We do want to make sure |
31 |
> > our developers understand gentoo, but I argue that the bugtracker is all we |
32 |
> > need. As long as a person is adding value to gentoo and they have "proven" |
33 |
> > themselves, then they *should* have commit access. |
34 |
> > |
35 |
> |
36 |
> Many people with useful contributions can commit garbage due to not |
37 |
> quite knowing what they're doing. |
38 |
> The quiz process is an attempt to address that. We used to recruit the |
39 |
> way you suggest and it worked for years; we've since outgrown that. |
40 |
> "Testing" recruits provides further education. |
41 |
> |
42 |
> Admittedly the quiz as it stands is archaic and needs reworking. I |
43 |
> believe the recruiters team is working on addressing that. |
44 |
|
45 |
I am arguing that we don't need testing of potential developers. It |
46 |
is bad for the community. It is saying that we don't have any faith |
47 |
with our recruiting process. If we only only worried about tree breakage, |
48 |
then this is the wrong solution. |
49 |
|
50 |
> > Everyone here is on the same team. There will be some breakages in the tree |
51 |
> > and those can be dealt with. Like Seemant [1] said, herds are just groups of |
52 |
> > like *packages*. The QA Policy is wrong when it says cross-team assistance; we |
53 |
> > are all on the *same* team. The tree should naturally work. If it doesn't |
54 |
> > then that is a bug for all of us. |
55 |
> > |
56 |
> |
57 |
> OK, well, realistically we are composed of projects working on various |
58 |
> areas of Gentoo that must work together with one another to form a |
59 |
> whole. Gentoo is not and should not be one big amorphous blob. |
60 |
|
61 |
I agree. The mentality should be one project, even if the herds are |
62 |
split into more project. I do not like when people say that someone |
63 |
has stepped on their toes when committing a change to another herd.. |
64 |
Typically people are trying to help. If there is a breakage then it |
65 |
is a problem for Gentoo, not just a herd. Having a live tree just |
66 |
adds to this problem. |
67 |
|
68 |
> > Conflict resolution should not be a subproject. It should *not* exist at all. |
69 |
> > Rules need to be in place to avoid conflict. Having some sort of voting |
70 |
> > structure for all the developers (this doesn't mean requiring everyone to vote) |
71 |
> > and not just the council or devrel makes a lot of sense for most things. |
72 |
> > If I |
73 |
> > don't like how someone is acting within the project there should be a vote and |
74 |
> > then see if that person is kicked out. No trial, no anything besides a vote. |
75 |
> > And if I lose I have to deal with it. Either stay with the project, or find |
76 |
> > something else. This solution just works. |
77 |
> |
78 |
> Why should conflict resolution be a popularity contest? |
79 |
|
80 |
It isn't. It is how a job works. If someone isn't getting along with |
81 |
the team, they are fired. Same principle. |
82 |
|
83 |
> > |
84 |
> > Gentoo should be a fun environment. The previous paragraph should be taken as |
85 |
> > a last resort. |
86 |
> > |
87 |
> > __Problem: GLEPs__ |
88 |
> > |
89 |
> > I dislike GLEPs. Usually they sit on the website for a long long time not |
90 |
> > doing anything. My vote (+1) is get rid of gleps and do everything by email |
91 |
> > and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. |
92 |
> > It stifles things from getting done, and there is no ownership of who is going |
93 |
> > to implement the idea. |
94 |
> > |
95 |
> > A new idea proposal should be mailed to a mailinglist (-innovation?) with |
96 |
> > details of timeline to completion, impact, and who is doing the implementation. |
97 |
> > If it sounds like a good one, then there is a vote and things proceed. I like |
98 |
> > progress. |
99 |
> |
100 |
> Well, I think we all like progress. The council votes on GLEPs; I don't |
101 |
> see how extending voting to include _all of Gentoo_ would speed things |
102 |
> up or contribute to progress... this is why we elect representatives. |
103 |
> |
104 |
> Overall I think this would be a regression. |
105 |
|
106 |
The council should not vote on gleps are provide policy. They should |
107 |
be there to handle the money and world-wide problems. |
108 |
|
109 |
The developers should drive innovation; not the council. |
110 |
|
111 |
As in all democracies things get done slowly. We don't need a |
112 |
democracy within Gentoo, just a clear way of creating progress. |
113 |
|
114 |
-Ryan |