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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
|
Quick summary
=============
Active-developer document: We reviewed it and made some suggestions for
improving both the document and the online developer list (adding
dates).
ChangeLog entries: Always required. If you aren't making them now, fix
your script to call echangelog.
Ignored arch-team bugs: What's the workflow for undermanned arch teams?
Can we improve it?
8-digit versions: Ask package maintainers with extremely long PVs
whether they were needed and test the impact of extending
versionator.eclass. Make decision once this data is available.
Enforced retirement: After 2.5 hours on the previous topics, people had
to go to sleep and jokey's computer broke. Instead of waiting till the
next regular meeting, because of its urgency, we scheduled a special
session next week at the same time. The appeals will *not* be decided
then -- it's about figuring out the validity and the process.
New meeting process: 105 minutes were closed and 57 were open. It might
save some time if we always moderated, but it won't cut it in half.
Should we keep doing this, or modify it a little to have a moderated
#-council and open backchannel?
Roll call
=========
(here, proxy [by whom] or slacker?)
amne slacker [30 minutes late]
betelgeuse here
dberkholz here
flameeyes here
lu_zero here
vapier proxy [solar]
jokey here
We gave amne 15 minutes to show up before getting a slacker mark.
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:
2000-2030: closed, 30 min
2030-2046: open, 16 min
2046-2056: closed, 10 min
2056-2114: open, 18 min
2114-2146: closed, 32 min
2146-2209: open, 23 min
2209-2242: closed, 33 min
2242- : open floor
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'd 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"?
Updates to last month's topics
==============================
http://www.gentoo.org/proj/en/council/meeting-logs/20080410-summary.txt
Document of being an active developer
-------------------------------------
Last month:
No updates
Updates:
araujo made http://dev.gentoo.org/~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 certificate content:
-Add title to the top: "Developer Certification"
-Add devrel contact info (general devrel email address)
-Add link to devrel userinfo page
-Add start and end dates to devrel retired developers page
-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.
The information should be gotten from LDAP, for example using
python-ldap. Could base this script on devrel's slacker script.
It's unsure how signatures 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.
Slacker arches
--------------
4 months ago:
vapier will work on rich0's suggestion and repost it for
discussion on -dev ML
2 months ago:
vapier said he was going to work on it that weekend.
Last month:
No updates
Updates:
New topics
==========
When are ChangeLog entries required?
------------------------------------
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.
Some people were curious what proportion of space ChangeLogs take in
the tree, but most people didn't think that was relevant.
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.
Can the council help fewer bugs get ignored by arm/sh/s390 teams?
-----------------------------------------------------------------
The work happens, but Mart says it's 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 -- add a good, motivating
staffing-needs entry.
PMS: Are versions allowed to have more than 8 digits?
-----------------------------------------------------
http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml
https://bugs.gentoo.org/show_bug.cgi?id=188449
What do various PMs/tools support? Portage, Pkgcore, Paludis all
handle >8. portage-utils does not but could be fixed to use longs
instead of ints, with some loss of performance (magnitude unclear).
versionator.eclass also needs fixing for >8 digits.
Apparently [ ]-style tests break with large numbers, but [[ ]]
works. 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:
sys-process/fuser-bsd
sys-apps/net-tools
sys-apps/gradm
net-im/ntame
media-video/captury
media-libs/libcaptury
media-libs/capseo
sys-block/btrace
www-apache/mod_depends
net-wireless/rt2500
sys-fs/unionfs
Enforced retirement
-------------------
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 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.
Open floor
----------
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