Gentoo Archives: gentoo-dev

From: Ryan Phillips <rphillips@g.o>
To: Jon Portnoy <avenj@g.o>
Cc: Ryan Phillips <rphillips@g.o>, gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo: State of the Union
Date: Fri, 28 Apr 2006 18:24:38
Message-Id: 20060428182205.GA62866@watcher.kimaker.com
In Reply to: Re: [gentoo-dev] Gentoo: State of the Union by Jon Portnoy
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

Replies

Subject Author
Re: [gentoo-dev] Gentoo: State of the Union Chris White <chriswhite@g.o>
Re: [gentoo-dev] Gentoo: State of the Union Alin Nastac <mrness@g.o>
Re: [gentoo-dev] Gentoo: State of the Union "Bryan Ƙstergaard" <kloeri@g.o>
Re: [gentoo-dev] Gentoo: State of the Union Thierry Carrez <koon@g.o>