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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
Summary of Gentoo council meeting 8 April 2014
Agenda
======
1. Roll call
2. Open issues - vote on GLEP 63
3. Use of ISO/IEC prefixes vs base-10
4. Discussion of the recent controversy regarding new libudev and libgudev
virtuals, their masking by QA member and subsequent unauthorized unmasking
by their maintainer.
5. Bugs assigned to Council
6. Open floor
1. Roll call
============
Present: blueness dberkholz dilfridge rich0 ulm williamh scarabeus
2. Open issues - vote on GLEP 63
================================
Council action last meeting tabled the vote on "GLEP 63: Gentoo GPG key
policies" [1] because dilfridge, one of the authors, presented a shorter version
which removed the "howto" language and reduced it to just policy [2]. 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. [2]
Ref:
[1] https://wiki.gentoo.org/wiki/GLEP:63
[2] https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a
3. Use of ISO/IEC prefixes vs base-10
=========================================================================
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 [1]. Two proposal were brought forward by rich0 [2]. Proposal 2 was
adopted:
"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."
Ref:
[1] http://article.gmane.org/gmane.linux.gentoo.project/3428
[2] http://article.gmane.org/gmane.linux.gentoo.project/3438
4. Recent events regarding new virtuals, masking by QA and then unmasking
=========================================================================
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:
1) the eudev team was excluded from discussions about the virtuals
2) the virtuals were committed, leading to breakage for eudev
3) the virtuals were masked by a member of the QA team
4) the vertuals were unmasked by their maintainer without authorization
from QA.
This led to two long discussion threads on gentoo-project@g.o [1] and
gentoo-dev@g.o [2]. 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 [3]. The council approved sending an email to the community
based on the following 4 of the 5 points:
* 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.
* 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.
* 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.
* 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.
One point urging QA to adopt policies regarding internal disagreements was
dropped since QA is in fact looking into the matter now [4].
Ref.
[1] http://article.gmane.org/gmane.linux.gentoo.project/3417
[2] http://article.gmane.org/gmane.linux.gentoo.devel/90800
[3] http://article.gmane.org/gmane.linux.gentoo.project/3474
[4] http://article.gmane.org/gmane.linux.gentoo.project/3522
5. Bugs assigned to Council
===========================
The council looked at two open bugs:
a) Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council
meetings
dberkholz said he would upload those summaries soon.
b) Bug #477030 - Missing summary for 20130611 council meeting
Still no progress here. scarabeus said he would try to bug Betelgeuse again.
6. Open floor
=============
No issues were brought forward.
Summary submitted by Anthony G. Basile <blueness@gentoo.org>
|
GitWeb