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
signature.asc
Description: PGP signature
