[gentoo-dev] EAPI Feature Request Bugs

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

Following discussion on the PMS list about how we can keep track of new
EAPI feature requests [1], and from the Council's discussions on the
development model for new EAPIs:

For 'Future EAPI' bugs, please do the following:

* Try to make sure there's a single bug describing the feature, rather
  than co-opting an existing bug report.

* Set 'Product' to 'Gentoo Hosted Projects' and 'Component' to
  'PMS / EAPI'.

* Set the 'Status Whiteboard' field to 'unclassified'.

* Mark the bug as blocking 174380.

Every now and again, the PMS team will go through and change the
'unclassified's to one of:

* feasible-for-next-eapi, if we think this is something that's probably
  doable in the next EAPI (basically if it's not going to be insanely
  difficult to implement in Portage).

* distant-future-eapi, if it's probably not an easy feature, or if
  there's not enough detail on how the change will work.

These are merely helpful indicators, and they'll get changed based upon
feedback from Portage people etc.

When we start work on the next EAPI, we'll change the bugs in the
initial list to be 'active-consideration-for-eapi-4'.

As the process goes on and the list gets narrowed down by Council and
Portage feedback, we'll kick things back to 'unclassified' and start
thinking about them again once the EAPI's over. Things that make it to
the "approved draft, to be accepted once Portage support is there" will
get 'in-eapi-4' instead.

Hopefully this'll make it easier to make sure we all know what's going
on, and harder for simple things to get missed because no-one remembers
them at the time.

[1]: http://archives.gentoo.org/gentoo-pms/msg_927530a070199c51f553df8360337de2.xml

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]