Gentoo Archives: gentoo-commits

From: "Jorge Manuel B. S. Vicetto (jmbsvicetto)" <jmbsvicetto@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20110201-summary.txt 20110201.txt
Date: Thu, 03 Feb 2011 03:55:10
1 jmbsvicetto 11/02/03 03:54:59
3 Added: 20110201-summary.txt 20110201.txt
4 Log:
5 Added summary and log for the 20110201 meeting.
7 Revision Changes Path
8 1.1 xml/htdocs/proj/en/council/meeting-logs/20110201-summary.txt
10 file :
11 plain:
13 Index: 20110201-summary.txt
14 ===================================================================
15 Council 2011/02/01 meeting summary
16 ==================================
19 Agenda
20 ------
22 * roll call
24 * slacking arches
25 * EAPI-4 use in the tree
26 * GLEP 48 (QA)
28 * open bugs with council involvement
29 * next meeting date / chair
30 * open floor - listen to the community
33 Meeting
34 -------
36 * roll call
38 here:
40 Betelgeuse
41 bonsaikitten
42 chainsaw
43 ferringb
44 jmbsvicetto
45 scarabeus
46 wired
49 * items for discussion / vote
51 slacker arches
53 After a brief discussion about the ml thread, Jorge raised a few concerns
54 about the proposed policy increasing arch teams work and not addressing
55 the issue of lacking hardware.
56 It was decided that Tomas will write a proposal based on the ml thread
57 and that Jorge will try to talk to the arch teams and trustees to see
58 if there is or not a hardware issue and if so will try to address it.
61 EAPI-4
63 The council already approved and published the use of EAPI-4 for testing
64 ebuilds in the tree - mail sent by Alex.
65 While mentioning this point, Tomas recalled his question about changing
66 policy to have developers use the latest EAPI whenever possible, which
67 lead to a long discussion about deprecating EAPI versions and upgrade
68 paths, to be continued in the MLs.
71 GLEP48
73 There was a very long discussion about "authority" and "powers" and whether
74 QA should or not have be able to suspend developer's commit privileges.
75 No consensus was reached and as proposed in the agenda, the GLEP was sent
76 back to be updated with current requests and for further discussion on MLs.
79 Bugs assigned/cc'd to the council were pushed to the next meeting
83 * Next meeting chair
85 Tomas
87 * Next meeting date
89 Tuesday, 20110301 2000 UTC
92 * Open floor - listen to the community
94 No issue was brought forward to the council
98 1.1 xml/htdocs/proj/en/council/meeting-logs/20110201.txt
100 file :
101 plain:
103 Index: 20110201.txt
104 ===================================================================
105 20:00 <@Betelgeuse> \o/
106 20:00 <@jmbsvicetto> ping
107 20:00 <@bonsaikitten> /o\
108 20:01 * scarabeus winks
109 20:01 <@jmbsvicetto> sorry, but it took me a bit longer than expected to get home
110 20:01 * bonsaikitten is present but may lag a bit
111 20:02 <@jmbsvicetto> can we start?
112 20:02 <@ferringb> ask nicely
113 20:02 <@jmbsvicetto> so, rollcall
114 20:03 * Betelgeuse is rolling
115 20:03 <@scarabeus> i preffer rickroll
116 20:03 <@jmbsvicetto> bonsaikitten / Chainsaw / ferringb / wired: ping
117 20:03 * wired here
118 20:03 -!- wired changed the topic of #gentoo-council to: Next meeting: Now | | 20110111 Log and Summary now available | | Agenda:
119 20:04 <@bonsaikitten> jmbsvicetto: pong
120 20:05 <@jmbsvicetto> Chainsaw / ferringb: present?
121 20:05 <@jmbsvicetto> scarabeus: do you want to start the discussion about slacking arches?
122 20:05 <@ferringb> there abouts, yes
123 20:05 <@ferringb> bit laggy right now, working to remove said lag
124 20:05 <@scarabeus> ok so can i presume you slackers read the mails right?
125 20:06 <@scarabeus> so there was no strong opinion against the named removal of stable keywords so would you mind if i sum up nice policy text for next meeting?
126 20:06 <@scarabeus> that would be based on current state from that thread, or you guys are against the idea as is?
127 20:07 <@jmbsvicetto> scarabeus: I read it more as not being much discussion about it
128 20:07 <@jmbsvicetto> I don't really like the idea of maintainers dropping arches and breaking the tree for users
129 20:07 <@scarabeus> hm? i just guessed nobody was against my propositon
130 20:07 <@scarabeus> jmbsvicetto: i dont like having opened stable bugs for 1year+
131 20:08 <@jmbsvicetto> but some arches just can't take the load
132 20:08 <@scarabeus> this should minimalise them packages
133 20:08 <@scarabeus> up to the state where they can be catching up
134 20:08 <@jmbsvicetto> the issue is the more packages you drop, the more workload you give to arch teams
135 20:08 <@wired> jmbsvicetto: well maybe if their packages start going away they'll step up (users) and help with the stabilization
136 20:09 <@bonsaikitten> I think removing stable keywords is better than broken / obsolete versions
137 20:09 <@jmbsvicetto> perhaps it's time we evaluate 2 premises that condition the issue of the "slacker arches":
138 20:09 <@bonsaikitten> and re-stabling is not more work than stabling a new version I guess
139 20:09 <@wired> if we can get users to test instead of slow archs/HTs, then the maintainers could use that feedback and stabilize themselves
140 20:09 <@Chainsaw> jmbsvicetto: Yes, I'm here.
141 20:09 <@jmbsvicetto> 1. can we / want we to maintain support to arch X - which leads to, what arches do we want Gentoo to support
142 20:10 <@jmbsvicetto> 2. what hardware exists and can we get to enable the support for arch X
143 20:10 -!- WilliamH [~william@gentoo/developer/williamh] has joined #gentoo-council
144 20:11 <@jmbsvicetto> bonsaikitten: you may want to ask vapier, matsuu and a few others (arm and mips had to go / are going through this)
145 20:11 <@bonsaikitten> jmbsvicetto: those are extreme cases, if we're talking about pruning single libs and their revdeps it's a lot smaller than stabling "from scratch"
146 20:12 <@scarabeus> take look on ppc and games
147 20:12 <@scarabeus> once it was popular arch
148 20:12 <@scarabeus> but nowdays it quite is not :)
149 20:12 <@scarabeus> so this way automatic process would clear games for them
150 20:12 <@scarabeus> less work for the team in that area -> faster reaction on other bugs
151 20:12 <@scarabeus> (at least i hope)
152 20:13 <@jmbsvicetto> scarabeus: ppc is a good example. AFAIK, their primary development box had issues for a long time which affected their ability to do arch work
153 20:13 <@wired> guys
154 20:14 <@wired> if no user shows up to complain and/or help with late stabilizations, we really shouldn't worry too much about it. no users can do it, no devs can do it, drop the stable packages until someone is interested again
155 20:14 <@jmbsvicetto> scarabeus: anyway, was your proposal for you to write a policy based in the thread discussion so we could vote on it on the next meeting?
156 20:14 <@bonsaikitten> jmbsvicetto: so why don't they have minimal redundancy? that's an organizational issue independent of the rest
157 20:15 <@scarabeus> yes, to write something that is worth voting
158 20:15 <@jmbsvicetto> ok
159 20:15 <@scarabeus> if you would be at least indicted to vote on it ( so i dont waste my time :P)
160 20:15 <@Chainsaw> i hope to be able to do more for PPC64 soon.
161 20:15 * ferringb looks up
162 20:15 <@Chainsaw> As in, I've secured a Mac Mini to be my iPhone dock, and that will free up the dual G5 for a dedicated linux install.
163 20:15 <@bonsaikitten> scarabeus: +1 for me for writing it up
164 20:15 <@wired> scarabeus: write it please :)
165 20:15 <@scarabeus> ok
166 20:16 <@jmbsvicetto> if you don't mind, I propose that while you do that, I try to talk to the arch teams and trustees and see if there's any hardware needs or not
167 20:16 <@scarabeus> so lets move to next (i suppose others are quietly happy :P)
168 20:16 <@scarabeus> jmbsvicetto: noo i will kill you and dig your body in backyard :P sure go ahead :)
169 20:16 <@jmbsvicetto> scarabeus: I'll talk to you later about it
170 20:17 <@scarabeus> :))
171 20:17 <@jmbsvicetto> so, EAPI-4
172 20:17 <@wired> thats taken care of
173 20:17 <@jmbsvicetto> I guess there's nothing else for us to talk about it
174 20:17 <@jmbsvicetto> so, GLEP48?
175 20:17 <@scarabeus> well what is your opinion for my eapi question also on -dev
176 20:17 <@scarabeus> for that eapi4
177 20:18 <@scarabeus> i really hope you guys read that stuff i cc council on :D
178 20:18 <@jmbsvicetto> As it was pointed out in the project ml, it's still early for us to vote about it, but I have a few impressions / thoughts about it. So if you want we can talk a bit about it
179 20:18 <@jmbsvicetto> scarabeus: what question?
180 20:18 <@jmbsvicetto> scarabeus: wired already sent an email telling developers that EAPI-4 can be used in the tree
181 20:18 <@scarabeus> use latest when possible
182 20:19 <@jmbsvicetto> right, that's a different issue
183 20:19 <@Betelgeuse> scarabeus: I have suggested that for years.
184 20:19 <@wired> I agree with that
185 20:19 <@bonsaikitten> me mostly too
186 20:19 <@Betelgeuse> But yeah there's no strict policy anywhere.
187 20:19 <@jmbsvicetto> we started talking about that last week. IIRC, we decided to continue that discussion in the mls. Didn't we?
188 20:19 <@wired> Betelgeuse: if you really want a policy you need to make repoman die
189 20:19 <@jmbsvicetto> in any case, I agree with telling people to use the latest when possible
190 20:20 <@scarabeus> ok so again
191 20:20 <@jmbsvicetto> I don't agree we making it mandatory, though
192 20:20 <@Betelgeuse> wired: little gain
193 20:20 <@Betelgeuse> wired: unless you actually start planning deprecating some EAPIs
194 20:20 <@Betelgeuse> s/you/we/
195 20:20 <@jmbsvicetto> wired: so no repoman die
196 20:20 <@scarabeus> Betelgeuse: eapi1 is mostly dead
197 20:20 <@Betelgeuse> scarabeus: yeah
198 20:20 <@scarabeus>
199 20:20 <@scarabeus> eapi per eclass usage
200 20:21 <@jmbsvicetto> Betelgeuse: I think it's time we deprecate EAPI-1 and EAPO-2
201 20:21 <@jmbsvicetto> EAPI-2*
202 20:21 <@ferringb> scarabeus: use the appropriate eapi, rather than just forcing latest
203 20:21 <@bonsaikitten> Betelgeuse: I would like to see eapi1 and 2 deprecated, keep 3 as it is still very new
204 20:21 <@Betelgeuse> In general developers should be using new EAPIs because it results in better user experience.
205 20:21 <@bonsaikitten> deprecate 3 when we add next one
206 20:21 <@ferringb> why?
207 20:21 * ferringb is serious, lay out a beneficial reason please
208 20:21 <@wired> I'd like to see repoman die on EAPI 1-3. in a few months most ebuilds will be 4 and 0
209 20:21 <@scarabeus> ferringb: there is problem with that eclasses operate differently under eapis, namely py one, so less shit to remember
210 20:21 <@bonsaikitten> ferringb: eclasses get really messy when you can't have slot deps etc.
211 20:22 <@ferringb> bonsaikitten: eapi1 was slot deps
212 20:22 <@jmbsvicetto> scarabeus: do you have totals for all ebuilds?
213 20:22 <@ferringb> 2 was use
214 20:22 <@ferringb> doesn't address why 2 should be deprecated
215 20:22 <@scarabeus> jmbsvicetto: pinspect eapi_usage portdir
216 20:22 <@bonsaikitten> ferringb: less to remember
217 20:22 <@Betelgeuse> And less for new devs to learn.
218 20:22 <@ferringb> they're going to have to learn an eapi one way or another
219 20:23 <@wired> ferringb: because we have 4 now and there's absolutely no reason to use any of the others?
220 20:23 <@jmbsvicetto> ferringb: what's the benefit of using 2 when you can use 3?
221 20:23 <@jmbsvicetto> ferringb: 3 "simplifies" use of 2 with rpefix
222 20:23 <@jmbsvicetto> prefix*
223 20:23 <@ferringb> *cough*
224 20:23 <@ferringb> I know what the eapi's do. :)
225 20:23 <@jmbsvicetto> ferringb: and I agree with bonsaikitten about having less to remember
226 20:23 <@jmbsvicetto> ferringb: I don't doubt that ;)
227 20:23 <@ferringb> I just don't agree that's it's worth while going and punting them
228 20:24 <@bonsaikitten> ferringb: no active punting, just no new adding
229 20:24 <@scarabeus> ferringb: i never said proactively update ebuilds
230 20:24 <@bonsaikitten> it'll slowly smoke them out
231 20:24 <@scarabeus> ferringb: jsut version bumps/additions must use latest where possible
232 20:24 <@scarabeus> now most bumps in some areas keep eapi1
233 20:24 <@scarabeus> and some quite hidious code
234 20:24 <@scarabeus> because cp just works
235 20:24 <@scarabeus> :D
236 20:24 <@ferringb> an EAPI bump isn't going to make hideous code go away
237 20:24 <@ferringb> probably will breed it if it's an eclass imo
238 20:25 <@ferringb> people should use what's appropriate imo
239 20:25 <@wired> why would eapi1 ever be more appropriate than 4?
240 20:25 <@ferringb> 1 should go away imo, since frankly it's not worth using in light of 2
241 20:25 <@ferringb> 0 over 4
242 20:25 <@scarabeus> the same goes for 2 over 3
243 20:25 <@ferringb> 0 gets you backwards compatibility
244 20:25 <@wired> 0 is the exception
245 20:25 <@scarabeus> 0 is staying probably forever
246 20:25 <@ferringb> it's the same arguement however
247 20:25 <@scarabeus> or until we create global update mechanism
248 20:25 <@ferringb> there is no such thing, nor will there be
249 20:25 <@scarabeus> btw did you notice that with eapi0 it is nto possible to emerge portage right?
250 20:26 <@ferringb> scarabeus: that's portages problem
251 20:26 <@ferringb> look elsewhere
252 20:26 <@wired> that makes even 0 useless ;p
253 20:26 * ferringb konws his upgrade pathway for 0 isn't correct, although it was, and will be
254 20:26 <@scarabeus> ferringb: even pkgcore is not possible if i checked rite :)
255 20:26 <@ferringb> scarabeus: yeah, not my doing. as said, will be resolved.
256 20:26 <@scarabeus> we should probably enforce that too
257 20:27 <@ferringb> eh? enforce what exactly
258 20:27 <@scarabeus> :P
259 20:27 <@scarabeus> not really, but would be nice if someone made sure that it really works, from time to time :)
260 20:27 <@ferringb> in this discussion, define deprecate
261 20:27 <@ferringb> exact terms
262 20:28 <@ferringb> because even if 1/2 are annoying, they're actually useful as jumping points for upgrading
263 20:28 <@jmbsvicetto> ferringb: you also can't emerge pkgcore ;)
264 20:28 <@jmbsvicetto> with EAPI-0
265 20:28 <@wired> we really need another solution for upgrading anyway
266 20:28 <@scarabeus> i said so already :P
267 20:28 <@ferringb> jmbsvicetto: seriously, read up. already said I was going to fix that, and it was *not* my doing.
268 20:28 <@scarabeus> ferringb: how so?
269 20:28 <@scarabeus> ferringb: if base is kept at 0
270 20:28 <@scarabeus> rest can be even latest
271 20:28 <@jmbsvicetto> ferringb: sorry, was taking care of summary
272 20:29 <@scarabeus> it does not bork upgrade path
273 20:29 <@scarabeus> because you update your pm first
274 20:29 <@ferringb> scarabeus: if all of the base were zero, you'd be correct. base doesn't really stay at zero though
275 20:29 <@jmbsvicetto> ferringb: one way would be to require repoman --force to be able to commit ebuilds with EAPI-1 and EAPI-2
276 20:29 <@ferringb> and being able to map the upgrade pathway down to just 'base' is actually harder than you're thinking, due to various flags pulling in higher eapi's
277 20:29 <@ferringb> repoman needs to stop being the enforcer on this
278 20:30 <@ferringb> specifically, the holder of what is good/bad eapi wise
279 20:30 <@ferringb> push the whitelist into the tree, make portage use that
280 20:30 <@ferringb> avoids having to wait on releases every time
281 20:30 <@scarabeus> wlist make sense :)
282 20:31 <@ferringb> gives the same capabilities to overlays too.
283 20:31 * ferringb notes that's a seperate discussion for PM monkeys however
284 20:31 < Arfrever> Alternatively council could decide that upgrading of system using package manager supporting only EAPI <=1 is not supported.
285 20:32 <@ferringb> No.
286 20:32 <@scarabeus> Arfrever: ahem and what should people with old systems do
287 20:32 <@scarabeus> die?
288 20:32 <@ferringb> purpose of eapi was backwards compatibility
289 20:32 <@ferringb> throwing out backwards compatibility defeats the fucking purpose of eapi imo
290 20:32 < Arfrever> scarabeus: Reinstall Gentoo.
291 20:32 <@wired> what we really need is a way to allow old systems to upgrade their PM to the latest version no matter what the current state of the tree and its features is
292 20:33 <@ferringb> wired: which is actually a bit harder than you'd think because a PM isn't standalone
293 20:33 <@Betelgeuse> wired: There's a decision that upto 1 year upgrade path must work.
294 20:33 <@Betelgeuse> After that it's best effort.
295 20:33 <@wired> ferringb: understandable
296 20:33 <@Betelgeuse> Any way could we continue this outside agenda discussion at the end?
297 20:33 * ferringb nods
298 20:33 <@wired> ferringb: thats why freezing the tree before major changes sounds like a good idea to me.
299 20:33 <@ferringb> would like to see the specifics of "deprecate" nailed down also
300 20:33 <@wired> anyway lets move on
301 20:34 <@ferringb> as in "we do xyz to repoman, this is the usage scenario for verbump, revbumps, new pkgs, etc".
302 20:34 <@bonsaikitten> so we should discuss upgrade paths a bit more - ML maybe?
303 20:34 <@ferringb> yes, and keep in mind removing the support from the tree doesn't remove the PM's requirement to support it
304 20:35 <@ferringb> we've got the vdb to support, which can be years beyond the last appearance in the tree
305 20:35 <@scarabeus> ferringb: i never wanted pm to drop support
306 20:35 <@scarabeus> ferringb: just not allow it in portage for new shitz
307 20:36 <@jmbsvicetto> so, GLEP 48?
308 20:36 <@ferringb> scarabeus: point was, the support's there even if you decide to tell people "stop using it" ;)
309 20:36 <@ferringb> 48 meanwhile
310 20:36 <@jmbsvicetto> who wants to start?
311 20:36 <@scarabeus> meh diego is not around, so /me is considered as proposer
312 20:36 <@scarabeus> so start bashing me
313 20:37 <@scarabeus> lets separate it onto 2 parts one update lead role and recruitement
314 20:37 <@scarabeus> second change the wording for the resolving issues
315 20:37 <@scarabeus> so part one...
316 20:38 <@jmbsvicetto> I have some objections to a few points:
317 20:39 <@jmbsvicetto> 1. I don't agree with the policy that any majority vote of the QA team must lead to an election of the lead if that decision goes against a prior decision by the lead
318 20:39 <@jmbsvicetto> in my view this "conditions" the QA team members
319 20:40 <@scarabeus> ok agree that that section is confusing and probably should be removed
320 20:40 <@scarabeus> you already convinced me on pm for that one but i didnt want to change the patch 1 day before meeting (in hope guys actualy read it :P)
321 20:41 <@ferringb> where is that patch btw
322 20:41 <@jmbsvicetto> 2. as already discussed in the ml, permanent removal of commit privileges and loss of developer status is a DevRel issue and not a QA issue
323 20:41 <@scarabeus>
324 20:41 <@ferringb> thanks
325 20:41 <@scarabeus> for the point 2
326 20:41 <@wired> Im a bit concerned with all this, I feel we're handling the whole thing the wrong way
327 20:42 <@scarabeus> if we drop the last two added lines
328 20:42 <@scarabeus> + Resolution for this kind of issue is completely in hands of the QA team
329 20:42 <@scarabeus> + and only the Gentoo Council can revisit the case.
330 20:42 <@scarabeus> it would be better for you?
331 20:42 <@scarabeus> jmbsvicetto: ^
332 20:42 <@wired> as jmbsvicetto said, disciplinary actions of any kind belong to DevRel.
333 20:42 <@bonsaikitten> I don't see why QA needs some special powers
334 20:43 <@jmbsvicetto> scarabeus: yes
335 20:43 <@scarabeus> and add there Final resolution for the case is done by devrel team based on the QA analysis of the given issue.
336 20:43 <@Betelgeuse> scarabeus: For temporarily disabling access you don't need to mention infra.
337 20:43 <@Betelgeuse> scarabeus: There are others who can do it too
338 20:43 <@wired> bonsaikitten: exactly
339 20:43 <@wired> in effect all gentoo developers are informal QA members
340 20:43 <@scarabeus> Betelgeuse: ok so what should i write there (approperiate people)?
341 20:44 <@scarabeus> Betelgeuse: i know that in reality we will ping recruiters or infra or anyone with this priv:)
342 20:44 <@jmbsvicetto> scarabeus: I mentioned one idea to Diego that I see is no longer in your proposal
343 20:44 <@scarabeus> which one :)
344 20:45 <@Betelgeuse> scarabeus: I would prefer first try DevRel and if unresponsive then fallback on anyone with access
345 20:45 <@jmbsvicetto> scarabeus: As I told him, I'd add a note that "on exceptional cases, if the lead and deputy are not available, a request by at least 2 QA team members can be made to suspend commit privileges"
346 20:45 <@Betelgeuse> scarabeus: I am assumign DevRel continues to handle the follow up
347 20:45 <@scarabeus> either the QA lead or two members of the QA team can require the Infra team to temporarily suspend access to said developer
348 20:45 <@Betelgeuse> So no need to involve infra.
349 20:45 <@scarabeus> jmbsvicetto: ^ this is there
350 20:45 <@jmbsvicetto> Betelgeuse: I think for what they're proposing they should try to get anyone with that power. The first to respond takes care of it
351 20:46 <@jmbsvicetto> scarabeus: bah, I missed it
352 20:46 <@wired> jmbsvicetto: why? why do 2 QA team members have to ask. Any developer should be able to request that with proper evidence.
353 20:46 <@wired> why are we making this so damn political
354 20:46 <@bonsaikitten> yes
355 20:46 <@Betelgeuse> wired: possible too
356 20:46 <@ferringb> wired: yep
357 20:46 <@bonsaikitten> why is QA trying to encapsulate themselves from the rest
358 20:46 <@wired> we all do QA
359 20:46 <@ferringb> yes and no
360 20:46 <@scarabeus> with few exceptions
361 20:46 <@jmbsvicetto> scarabeus: you only mention it for the 2nd case. I'd have that the rule for both cases
362 20:46 <@Betelgeuse> wired: I presume the request here is to be able to force the hand of the people who can disable access.
363 20:47 <@scarabeus> i think that two points should be rewritten in one
364 20:47 <@scarabeus> with some adjusted wording from what i get from you so far
365 20:47 <@wired> Betelgeuse: by giving others "power" to do so?
366 20:47 <@wired> Betelgeuse: seems we're trying to fix this the wrong way
367 20:47 <@jmbsvicetto> wired: the idea is that this power was originally only available to the QA team lead. I'd say at least some of us think that might be too strict in some circumstances and are thus willing to relax the requirement.
368 20:48 <@ferringb> it's too strict
369 20:48 <@jmbsvicetto> wired: When I say 2 QA team members is to ensure that no single QA member can suspend commit privileges "on a whim"
370 20:48 <@wired> jmbsvicetto: you say that, but in reality anyone can request that
371 20:48 <@ferringb> doesn't work that way
372 20:48 <@ferringb> infra's not going to pop someones commit bit for a flagrant mistake
373 20:49 <@jmbsvicetto> wired: anyone can, but infra and devrel will only do it after an evaluation if it's just "anyone" asking
374 20:49 <@ferringb> when arfie broke portage in the tree, he still had his rights afterwards
375 20:49 <@ferringb> *arfrever, pardon
376 20:49 <@wired> well it was our mistake
377 20:49 <@jmbsvicetto> wired: If it's the QA team lead/deputy or 2 team members, they would do it immediately and then there would be an evaluation of that suspension
378 20:49 * ferringb doubts infra wants to be in the position of deciding the validity of a "temp suspend this dudes rights" also
379 20:49 <@wired> no one went to infra and said "hey, this guy is doing something nasty, lift his privs for a while"
380 20:49 <@wired> "then devrel will handle it"
381 20:50 <@ferringb> wired: hmm? if you're talking about the portage incident, actually we did
382 20:50 <@Betelgeuse> In that instance access was suspended.
383 20:50 <@ferringb> Betelgeuse: via devrel, if memory serves
384 20:50 <@Betelgeuse> But really I don't think we should be handling that case here now.
385 20:50 <@ferringb> well
386 20:51 <@wired> its all part of the same problem
387 20:51 <@Betelgeuse> Unless we want to do it publically without asking parties.
388 20:51 <@jmbsvicetto> wired: if you want, part of this whole debate is because at the time the QA team wasn't responsive and people got concerned that relying solely on the QA team lead was a bad idea - thus the attempt to "lift" the strictness of the requirement
389 20:51 <@ferringb> need scenarios if we're going to discuss this
390 20:51 <@jmbsvicetto> so my perspective is the following:
391 20:51 <@Betelgeuse> ferringb: My point was to rather keep it more abstract
392 20:52 <@ferringb> avoid names is your meaning
393 20:52 <@jmbsvicetto> for obvious cases where someone did a mistake, like leaving a broken script running that is causing havoc in the tree, we want to have someone with the ability to suspend access to limit the "damage" that script will do
394 20:52 <@ferringb> understand it, but discussing about hypotheticals doesn't gain us much when a lot of this QA discussion spawns from incidents like that ;)
395 20:52 <@ferringb> either way
396 20:53 <@ferringb> jmbsvicetto: agreed
397 20:53 <@ferringb> curious
398 20:53 <@ferringb> what exactly is devrel's mandate?
399 20:53 <@scarabeus> 2 cases a) accidental commit breakage b) blatant ignoring of NO and commiting stuff
400 20:53 <@ferringb> a definition, if you would
401 20:53 <@Betelgeuse> ferringb: devrel policy is approved by council
402 20:53 <@jmbsvicetto> for cases where there's a total disregard for policy and where a developer doesn't want to work with others and comply with distro rules, we want someone with the ability to suspend his commit privileges and then take that to the disciplinary body - devrel
403 20:53 <@Betelgeuse> ferringb: but it was suggested to turn that too into a GLEP which would be clearer
404 20:53 <@scarabeus> for a) i think suspend and then bugaboo should happen
405 20:53 <@scarabeus> b) suspend investigation + devrel
406 20:54 <@ferringb> Betelgeuse: it's a question of purposes
407 20:54 < Calchan> scarabeus, a) is a mistake, we all do mistakes, b) is devrel's problem
408 20:54 <@ferringb> Betelgeuse: mainly, I see qa/devrel intersecting, and not always in great ways
409 20:54 <@scarabeus> Calchan: violating qa rules is not devrel problem
410 20:54 <@jmbsvicetto> in the first case, as soon as the developer gets back and fixes his tools, the suspension will be lifted. In the second case, the suspension will be kept until there's a disciplinary review
411 20:54 < Calchan> scarabeus, you don't suspend somebody who's made an honest mistake or you're an ass
412 20:55 <@scarabeus> Calchan: we have rule where something must comply and if dev violates it he does not clash with other dev, he just pisses qa
413 20:55 <@scarabeus> Calchan: some guys script over night, so hell i would suspend breaking commit just to freeze it
414 20:55 < Calchan> and if it's not an honest mistake it's devrel matter
415 20:55 <@Betelgeuse> ferringb:
416 20:55 < Calchan> you guys are completely on the wrong track
417 20:56 <@Betelgeuse> ferringb: There's stuff like: "If the issue is deemed critical, the developer in question may have his or her access suspended while a vote takes place. In such situations, the Developer Relations lead may act without a vote of the remaining Developer Relations team; this power is granted by Council. "
418 20:56 <@Betelgeuse> Basically if we trust DevRel to work then we can just have anyone ask me (or any lead after me) to keep things going.
419 20:57 <@jmbsvicetto> Betelgeuse: I see no problem with GLEP48 giving the QA team the power to request the commit privileges suspension in the above cases. The first would be resolved when the developer stops his broken script and the second would be sent to devrel
420 20:57 <@wired> I still don't understand why we have to actually write a rule/definition/whatever for things like this.
421 20:58 <@ferringb> dunno. it's weird that devrel is basically responsible for punting the sucker, testing people coming in, and deciding what to do with folk who are misbehaving QA wise, but QA is basically stuck trying to sort out everything in between.
422 20:58 <@ferringb> and yes, not sure I agree w/ locking all of this down into rules... little bit of wiggle room is useful
423 20:58 <@Betelgeuse> ferringb: partly historical probably
424 20:58 <@ferringb> Betelgeuse: that devrel/qa schism I referenced there is what bugs me about the whole setup.
425 20:58 <@ferringb> not convinced it's best either
426 20:59 <@Betelgeuse> ferringb: Yeah it's not ideal.
427 20:59 <@ferringb> it basically defangs QA's ability to actually set standards
428 20:59 <@Betelgeuse> ferringb: But I don't think you can solve communication / co-operation with rule books.
429 20:59 <@ferringb> and leaves them asking nicely (or bribing/blackmailing if they're of my persusasion) to get things done
430 20:59 <@wired> QA is violated badly, breaks tree. team finds out, tells infra (always quick to respond, btw), infra suspends if necessary (if damage is continuous), issue escalates to devrel, devrel takes care of it
431 20:59 * ferringb didn't claim you could
432 20:59 <@wired> does this really need rules?
433 20:59 <@ferringb> wired: that's not how it works
434 20:59 <@wired> no, thats how I think it should work :)
435 21:00 <@jmbsvicetto> ferringb: all I would write in the revised GLEP48 is that "in extreme cases (we can discuss where to provide a list of examples or leave it just at this) the QA team lead, his deputy or 2 QA team members can ask anyone with the privileges to suspend a developer commit privileges."
436 21:00 <@ferringb> Eh
437 21:00 <@ferringb> feels like we're polishing a turd to be honest. not sure the structuring is wise, think that's the source of these issues.
438 21:01 <@wired> ferringb: my point, thank you :)
439 21:01 <@ferringb> formalizing the ability to punt someones access in an emergency is needed however
440 21:01 < Calchan> I don't know where you guys got the notion that the group setting the standard should be the same that polices it but it's not healthy, just think over that and it will all make sense to you
441 21:01 <@Betelgeuse> ferringb: It's already in DevRel policy.
442 21:01 <@Betelgeuse> ferringb: We can easily turn that into a GLEP too.
443 21:01 <@ferringb> Betelgeuse: I meant for QA
444 21:02 <@jmbsvicetto> Calchan: the current proposal, taking out the last part in the 2nd diff scarabeus presented, doesn't give QA disciplinary power
445 21:02 <@ferringb> Calchan: yes and no, but yes, get your point.
446 21:02 <@wired> I recommend we talk about this a bit more in the ML
447 21:02 <@jmbsvicetto> wired: we have to ;)
448 21:02 <@Betelgeuse> ferringb: I was trying to also communicate that both should be worked in tandem.
449 21:02 <@jmbsvicetto> wired: this was never in a state where the council could decided about it on this meeting
450 21:02 <@Betelgeuse> ferringb: Probably gives the best result.
451 21:03 < Calchan> jmbsvicetto, why bother adding more crap to existing crap then, why not fixing the crap that's already in place if it's actually needed
452 21:03 < c1pher> Calchan: I'm not sure if I'm the only one that's confused, but to which parts are you refering?
453 21:03 <@jmbsvicetto> Calchan: the only point of this is to "entrust" the QA team with the ability to quickly react in cases something extreme is happening in the tree
454 21:04 < Calchan> jmbsvicetto, isn't that supposed to be infra's responsibility?
455 21:04 <@jmbsvicetto> Calchan: I see it as just ensuring another team (the one which is entrusted with the status of the tree) has the tools to act on emergencies. Nothing more than that
456 21:04 <@bonsaikitten> i guess we disagree if there even is a problem
457 21:05 < Calchan> again, infra's job
458 21:05 <@bonsaikitten> also what the problem is, and if we need to fix it
459 21:05 <@wired> Calchan: I've been trying(and failing) to point that out
460 21:05 <@jmbsvicetto> Calchan: infra might not have noticed it and in some cases infra might not be ready to intervene by considering it's "open to interpretation"
461 21:06 < Calchan> jmbsvicetto, infra is always available, more than QA at least
462 21:06 < Calchan> and the interpretation is true, but they are gnetoo users too
463 21:06 <@jmbsvicetto> in any case, I haven't seen anyone asking for the QA team to have access to ldap to suspend / revoke commit privileges. This is all about them having the authority to talk with those having the tools to suspend access
464 21:07 < Calchan> jmbsvicetto, don't all developers have authority to talk to infra/devrel/council/etc...?
465 21:07 <@jmbsvicetto> Calchan: I didn't say infra wasn't avilable, I said they might not have noticed it
466 21:07 <@jmbsvicetto> Calchan: one thing is being able to talk to, another is having "delegated powers" to do so
467 21:08 < Calchan> what are you talking about? devs don't need anybody's authorization to talk!
468 21:09 <@scarabeus> Calchan: we are not talking about "hey developer x might done something would you look to it?" but "Suspend X access, more informations to follow kthx"
469 21:09 <@jmbsvicetto> Calchan: no, but the goal was give QA the authority to "tell" infra/devrel to suspend, while developers can only "ask" them to do it
470 21:09 <@wired> i think the real problem here is "authority"
471 21:10 < Calchan> jmbsvicetto, and what I'm saying is that if you don't trust infra to suspend some dev's access when *anybody* tell them that something bad is happening to the tree then you need to fire them all and set up a new team
472 21:10 <@Chainsaw> I do believe the way the "distfiles go in dev.g.o/~you" edict was handed down is problematic.
473 21:11 <@bonsaikitten> Chainsaw: silly thing, that
474 21:11 <@Betelgeuse> Calchan: infra members are not required to understand ebuild development
475 21:11 <@Betelgeuse> But in general I don't see problems in automatically pulling the switch pending eval is multiple QA members ask.
476 21:12 <@jmbsvicetto> nor are they "obliged" to suspend someone's commit privileges just because Jorge went there running and saying evil Tomas got his commit script running to get KDE-7 in the tree and it's breaking Manifests in kde-base/ and package.mask
477 21:13 < Calchan> jmbsvicetto, how about you talk to them before you make this kind of assumption?
478 21:14 <@jmbsvicetto> To infra or to the other developer?
479 21:14 < Calchan> infra
480 21:14 <@jmbsvicetto> I've talked with infra members about this issue before
481 21:14 <@jmbsvicetto> and I'm not complaining about infra, quite the contrary
482 21:15 <@jmbsvicetto> so, let's push GLEP-48 back to the mls?
483 21:15 <@wired> yes please
484 21:16 <@jmbsvicetto> Do we want to over the bugs? I'd prefer to leave that for next meeting
485 21:16 <@Betelgeuse> was always the plan any way :)
486 21:17 <@scarabeus> ha ha :)
487 21:17 <@jmbsvicetto> Seems like no one is interested on bugs, so who wants to chair next meeting and when shall we have it?
488 21:17 <@scarabeus> ayway i will update teh text with what we said here and sent it again to -dev
489 21:17 <@Betelgeuse> scarabeus: good context :)
490 21:18 <@scarabeus> jmbsvicetto: in 4 days around 18:00 presence will be around 5 out of 7 members O:)
491 21:18 <@scarabeus> or something :D
492 21:18 <@jmbsvicetto> Shall we have the next meeting at 20110301 2000 UTC?
493 21:18 <@bonsaikitten> scarabeus: and a combined alc level of ~3% ;)
494 21:19 <@jmbsvicetto> scarabeus: hehe - that'll be an "extra" meeting ;)
495 21:19 <@scarabeus> jmbsvicetto: agreed on the date
496 21:19 <@Chainsaw> jmbsvicetto: What day of the week is that please?
497 21:19 <@jmbsvicetto> Tuesday
498 21:19 <@scarabeus> same as this
499 21:19 <@Betelgeuse> wfm
500 21:19 <@wired> wfm2
501 21:19 <@Chainsaw> Yes, that works for me.
502 21:20 <@jmbsvicetto> any volunteers to chair the meeting?
503 21:20 <@Chainsaw> It's my birthday, so there must be cake.
504 21:20 <@Chainsaw> But other then that, all good :)
505 21:20 <@jmbsvicetto> ferringb: ^^
506 21:20 <@ferringb> bastards
507 21:20 <@jmbsvicetto> Chainsaw: hehe
508 21:20 <@ferringb> jmbsvicetto: answer your question? ;)
509 21:20 <@ferringb> yeah, can swing it
510 21:20 <@jmbsvicetto> is that for FOSDEM or meeting date? :P
511 21:20 <@wired> Chainsaw: woohoo, we'll have cake ;p
512 21:20 <@ferringb> may need to adjust it, but won't know for a week or so
513 21:21 <@jmbsvicetto> ferringb: if you'd prefer a different date / time, can you make a suggestion?
514 21:21 <@jmbsvicetto> alright, I see no one is too interested, so I'll chair next meeting too
515 21:22 <@jmbsvicetto> ferringb: want to suggest a different date or can we go forward with Tuesday, 20110301 2000 UTC?
516 21:22 <@scarabeus> jmbsvicetto: ferringb look like he agreed to that chair, nt to the date :P
517 21:22 <@scarabeus> *looks
518 21:22 * ferringb didn't agree to chair
519 21:22 <@scarabeus> :D
520 21:22 <@ferringb> I tried that one, I sucked at it
521 21:22 * scarabeus chuckless
522 21:22 <@ferringb> *once
523 21:23 <@scarabeus> jmbsvicetto: anyway i can chair it so you dont do it in row
524 21:23 <@ferringb> jmbsvicetto: proceed w/ march 1st, as said, I may need to change it, but I won't know till it gets closer
525 21:23 <@jmbsvicetto> ok
526 21:23 <@ferringb> jmbsvicetto: or I'll just send a proxy, since I've not yet ;)
527 21:23 <@jmbsvicetto> scarabeus: you want to chair it or will i?
528 21:23 <@scarabeus> ferringb: soome pretty girl please, if Chainsaw has the birthday so we have it cosy
529 21:23 <@jmbsvicetto> I*
530 21:23 <@wired> ferringb: we can always push it a few days if you can't make it :)
531 21:23 <@scarabeus> jmbsvicetto: write me
532 21:23 <@jmbsvicetto> ok
533 21:24 <@jmbsvicetto> so, let's open the floor to the community
534 21:24 <@jmbsvicetto> Anyone has any issues or questions to bring to the attention of the council?
535 21:25 <@scarabeus> hm I am out of icecream could foundation do something about it? i am heavily addicted to chocolate icecream... might be worth bug :P
536 21:25 <@bonsaikitten> scarabeus: you sound fat
537 21:25 <@bonsaikitten> :D
538 21:25 <@scarabeus> i am all slim and sexy!
539 21:25 <@scarabeus> well at least the first part is true
540 21:26 <@bonsaikitten> I'm leaner than your steak! HA HA
541 21:26 <@scarabeus> :))
542 21:26 <@jmbsvicetto> I sense some discrimination against geometric figures like the circle :P
543 21:27 <@bonsaikitten> no, we need differences to enjoy what we have
544 21:27 <@wired> i have an issue
545 21:27 <@wired> FOSDEM in 4 days!
546 21:27 <@jmbsvicetto> hehe
547 21:28 <@wired> assuming my flight is not cancel;ed anyway
548 21:28 <@jmbsvicetto> wired: I have a thing tonight, work tomorrow and start my travel to FOSDEM on Thursday ;)
549 21:28 <@wired> heh
550 21:29 <@jmbsvicetto> oh and I still need to write some slides :>
551 21:29 <@scarabeus> ook i guess i can safely disappear and take look what sabayon guys pinged about :)
552 21:29 <@jmbsvicetto> ok, it seems like there's no issues from the community
553 21:29 <@jmbsvicetto> I'll wait a bit more and close the meeting in around 30 minutes
554 21:29 * ferringb is back to work already
555 21:30 <@ferringb> avail off/on with some lag for the next half hour or so
556 21:30 <@wired> jmbsvicetto: really? just end the meeting now :P
557 21:30 <@jmbsvicetto> scarabeus / wired: Did you get my wave invitation? Mind checking the summary there
558 21:30 <@wired> jmbsvicetto: got it, reading it
559 21:30 <@jmbsvicetto> I hereby close this meeting"
560 21:31 <@jmbsvicetto> Anyone intersted has 30 minutes to raise an issue before I commit the summary / logs
561 21:31 < hwoarang> re arch teams
562 21:32 <@wired> jmbsvicetto: looks good
563 21:32 < hwoarang> bare in mind that amd64 is at stake too
564 21:33 <@scarabeus> looks fine
565 21:33 < hwoarang> jmbsvicetto: maybe you want to contact *all* the arch teams
566 21:33 <@jmbsvicetto> hwoarang: I do
567 21:33 < hwoarang> thank u
568 21:33 <@jmbsvicetto> hwoarang: I wasn't planning to exclude any team
569 21:33 < hwoarang> ok didn't realize that
570 21:34 <@jmbsvicetto> I'll try to send an email to all teams alias
571 21:35 <@jmbsvicetto> +tonight