\summary{2008}{9}{25}

Agenda call: \agoref{gentoo-dev}{e56a4be3a7fdfd47ce26583dd32f0f69}

Agenda announcement: \agoref{gentoo-dev}{26d869ad968c831e4e8cc08d66a188ee}


\agendaitem{EAPI 2}
\index{EAPI!2}\index{EAPI!2!approval}

On the procedure side, it was agreed to 
\begin{itemize}
 \item
 put a generated copy (preferably HTML) in the PMS project webspace. 
    People who want to refer to an EAPI 2 reference don't necessarily 
    want to install all the dependencies to build it.
 \item
 tag the git repository something like 
    eapi-\$EAPI-approved-\$DATE.
\end{itemize}
With that in mind, EAPI 2 was approved by vote.


\agendaitem{PROPERTIES in the metadata cache}
\index{PROPERTIES}\index{metadata cache}

Does the council need to approve metadata cache content changes (i.e. changes 
to the list of cached fields)?

Since it's related to the EAPI, this should be another issue that 
package-manager developers resolve amongst themselves and only present to 
council if they can't agree. The package manager developers agree on adding 
PROPERTIES to the cache as a value that package managers can ignore, so it will 
be added.


\agendaitem{PROPERTIES=interactive in ebuilds}
\index{ebuilds!interactive}\index{PROPERTIES}

Does the council need to approve changes of the global variables used in 
ebuilds?

Result: This is a retroactive, backwards-compatible EAPI change and thus is 
handled the same as any other EAPI change -- it requires council approval.

\vote{Approve PROPERTIES=interactive for use in ebuilds}{Approved.}