1 |
On Wednesday 14 December 2005 06:16, Grant Goodyear wrote: |
2 |
> Jason Stubbs wrote: [Mon Dec 12 2005, 08:06:54PM CST] |
3 |
> |
4 |
> > The purpose of GLEPs is to coordinate several teams into providing an |
5 |
> > overall enhancement to Gentoo. However, the GLEP itself is written by |
6 |
> > a single person rather than a cooperative effort between the teams. |
7 |
> |
8 |
> You know, there's no reason that GLEPs need to be written by a single |
9 |
> person. It's often true, though, that it is a single person's idea, |
10 |
> initially at least. |
11 |
|
12 |
Definitely. Ideas usually are a single person's "eureka" even if it comes |
13 |
through discussion with others. |
14 |
|
15 |
> > Specification |
16 |
> > |
17 |
> > Rather than coming to the ML with a completed GLEP and then asking for |
18 |
> > feedback, a GLEP author should look at the teams involved and then |
19 |
> > select a solicit a member from each team to be responsible for that |
20 |
> > area of the GLEP. The GLEP author may represent any teams they belong |
21 |
> > to. |
22 |
> |
23 |
> Throwing out the initial GLEP amounts to the same thing, in my opinion, |
24 |
> since any interested parties are urged to provide feedback, and ideally |
25 |
> the next revision will include that feedback, either to accept it or |
26 |
> reject it. |
27 |
|
28 |
This is where it is falling down. The assumption is that somebody from each |
29 |
affected team happens to notice the post and have the time to reply before |
30 |
the GLEP goes too far. It also means that the goals and direction of the |
31 |
teams affected have no bearing on the initial revision of the GLEP. With the |
32 |
initial revision of the GLEP setting the direction in which it will head (or |
33 |
fizzle), the GLEP author is essentially handing tasks to various teams (which |
34 |
may conflict with their goals) if the initial revision draws enough support. |
35 |
|
36 |
> > Rationale |
37 |
> > |
38 |
> > Rather than doing lots of hard work and having it thrown away once it |
39 |
> > is found to be unacceptable by the teams involved, the teams involved |
40 |
> > share the hard work and come up with something acceptable to everybody |
41 |
> > right from the outset. |
42 |
> |
43 |
> Yes, of course, GLEP authors should talk to the folks who are likely to |
44 |
> be affected beforehand, but if they fail to do so then the GLEP process |
45 |
> is likely to be rather protracted for that GLEP. I have to admit that I |
46 |
> have no problem with people doing hard work for little gain, if that's |
47 |
> what people want to do. *Shrug* |
48 |
|
49 |
Why go through all that stress? Given GLEP 41, how much effort should infra |
50 |
need to put into defending why the tasks initially set out by the GLEP author |
51 |
are impractical? Is a single email enough? Is a battle with the GLEP author |
52 |
required if the GLEP author disagrees? That's assuming of course that a |
53 |
response was quick enough. It's not only the GLEP authors whom are doing |
54 |
extra unnecessary work. |
55 |
|
56 |
In addition as I missed out the signing off part from the inital post, should |
57 |
council members all be continually polling the lists for disagreement and |
58 |
marking it down in a notebook to be pulled out in time for when the GLEP is |
59 |
put to a vote? Or is it all just down to how convincingly the GLEP author |
60 |
speaks in the meeting where it is voted upon? Because there is no mechanism |
61 |
to ensure otherwise, the latter is inevitably the case. |
62 |
|
63 |
-- |
64 |
Jason Stubbs |
65 |
-- |
66 |
gentoo-dev@g.o mailing list |