Gentoo Archives: gentoo-dev

From: Mark Bateman <couldbe@××××.com>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [GLEP] Improvements to the GLEP workflow
Date: Tue, 09 Jun 2009 21:50:21
Message-Id: loom.20090609T214513-961@post.gmane.org
1 ABSTRACT
2 This GLEP details a possible enhancement to the GLEP process to aid the Gentoo
3 council in voting on GLEPs as well Gentoo developers in the creation of GLEPs.
4
5
6 MOTIVATION
7 Whenever a developer or user wants to request a significant enhancement to
8 Gentoo the GLEP process can be used to capture the request. Unfortunately
9 all the council can do with GLEPs are either
10
11 1) Vote to accept the GLEP
12 2) Vote to reject the GLEP
13 3) Defer voting on the GLEP
14
15 For the majority of GLEPs this process is adequate. This process however
16 becomes a hindrance if a GLEP is submitted that is either incomplete, fairly
17 complex or a general consensus on the best way forward isn't reached.
18
19 What ends up happening with GLEPs like this is they linger around being
20 tweaked and repeatedly discussed, so much so that eventually nothing new is
21 being discussed and no further constructive discussions occur.
22
23
24 SPECIFICATION
25 Rather then having a process of: GLEP editing -> Council voting -> back to
26 editing until a YES/NO vote. If the GLEP is determined to not describe the
27 problem/enhancement/solution enough it should be suspended and a more
28 structured work flow utilised.
29
30 1) Capture specification of problem or enhancement.
31 The GLEP shall be re-written such that it ONLY details the problems being
32 faced or details the requested enhancement. Actual details are required,
33 "how foo is presently done" is useless in a years time if someone needs to
34 examine an old GLEP.
35
36 Details on possible solutions or implementations are not to be included
37 in this section.
38
39
40 2) Specification Approval
41 Once the actual scope of the problem has been defined the council can vote on
42 freezing the scope of the GLEP.
43
44
45 3) Submission of concepts.
46 With the actual scope of the problem detailed and frozen, developers can
47 discuss what concepts should be added to the GLEP. One or more concepts shall
48 be added to the GLEP with enough detail to show how each falls within the scope
49 of the GLEP. Likewise criticisms of each concept shall be added to provide its
50 pros and cons (if more then one solution is to be submitted). Any required
51 modification to the scope needs to be approved by the council.
52
53
54 4) Concept Design Review
55 Once each concept has been detailed enough, the council can then vote to
56 either accept one of the suggested concepts or reject the GLEP. Details of
57 council decision (ie which concept excepted, if any) to be recorded in the GLEP
58
59 5) Detailed Design Review.
60 An optional step can be utilised to capture the implementation. A final
61 signoff by individuals actually implementing the concept to confirm the scope
62 of the GLEP has been met.
63
64
65 How is this beneficial?
66 By having actual stages to the GLEP process, stages that do not get polluted
67 by discussion/details belonging in a subsequent stage, the content of each stage
68 can be clearly defined so all parties are aware of what is being discussed.
69
70 This also provides the additional benefit of traceability, so that as old
71 developers leave and new developers arrive, the GLEP is a complete package
72 detailing the problems, the solutions as well as the justification. This removes
73 the reliance on distilling mailing list posts or irc logs after the fact.
74
75 Likewise it provides a mechanism for individuals to submit a GLEP who may not
76 be fully aware of the best method to implement such an enhancement. Others can
77 then propose concepts that meet this proposal (if such an enhancement is valid).
78
79 The actual structure of the GLEP template remains largely the same, additions
80 headings would need to be added after the SPECIFICATION heading to provide
81 documentation for the different stages.
82
83 SPECIFICATION: full breakdown of the problem
84
85 COUNCIL COMMENTS ON SPECIFICATION: Capture council’s verdict on GLEP
86 preliminary details capturing any additional information on what the council
87 would like to see in concepts or if it should be rejected
88
89 CONCEPT DESIGNS: Each concept to have its own subheading capturing details of
90 how it plans to solve what has been detailed in the SCOPE of the GLEP
91
92 CONCEPT_1:
93 DETAILS:
94 CRITIQUE:
95 CONCEPT_2:
96 DETAILS:
97 CRITIQUE:
98
99 COUNCIL COMMENTS ON CONCEPT: Result of council vote on what the council have
100 chosen, if the council requires additional metrics if there is no clear
101 advantage between different concepts, or if GLEP is rejected.
102
103 (Optional) DETAILED DESIGN SIGNOFF: A final closing point to the GLEP to capture
104 who fulfilled what and where with respect to the SCOPE
105 Requirement #1 from the SCOPE implement by foo in bar
106
107 RATIONALE: ...

Replies

Subject Author
Re: [gentoo-dev] [GLEP] Improvements to the GLEP workflow Roy Bamford <neddyseagoon@g.o>