1 |
On Fri, Apr 28, 2006 at 10:14:53AM -0700, Ryan Phillips wrote: |
2 |
> |
3 |
> I find that developer growth as being a problem. Adding a developer to gentoo |
4 |
> should be as easy as 1. has the user contributed numerous (~5+) patches that |
5 |
> helps the project move forward. If yes, then commit access should be given. |
6 |
> Adding a developer is usually quite a chore. There are numerous reasons why |
7 |
> this is a problem: having a live tree, taking a test, and not defining within |
8 |
> policy when a person could possibly get commit access. |
9 |
> |
10 |
> All these reasons leave the project stagnant and lacking developers. |
11 |
> |
12 |
|
13 |
Maybe certain projects are (and maybe there are a lot of undermaintained |
14 |
packages) but overall I would say we are not really lacking developers; |
15 |
what areas would you say we're lacking devs in exactly? |
16 |
|
17 |
The recruitment process should be tightened further to ensure we have a |
18 |
solid, educated dev base. This isn't about shutting people out, it's |
19 |
about ensuring that anyone with commit access is well-versed in how we |
20 |
do things. |
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 |
|
29 |
Many people with useful contributions can commit garbage due to not |
30 |
quite knowing what they're doing. |
31 |
The quiz process is an attempt to address that. We used to recruit the |
32 |
way you suggest and it worked for years; we've since outgrown that. |
33 |
"Testing" recruits provides further education. |
34 |
|
35 |
Admittedly the quiz as it stands is archaic and needs reworking. I |
36 |
believe the recruiters team is working on addressing that. |
37 |
|
38 |
> |
39 |
> Everyone here is on the same team. There will be some breakages in the tree |
40 |
> and those can be dealt with. Like Seemant [1] said, herds are just groups of |
41 |
> like *packages*. The QA Policy is wrong when it says cross-team assistance; we |
42 |
> are all on the *same* team. The tree should naturally work. If it doesn't |
43 |
> then that is a bug for all of us. |
44 |
> |
45 |
|
46 |
OK, well, realistically we are composed of projects working on various |
47 |
areas of Gentoo that must work together with one another to form a |
48 |
whole. Gentoo is not and should not be one big amorphous blob. |
49 |
|
50 |
> Conflict resolution should not be a subproject. It should *not* exist at all. |
51 |
> Rules need to be in place to avoid conflict. Having some sort of voting |
52 |
> structure for all the developers (this doesn't mean requiring everyone to vote) |
53 |
> and not just the council or devrel makes a lot of sense for most things. |
54 |
> If I |
55 |
> don't like how someone is acting within the project there should be a vote and |
56 |
> then see if that person is kicked out. No trial, no anything besides a vote. |
57 |
> And if I lose I have to deal with it. Either stay with the project, or find |
58 |
> something else. This solution just works. |
59 |
|
60 |
Why should conflict resolution be a popularity contest? |
61 |
|
62 |
> |
63 |
> Gentoo should be a fun environment. The previous paragraph should be taken as |
64 |
> a last resort. |
65 |
> |
66 |
> __Problem: GLEPs__ |
67 |
> |
68 |
> I dislike GLEPs. Usually they sit on the website for a long long time not |
69 |
> doing anything. My vote (+1) is get rid of gleps and do everything by email |
70 |
> and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. |
71 |
> It stifles things from getting done, and there is no ownership of who is going |
72 |
> to implement the idea. |
73 |
> |
74 |
> A new idea proposal should be mailed to a mailinglist (-innovation?) with |
75 |
> details of timeline to completion, impact, and who is doing the implementation. |
76 |
> If it sounds like a good one, then there is a vote and things proceed. I like |
77 |
> progress. |
78 |
|
79 |
Well, I think we all like progress. The council votes on GLEPs; I don't |
80 |
see how extending voting to include _all of Gentoo_ would speed things |
81 |
up or contribute to progress... this is why we elect representatives. |
82 |
|
83 |
Overall I think this would be a regression. |
84 |
|
85 |
-- |
86 |
Jon Portnoy |
87 |
avenj/irc.freenode.net |
88 |
-- |
89 |
gentoo-dev@g.o mailing list |