Gentoo Archives: gentoo-dev

From: Ryan Phillips <rphillips@g.o>
To: Simon Stelling <blubb@g.o>
Cc: gentoo-dev@l.g.o, rphillips@g.o
Subject: Re: [gentoo-dev] Gentoo: State of the Union
Date: Fri, 28 Apr 2006 23:17:27
In Reply to: Re: [gentoo-dev] Gentoo: State of the Union by Simon Stelling
1 Simon Stelling <blubb@g.o> said:
2 > Hi Ryan,
3 >
4 > Ryan Phillips wrote:
6 > >__Problem: Developer Growth__
8 > I've seen ebuilds from people who have written quite a bunch of ebuilds
9 > and were really interested in understanding how they work, but the work
10 > they produced just was awful and hurt my eyes. I don't mean that the
11 > mean way, I don't expect anything else, and I was just the same.
12 > However, the mentoring process and the quiz have helped me a lot to
13 > understand not-so-obvious problems.
14 >
15 > >All these reasons leave the project stagnant and lacking developers.
16 >
17 > I wouldn't say so. Just about two weeks or so ago, the recruiters had to
18 > defer new requests, because they couldn't deal with them in a timely
19 > fashion. You can now tell me that this makes it even worse, but I just
20 > see that as the proove of the fact that people are interested in helping
21 > us and ready to take the quiz and all the "hassle" involved with
22 > becoming a dev.
23 >
24 > Another good reason to keep the current process is the fact that a lot
25 > of people become dev and vanish a week after their mentoring period
26 > expired. These people would better contribute to the project in a more
27 > distant way IMHO, because it takes up a fair amount of time to clean up
28 > these accounts afterwards. If you don't beleave me, ask kloeri. ;)
30 I revised my earlier statement to say consistent involvement for ~6
31 months. That is more reasonable.
33 > >Perhaps its because of a live tree...
34 >
35 > That's surely a big factor.
36 >
37 > >__Problem: Live Tree__
38 > >
39 > >Having a live tree requires people to be perfect. People are not perfect
40 > >and
41 > >requiring it is ridiculous. I love having commits in my local tree within
42 > >the
43 > >hour, but having a stable and unstable branch makes a lot of sense.
44 >
45 > It doesn't require people to be perfect. It requires people to think
46 > before commiting. If it really required us to be perfect, we wouldn't
47 > exist in the first place, would we?
49 I disagree. By committing something to the current tree it has the
50 ability to effect a lot of people. What happens when we need to reverse a
51 commit? It isn't that easy with CVS.
53 >
54 > Having a stable and unstable branch doesn't have many advantages over
55 > stable and unstable keywords IMHO, but requires a HUUUGE effort to keep
56 > them in sync. It would make things more complicated than necessary. You
57 > say we're lacking developers. Do you really want to spend [insert random
58 > big number here] of these much-needed developer hours to merging an old
59 > with a new tree?
61 Stable and unstable keywords are a hack on top of a version control
62 system. We wouldn't have them if gentoo used an SCM that supports true
63 branches. There would be no need.
65 It doesn't take much time for a herd to say that this branch is stable
66 for the production tree and do an svn merge or similar. It isn't a
67 full time job.
69 > >Conflict resolution should not be a subproject. It should *not* exist at
70 > >all.
71 >
72 > You mean conflicts or conflict solution shouldn't exist at all?
73 > If the former, that's unrealistic. If the latter, why not?
75 We need a policy so that we can resolve our conflicts. There are two
76 types of conflicts. Personal and Technical. Personal conflicts can
77 be resolved simply; a vote, and be done with it. Technical conflicts
78 need to be resolved by a voting process so that we can move forward.
80 Check out the apache voting page I linked to before.
82 > >Rules need to be in place to avoid conflict. Having some sort of voting
83 > >structure for all the developers (this doesn't mean requiring everyone to
84 > >vote)
85 > >and not just the council or devrel makes a lot of sense for most things.
86 > >If I
87 > >don't like how someone is acting within the project there should be a vote
88 > >and
89 > >then see if that person is kicked out. No trial, no anything besides a
90 > >vote.
91 > >And if I lose I have to deal with it. Either stay with the project, or
92 > >find
93 > >something else. This solution just works.
94 >
95 > Do you really think just because 60% of the voting devs agreed on
96 > something the other 40% will like it suddenly?
98 yes, a majority rule.
100 > Conflicts cannot be
101 > avoided, other than shooting down all people which don't share your
102 > point of view.
104 We need to minimize the conflict and make it easier to overcome those
105 conflicts. Having a voting structure would do that.
107 > >__Problem: GLEPs__
108 > >
109 > >I dislike GLEPs. Usually they sit on the website for a long long time not
110 > >doing anything. My vote (+1) is get rid of gleps and do everything by
111 > >email
112 > >and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad
113 > >Idea.
114 > >It stifles things from getting done, and there is no ownership of who is
115 > >going
116 > >to implement the idea.
117 >
118 > I dislike them too. However, you're not addressing the issue IMHO. The
119 > problem is not that the council votes on them. The problem is much more
120 > that they are proposed to the whole dev community. Yes, you read right.
121 > It's mostly a good thing, but it is also a show stopper. I once wrote up
122 > a GLEP, sent it to the dev ml. Some people liked it, others wanted this
123 > or that changed. I re-submitted it, and they criticised this and that
124 > (which is a good thing!). So I fixed all the stuff they pointed out. In
125 > the end, I had a GLEP. But what I documented was not the idea I wanted
126 > to implement. So I lost interest. The GLEP got approved, but it's still
127 > not implemented. I don't know if anybody is working on it, I wont,
128 > because it's no longer what I once wanted to push forward.
130 This is because Gentoo wants to make everyone happy. We will have
131 conflict. We should have a vote and decide. Your example is
132 perfectly stating the frustration I have.
134 > I would like it much more, if the people who are not affected by the
135 > GLEP wouldn't read it at all anyway. Whenever something is discussed I'm
136 > not involved in or affected by at all, I try to keep my mouth shut. I
137 > just trust the guys who submitted it to do their job the right way. And
138 > IMHO, this is exactly the point. Trust the others to do their job
139 > seriously and well. We don't need a whole dev community voting on an
140 > idea. Having everybody vote instead of a 7-headed council won't reduce
141 > politicalness. And that was what all your mail was about, in the end.
142 >
144 I didn't mention everyone had to vote. There can be lazy consesus.
146 > >__Problem: Voting__
147 >
148 > Heh, really don't need to comment on that one anymore. ;)
150 I think it is the solution.
152 -ryan


Subject Author
Re: [gentoo-dev] Gentoo: State of the Union Chris White <chriswhite@g.o>
Re: [gentoo-dev] Gentoo: State of the Union "Jan Kundrát" <jkt@g.o>