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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
\summary{2008}{5}{8}
Agenda call: \agoref{gentoo-dev}{bd9a171d7303bf1299a4c307f7b6ddcf}
\agendaitem{New process}
The last few meetings have dragged out for hours unnecessarily. This time, we
tried moderating the channel during discussion of each topic, then temporarily
opening the floor for that topic before a vote so anyone could contribute.
Here's the time breakdown:
\begin{center}
\begin{tabular}{c|c|c|c}
start & end & mode & duration \\ \hline
20:00 & 20:30 & closed & 30min \\
20:30 & 20:46 & open & 16min \\
20:46 & 20:56 & closed & 10min \\
20:56 & 21:14 & open & 18min \\
21:14 & 21:46 & closed & 32min \\
21:46 & 22:09 & open & 23min \\
22:09 & 22:42 & closed & 33min \\
22:42 & & \multicolumn{2}{c}{open floor}
\end{tabular}
\end{center}
Total before open floor: 105 minutes closed, 57 minutes open.
Optimistically, we could have saved an hour if the channel was moderated
throughout the meeting. That's unlikely to be the case in reality, because we
would be redirecting people's comments from queries into the channel.
Should we keep it moderated until the final open floor? Should we have
an open "backchannel"?
\agendaitem{Document of being an active developer}
\index{developer certificate}\index{trustees}\index{project!devrel}
\dev{araujo} made http://dev.gentoo.org/$\sim$araujo/gcert1.pdf in Scribus.
He'd like to ask for approval of this design and discuss the script, in
particular its infrastructure requirements.
Suggestions on the certificate content were:
\begin{itemize}
\item Add a title to the top: "Developer Certification"
\item Add devrel contact info (general devrel email address)\footnote{Whether
trustees or devrel should be the proper contact was a matter of discussion. In
the end, devrel was seen as responsible for human resources and thereby
responsible for it.}
\item Add a link to the (devrel-maintained) user information web page
\item Add start and end dates of developer status on the (devrel-maintained)
retired developers web page
\item Add a sentence saying e.g. "This certifies that XXX was a Gentoo
developer from START_DATE to TODAY_DATE."
The point is to avoid implying that the developer is certified forever, or will
be a developer in the future. This information should be gotten from LDAP, for
example using python-ldap. One could base this script on devrel's slacker
script.
\end{itemize}
It is unsure how signatures on the document are going to happen, but one option
is to keep a GPG-encrypted image of a signature and decrypt it on-demand for
certificate creation. This should be discussed with the person doing the
signing.
\agendaitem{Slacker arches}
\index{arches!slacking}
There were no updates on this topic.
\agendaitem{When are ChangeLog entries required?}
\index{ChangeLog}
This question mainly relates to arch stabilizations.
The consensus was that ChangeLog entries even for arch stabilizations provide
valuable information that is unique without network access and more accessible
than CVS logs even with network access. So, ChangeLog entries are always
required. If you aren't making them now, fix your script to call echangelog.
Some people were curious what proportion of space ChangeLogs take in the tree,
but most people didn't think that was relevant.
\dev{welp} suggested making a changelog message part of repoman commit.
It would be helpful for the QA team to help with checking for and enforcing
ChangeLog messages. If that doesn't help matters, the council may have to take
action.
\agendaitem{Can the council help fewer bugs get ignored by arm/sh/s390 teams?}
\index{arch!arm}\index{arch!sh}\index{arch!s390}\index{arches!slacking}
The work happens, but \dev{leio} says it is not communicated to anyone and has
no relationship to whether bugs are open. We need to understand the workflow of
undermanned arch teams and see whether there's anything we can help improve.
Possibly improving recuitment -- we should add a good, motivating
staffing-needs entry.
\agendaitem{PMS: Are versions allowed to have more than 8 digits?}
\index{versions!number of digits}
References:
\begin{itemize}
\item
\agoref{gentoo-dev}{db2f5c09c2c0c8b042ca3d0dcec7cdaf}
\item
\bug{188449}
\end{itemize}
What do various package managers / tools support? \package{sys-apps/portage},
\package{sys-apps/pkgcore}, and \package{sys-apps/paludis} all handle more
than 8 digits. \package{app-portage/portage-utils} does not but could be fixed
to use longs instead of ints, with some loss of performance (magnitude unclear).
versionator.eclass \index{eclass!versionator} also needs fixing for >8 digits.
Apparently [ ]-style tests break with large numbers, but [[ ]] works. We have
to be careful which tests are getting used anywhere large versions are compared.
The council generally favored allowing versions to have $<=18$ digits. This
allows them to fit into 64 bits (18 signed digits or 19 unsigned) and gives them
an upper bound, which some implementations of version parsing could find useful.
We voted to do more research and testing, specifically to ask the package
maintainers with extremely long PVs whether they were needed and to test the
impact of extending versionator.eclass. The involved packages are:
\begin{itemize}
\item \package{sys-process/fuser-bsd}
\item \package{sys-apps/net-tools}
\item \package{sys-apps/gradm}
\item \package{net-im/ntame}
\item \package{media-video/captury}
\item \package{media-libs/libcaptury}
\item \package{media-libs/capseo}
\item \package{sys-block/btrace}
\item \package{www-apache/mod_depends}
\item \package{net-wireless/rt2500}
\item \package{sys-fs/unionfs}
\end{itemize}
\agendaitem{Enforced retirement}
\index{retirement!enforced}\index{project!devrel}\index{council!appeal process}
The meeting had already gone 2.5 hours and we were short multiple council
members because of the late hour in their timezone, or broken hardware in the
case of \dev{jokey}. Because of the urgency of getting this resolved, we
decided it couldn't wait for next month's meeting and scheduled a special
session for next week at the same time.
The topics to be covered here were:
\begin{itemize}
\item
What was the council's role in the recent enforced retirement of three
developers?
\item
Why does the council permit such actions in apparent violation of Gentoo's
policy of openness?
\item
What is the council's role in an appeal?
\end{itemize}
\agendaitem{Open floor}
\index{retirement!appeal}
Some people thought that we were going to make a final decision on the above
appeals today, because the agenda was insufficiently clear on that. That was
not the case. What we intended to do was explain why we can take the appeal and
then figure out the process for it because we haven't done any appeals before.
|
GitWeb