Gentoo Archives: gentoo-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] GLEP XX: Fix the GLEP process
Date: Wed, 14 Dec 2005 16:22:45
Message-Id: 200512150116.51400.jstubbs@gentoo.org
In Reply to: Re: [gentoo-dev] GLEP XX: Fix the GLEP process by Grant Goodyear
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