blob: 9b53368b40d96da1bab7dc0cb684bd74a5cd95a7 (
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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
\summary{2014}{3}{11}
\agendaitem{Vote on GLEP 63}
Previous council action approved in principle the policies outlined in
"\glep{63}: Gentoo GPG key policies", but delayed the vote for approval
until the final language was put in place. dilfridge presented a shorter
version of the GLEP which removed the "howto" language and reduced it to
just policy (\wgoref{User:Dilfridge/GLEP:1001a}). Discussion progressed to a
consensus that we should have only policy in the GLEP and a practical guide
should be a separate document which can be changed without council vote.
We tabled the vote until either an email vote (initiated by dilfridge) or
the next meeting.
\agendaitem{Ban on EAPI 1 and 2 should extend to updating EAPI in existing
ebuilds}
\index{EAPI!1}\index{EAPI!2}
Reference: \agoref{gentoo-project}{3a319600f3dc2dc42703a710155b2882}
The council considered the question of whether the ban on EAPIs 1 and 2 should
extended to updating EAPIs in *existing* ebuilds, and not just new ebuilds added
to the tree. mgorny noted that we need bumps from EAPI 0 to 1 because we need
an easy way to introduce slotting without the major rewriting of ebuild phases
than an EAPI 0 to 3 bump would require. After discussion, the council voted on
the following motion:
\vote{EAPI 1 and 2 are now banned. This ban should not only be limited to new
ebuilds, but should be extended to include updating EAPIs in *existing* ebuilds.
In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be
updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary
workaround.}{Carried with 4 yes, 1 no and 1 abstention.}
\agendaitem{Make all cosmetic repoman warnings fatal}
\index{package!app-portage/repoman}
Reference: \agoref{gentoo-project}{8fb1d8c0dd80e17cbb1fc633006f14b9}
The council considered the question of whether all repoman warnings should be
made fatal. Consensus was reached that this would lead to too many false
positives.
The motion failed with 4 no and 1 abstention.
\agendaitem{Adherence to FHS standards in Gentoo: putting config files int /etc}
\index{FHS}\index{udev rules}\index{configuration files!location}
References:
\begin{itemize}
\item \agoref{gentoo-project}{474fc6822dba50ccc6192c9f31d8024a}
\item \agoref{gentoo-project}{b59d8abb15e148b71d6e50180a2a27a7}
\item \url{http://devmanual.gentoo.org/general-concepts/filesystem/index.html}
\end{itemize}
The question of where config files should go was raised by patrick. The
council discussed whether it should be policy to put all config files in /etc.
However, what defines a config file is unclear because some packages, like udev or
eudev, put their *default* config files in /lib/udev/rules.d which are overridden
by the files in /etc/udev/rules.d. The former are not meant to be user-edited while
the later are. The council is okay with static config files living outside of /etc
while user-editable config files should be in /etc.
rich0 introduced the following motion:
\vote{Council does not feel additional policy required regarding config files
in /etc.
In particular packages that place config templates in /usr or /lib* and allow overriding
in /etc are fine. Specific issues not already discussed can be raised in future
meetings.}{Passed with 4 yes and 1 abstention.}
\agendaitem{Bugs with council involvement}
The council looked at two open bugs:
\begin{itemize}
\item \bug{503382}: dberkholz said he would upload those summaries soon.
\item \bug{477030}: There has been no progress. scarabeus was to nudge
betelgeuse for that summary.
\end{itemize}
\agendaitem{Open floor}
No issues were brought forward.
|
GitWeb