summaryrefslogtreecommitdiff
blob: f98cab0730c5924eb090e6c8b4aa98a1a1f85286 (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
\summary{2016}{9}{11}

\agendaitem{RFC: Eclasses and EAPI}
\index{eclasses}\index{EAPI!support in eclasses}

Reference: \agoref{gentoo-dev}{87e630b9da724c5c59060608aba596a9}

k\_f asked the council to discuss the requirement of a definition of supported
EAPIs in eclasses. The general consensus was that this not having a proper
check only created minor issues so far and the council leaves the
responsibility with the respective eclass maintainers and QA for a general
solution.

ulm mentioned his idea of splitting eclass in eclass libs and eclass, where
the eclass-libs contain the EAPI independent code in low level functions, where as
the actual eclasses themselves are EAPI dependent. This would be a very stable
and efficient architecture, but only in some niches eclasses are converting to
this e.g. perl.

Nothing has been decided on this matter by the council in this meeting.


\agendaitem{Bugs with council involvement}

\begin{itemize}
 \item 
 \bug{571490}: dilfridge follows this up
 \item
 \bug{590972}: Up to PM maintainers
 \item
 Various games.eclass related bugs: Decision have been made, up to community to
	implement
 \item
 \bug{565566}: Action from Infra missing, council will ping Infra for update
\end{itemize}

\agendaitem{Open floor}

No items were brought up.