
\summary{2012}{8}{14}


\agendaitem{EAPI 5 features}
\index{EAPI!5}

Due to holidays, the list of features for EAPI5 was announced only 2
days in advance of the meeting.  This gave little time for Council
members to prepare for votes.
Therefore a vote was conducted if voting on EAPI5 features in this
meeting was deemed suitable.

The Council voted unanimously to postpone voting on EAPI5 features.

The list of features for EAPI 5 were outlined by ulm in
http://thread.gmane.org/gmane.linux.gentoo.project/2101/focus=2115 (bad link).
Since many of these features appear not to be implemented in Portage, a
discussion on their implementation is called for by the Council.  The
Council stressed that it prefers to vote on EAPI 5 features that can and
will be implemented within a short timeframe, say 1 month.


\agendaitem{Open bugs with Council involvement}

There are currently no open bugs.


\agendaitem{Open floor}
\index{EAPI!usage when bumping}\index{EAPI!deprecation}\index{EAPI!1}
\index{EAPI!0}

scarabeus suggested the change "dev should use latest eapi when bumping"
to "dev must use latest eapi when bumping if not forbidden by eclasses".
He was asked to bring it up on the mailing lists, to get a better
definition of when what EAPI should be used.

ulm raised deprecation of EAPI 1 on request of patrick.  Arfrever argued
that backwards compatability is not an issue here, and that it can
greatly reduce code size / maintenance of eclasses when EAPI 0 and EAPI 1
are removed.  It was questioned whether removal of an EAPI really brings
that much benefits.  It seems eclasses can drop support for EAPIs, if
all consumers don't use them, which does not require complete removal of
the EAPI. It appears some packages use build-systems that require
EAPI 1.
