blob: 92fd6373a5976dc809677e179ed795505c7c5345 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
\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.}
|
GitWeb
