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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
\summary{2014}{4}{8}
\agendaitem{Vote on GLEP 63}
Council action last meeting tabled the vote on "\glep{63}: Gentoo GPG key
policies" because dilfridge, one of the authors, presented a shorter version
which removed the "howto" language and reduced it to just policy
(\wgoref{User:Dilfridge/GLEP:1001a}). The council has now had time to consider
this version and the general feeling was that the GLEP should concentrate only
on policy and move any questions of implementation to another document.
The council unanimously approved the shorter version.
\agendaitem{Use of ISO/IEC prefixes vs base-10}
\index{ISO prefixes}
References:
\begin{itemize}
\item
\agoref{gentoo-project}{1c2224a5a468ff854e73fc60d25f7dce}
\item
\agoref{gentoo-project}{6041b91cfa4c52c427ddbbd4f69607ff}
\end{itemize}
The council considered whether a) ISO/IEC prefixes, Ki=$2^{10}$, etc., should be
preferred over ISO base-10 prefixes, k=$10^3$, etc., or b) we should just
require unambiguous units in check-reqs.eclass, where KiB etc are base-2 and k
etc are base-10. Two proposal were brought forward by rich0. Proposal
2 was adopted:
\begin{quote}{\it
Whenever practical developers are required to use unit prefixes defined in
IEC 80000-13 (kB, KiB, etc) so that output is unambiguous. This does not
require maintainers to patch upstream code to change its behavior, but they
should be applied with code that originates in Gentoo.}
\end{quote}
\agendaitem{Recent events regarding new virtuals, masking by QA and then
unmasking}
\index{project!QA}\index{mailing lists}
References:
\begin{itemize}
\item \agoref{gentoo-project}{71c67cdf620f262b4f94765360c8c8c2}
\item http://article.gmane.org/gmane.linux.gentoo.devel/90800 (broken link)
\item \agoref{gentoo-project}{9bc36a643a969e165c6f7cf228f2745c}
\item \agoref{gentoo-project}{44defe3ffe0fc93ad754bd895ed0196c}
\end{itemize}
The council consider what action to take with regards to the controversy around
the recent introduction of virtual/libudev and virtual/libgudev. Roughly the
time sequence of events was as follows:
\begin{enumerate}
\item the eudev team was excluded from discussions about the virtuals
\item the virtuals were committed, leading to breakage for eudev
\item the virtuals were masked by a member of the QA team
\item the virtuals were unmasked by their maintainer without authorization
from QA.
\end{enumerate}
This led to two long discussion threads on gentoo-project@g.o and
gentoo-dev@g.o. dilfridge suggested the council take a position on five
points which address the systematic problems in the Gentoo community that led to
the above events. The council approved sending an email to the community
based on the following 4 of the 5 points:
{\it \begin{enumerate}
\item The council encourages teams maintaining central parts of Gentoo to
accept new developers as team members and teach them the required knowledge and
intricacies. We consider this important to ensure long-term continuity and
increase the bus factor in critical areas.
\item While it is any developer's choice not to participate on the gentoo-dev
and
gentoo-project mailing lists, they nevertheless serve as main communication
channels. If something has been discussed there, and then action has been taken,
the council regards ignorance of the discussion not as a good foundation for
protests against the actions.
\item
The council believes that a wide announcement and if needed discussion of
changes to central parts of Gentoo (as, e.g., system packages, profiles) should
be preferred. In particular, only informing "relevant people" makes no sense if
others will also be affected.
\item
The council strongly disapproves of any developers unilaterally reverting QA
team actions. While any future case decisions lie with QA and ComRel teams, the
council welcomes the idea of immediate sanctions in such a case. An individual
developer who disagrees with an action made in the name of QA, whether the
action is proper or not, MUST follow the escalation procedures set forth in GLEP
48, and is encouraged to work with QA, or eventually ComRel or the council to
settle any concerns. The council will follow up on any accusations of QA abuse
the same way as on any commit that is in conflict with a QA action.
\end{enumerate}}
One point urging QA to adopt policies regarding internal disagreements was
dropped since QA is in fact looking into the matter now.
\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}: Still no progress here. scarabeus said he would try to bug
Betelgeuse again.
\end{itemize}
\agendaitem{Open floor}
No issues were brought forward.
|
GitWeb