1 |
Following discussion on the PMS list about how we can keep track of new |
2 |
EAPI feature requests [1], and from the Council's discussions on the |
3 |
development model for new EAPIs: |
4 |
|
5 |
For 'Future EAPI' bugs, please do the following: |
6 |
|
7 |
* Try to make sure there's a single bug describing the feature, rather |
8 |
than co-opting an existing bug report. |
9 |
|
10 |
* Set 'Product' to 'Gentoo Hosted Projects' and 'Component' to |
11 |
'PMS / EAPI'. |
12 |
|
13 |
* Set the 'Status Whiteboard' field to 'unclassified'. |
14 |
|
15 |
* Mark the bug as blocking 174380. |
16 |
|
17 |
Every now and again, the PMS team will go through and change the |
18 |
'unclassified's to one of: |
19 |
|
20 |
* feasible-for-next-eapi, if we think this is something that's probably |
21 |
doable in the next EAPI (basically if it's not going to be insanely |
22 |
difficult to implement in Portage). |
23 |
|
24 |
* distant-future-eapi, if it's probably not an easy feature, or if |
25 |
there's not enough detail on how the change will work. |
26 |
|
27 |
These are merely helpful indicators, and they'll get changed based upon |
28 |
feedback from Portage people etc. |
29 |
|
30 |
When we start work on the next EAPI, we'll change the bugs in the |
31 |
initial list to be 'active-consideration-for-eapi-4'. |
32 |
|
33 |
As the process goes on and the list gets narrowed down by Council and |
34 |
Portage feedback, we'll kick things back to 'unclassified' and start |
35 |
thinking about them again once the EAPI's over. Things that make it to |
36 |
the "approved draft, to be accepted once Portage support is there" will |
37 |
get 'in-eapi-4' instead. |
38 |
|
39 |
Hopefully this'll make it easier to make sure we all know what's going |
40 |
on, and harder for simple things to get missed because no-one remembers |
41 |
them at the time. |
42 |
|
43 |
[1]: http://archives.gentoo.org/gentoo-pms/msg_927530a070199c51f553df8360337de2.xml |
44 |
|
45 |
-- |
46 |
Ciaran McCreesh |