20:00 <@Betelgeuse> \o/ 20:00 <@jmbsvicetto> ping 20:00 <@bonsaikitten> /o\ 20:01 * scarabeus winks 20:01 <@jmbsvicetto> sorry, but it took me a bit longer than expected to get home 20:01 * bonsaikitten is present but may lag a bit 20:02 <@jmbsvicetto> can we start? 20:02 <@ferringb> ask nicely 20:02 <@jmbsvicetto> so, rollcall 20:03 * Betelgeuse is rolling 20:03 <@scarabeus> i preffer rickroll 20:03 <@jmbsvicetto> bonsaikitten / Chainsaw / ferringb / wired: ping 20:03 * wired here 20:03 -!- wired changed the topic of #gentoo-council to: Next meeting: Now | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | 20110111 Log and Summary now available | http://www.gentoo.org/proj/en/council/ | Agenda: http://tinyurl.com/63vfzla 20:04 <@bonsaikitten> jmbsvicetto: pong 20:05 <@jmbsvicetto> Chainsaw / ferringb: present? 20:05 <@jmbsvicetto> scarabeus: do you want to start the discussion about slacking arches? 20:05 <@ferringb> there abouts, yes 20:05 <@ferringb> bit laggy right now, working to remove said lag 20:05 <@scarabeus> ok so can i presume you slackers read the mails right? 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? 20:06 <@scarabeus> that would be based on current state from that thread, or you guys are against the idea as is? 20:07 <@jmbsvicetto> scarabeus: I read it more as not being much discussion about it 20:07 <@jmbsvicetto> I don't really like the idea of maintainers dropping arches and breaking the tree for users 20:07 <@scarabeus> hm? i just guessed nobody was against my propositon 20:07 <@scarabeus> jmbsvicetto: i dont like having opened stable bugs for 1year+ 20:08 <@jmbsvicetto> but some arches just can't take the load 20:08 <@scarabeus> this should minimalise them packages 20:08 <@scarabeus> up to the state where they can be catching up 20:08 <@jmbsvicetto> the issue is the more packages you drop, the more workload you give to arch teams 20:08 <@wired> jmbsvicetto: well maybe if their packages start going away they'll step up (users) and help with the stabilization 20:09 <@bonsaikitten> I think removing stable keywords is better than broken / obsolete versions 20:09 <@jmbsvicetto> perhaps it's time we evaluate 2 premises that condition the issue of the "slacker arches": 20:09 <@bonsaikitten> and re-stabling is not more work than stabling a new version I guess 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 20:09 <@Chainsaw> jmbsvicetto: Yes, I'm here. 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 20:10 <@jmbsvicetto> 2. what hardware exists and can we get to enable the support for arch X 20:10 -!- WilliamH [~william@gentoo/developer/williamh] has joined #gentoo-council 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) 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" 20:12 <@scarabeus> take look on ppc and games 20:12 <@scarabeus> once it was popular arch 20:12 <@scarabeus> but nowdays it quite is not :) 20:12 <@scarabeus> so this way automatic process would clear games for them 20:12 <@scarabeus> less work for the team in that area -> faster reaction on other bugs 20:12 <@scarabeus> (at least i hope) 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 20:13 <@wired> guys 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 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? 20:14 <@bonsaikitten> jmbsvicetto: so why don't they have minimal redundancy? that's an organizational issue independent of the rest 20:15 <@scarabeus> yes, to write something that is worth voting 20:15 <@jmbsvicetto> ok 20:15 <@scarabeus> if you would be at least indicted to vote on it ( so i dont waste my time :P) 20:15 <@Chainsaw> i hope to be able to do more for PPC64 soon. 20:15 * ferringb looks up 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. 20:15 <@bonsaikitten> scarabeus: +1 for me for writing it up 20:15 <@wired> scarabeus: write it please :) 20:15 <@scarabeus> ok 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 20:16 <@scarabeus> so lets move to next (i suppose others are quietly happy :P) 20:16 <@scarabeus> jmbsvicetto: noo i will kill you and dig your body in backyard :P sure go ahead :) 20:16 <@jmbsvicetto> scarabeus: I'll talk to you later about it 20:17 <@scarabeus> :)) 20:17 <@jmbsvicetto> so, EAPI-4 20:17 <@wired> thats taken care of 20:17 <@jmbsvicetto> I guess there's nothing else for us to talk about it 20:17 <@jmbsvicetto> so, GLEP48? 20:17 <@scarabeus> well what is your opinion for my eapi question also on -dev 20:17 <@scarabeus> for that eapi4 20:18 <@scarabeus> i really hope you guys read that stuff i cc council on :D 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 20:18 <@jmbsvicetto> scarabeus: what question? 20:18 <@jmbsvicetto> scarabeus: wired already sent an email telling developers that EAPI-4 can be used in the tree 20:18 <@scarabeus> use latest when possible 20:19 <@jmbsvicetto> right, that's a different issue 20:19 <@Betelgeuse> scarabeus: I have suggested that for years. 20:19 <@wired> I agree with that 20:19 <@bonsaikitten> me mostly too 20:19 <@Betelgeuse> But yeah there's no strict policy anywhere. 20:19 <@jmbsvicetto> we started talking about that last week. IIRC, we decided to continue that discussion in the mls. Didn't we? 20:19 <@wired> Betelgeuse: if you really want a policy you need to make repoman die 20:19 <@jmbsvicetto> in any case, I agree with telling people to use the latest when possible 20:20 <@scarabeus> ok so again 20:20 <@jmbsvicetto> I don't agree we making it mandatory, though 20:20 <@Betelgeuse> wired: little gain 20:20 <@Betelgeuse> wired: unless you actually start planning deprecating some EAPIs 20:20 <@Betelgeuse> s/you/we/ 20:20 <@jmbsvicetto> wired: so no repoman die 20:20 <@scarabeus> Betelgeuse: eapi1 is mostly dead 20:20 <@Betelgeuse> scarabeus: yeah 20:20 <@scarabeus> http://dev.gentooexperimental.org/~scarabeus/eclass_eapi/ 20:20 <@scarabeus> eapi per eclass usage 20:21 <@jmbsvicetto> Betelgeuse: I think it's time we deprecate EAPI-1 and EAPO-2 20:21 <@jmbsvicetto> EAPI-2* 20:21 <@ferringb> scarabeus: use the appropriate eapi, rather than just forcing latest 20:21 <@bonsaikitten> Betelgeuse: I would like to see eapi1 and 2 deprecated, keep 3 as it is still very new 20:21 <@Betelgeuse> In general developers should be using new EAPIs because it results in better user experience. 20:21 <@bonsaikitten> deprecate 3 when we add next one 20:21 <@ferringb> why? 20:21 * ferringb is serious, lay out a beneficial reason please 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 20:21 <@scarabeus> ferringb: there is problem with that eclasses operate differently under eapis, namely py one, so less shit to remember 20:21 <@bonsaikitten> ferringb: eclasses get really messy when you can't have slot deps etc. 20:22 <@ferringb> bonsaikitten: eapi1 was slot deps 20:22 <@jmbsvicetto> scarabeus: do you have totals for all ebuilds? 20:22 <@ferringb> 2 was use 20:22 <@ferringb> doesn't address why 2 should be deprecated 20:22 <@scarabeus> jmbsvicetto: pinspect eapi_usage portdir 20:22 <@bonsaikitten> ferringb: less to remember 20:22 <@Betelgeuse> And less for new devs to learn. 20:22 <@ferringb> they're going to have to learn an eapi one way or another 20:23 <@wired> ferringb: because we have 4 now and there's absolutely no reason to use any of the others? 20:23 <@jmbsvicetto> ferringb: what's the benefit of using 2 when you can use 3? 20:23 <@jmbsvicetto> ferringb: 3 "simplifies" use of 2 with rpefix 20:23 <@jmbsvicetto> prefix* 20:23 <@ferringb> *cough* 20:23 <@ferringb> I know what the eapi's do. :) 20:23 <@jmbsvicetto> ferringb: and I agree with bonsaikitten about having less to remember 20:23 <@jmbsvicetto> ferringb: I don't doubt that ;) 20:23 <@ferringb> I just don't agree that's it's worth while going and punting them 20:24 <@bonsaikitten> ferringb: no active punting, just no new adding 20:24 <@scarabeus> ferringb: i never said proactively update ebuilds 20:24 <@bonsaikitten> it'll slowly smoke them out 20:24 <@scarabeus> ferringb: jsut version bumps/additions must use latest where possible 20:24 <@scarabeus> now most bumps in some areas keep eapi1 20:24 <@scarabeus> and some quite hidious code 20:24 <@scarabeus> because cp just works 20:24 <@scarabeus> :D 20:24 <@ferringb> an EAPI bump isn't going to make hideous code go away 20:24 <@ferringb> probably will breed it if it's an eclass imo 20:25 <@ferringb> people should use what's appropriate imo 20:25 <@wired> why would eapi1 ever be more appropriate than 4? 20:25 <@ferringb> 1 should go away imo, since frankly it's not worth using in light of 2 20:25 <@ferringb> 0 over 4 20:25 <@scarabeus> the same goes for 2 over 3 20:25 <@ferringb> 0 gets you backwards compatibility 20:25 <@wired> 0 is the exception 20:25 <@scarabeus> 0 is staying probably forever 20:25 <@ferringb> it's the same arguement however 20:25 <@scarabeus> or until we create global update mechanism 20:25 <@ferringb> there is no such thing, nor will there be 20:25 <@scarabeus> btw did you notice that with eapi0 it is nto possible to emerge portage right? 20:26 <@ferringb> scarabeus: that's portages problem 20:26 <@ferringb> look elsewhere 20:26 <@wired> that makes even 0 useless ;p 20:26 * ferringb konws his upgrade pathway for 0 isn't correct, although it was, and will be 20:26 <@scarabeus> ferringb: even pkgcore is not possible if i checked rite :) 20:26 <@ferringb> scarabeus: yeah, not my doing. as said, will be resolved. 20:26 <@scarabeus> we should probably enforce that too 20:27 <@ferringb> eh? enforce what exactly 20:27 <@scarabeus> :P 20:27 <@scarabeus> not really, but would be nice if someone made sure that it really works, from time to time :) 20:27 <@ferringb> in this discussion, define deprecate 20:27 <@ferringb> exact terms 20:28 <@ferringb> because even if 1/2 are annoying, they're actually useful as jumping points for upgrading 20:28 <@jmbsvicetto> ferringb: you also can't emerge pkgcore ;) 20:28 <@jmbsvicetto> with EAPI-0 20:28 <@wired> we really need another solution for upgrading anyway 20:28 <@scarabeus> i said so already :P 20:28 <@ferringb> jmbsvicetto: seriously, read up. already said I was going to fix that, and it was *not* my doing. 20:28 <@scarabeus> ferringb: how so? 20:28 <@scarabeus> ferringb: if base is kept at 0 20:28 <@scarabeus> rest can be even latest 20:28 <@jmbsvicetto> ferringb: sorry, was taking care of summary 20:29 <@scarabeus> it does not bork upgrade path 20:29 <@scarabeus> because you update your pm first 20:29 <@ferringb> scarabeus: if all of the base were zero, you'd be correct. base doesn't really stay at zero though 20:29 <@jmbsvicetto> ferringb: one way would be to require repoman --force to be able to commit ebuilds with EAPI-1 and EAPI-2 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 20:29 <@ferringb> repoman needs to stop being the enforcer on this 20:30 <@ferringb> specifically, the holder of what is good/bad eapi wise 20:30 <@ferringb> push the whitelist into the tree, make portage use that 20:30 <@ferringb> avoids having to wait on releases every time 20:30 <@scarabeus> wlist make sense :) 20:31 <@ferringb> gives the same capabilities to overlays too. 20:31 * ferringb notes that's a seperate discussion for PM monkeys however 20:31 < Arfrever> Alternatively council could decide that upgrading of system using package manager supporting only EAPI <=1 is not supported. 20:32 <@ferringb> No. 20:32 <@scarabeus> Arfrever: ahem and what should people with old systems do 20:32 <@scarabeus> die? 20:32 <@ferringb> purpose of eapi was backwards compatibility 20:32 <@ferringb> throwing out backwards compatibility defeats the fucking purpose of eapi imo 20:32 < Arfrever> scarabeus: Reinstall Gentoo. 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 20:33 <@ferringb> wired: which is actually a bit harder than you'd think because a PM isn't standalone 20:33 <@Betelgeuse> wired: There's a decision that upto 1 year upgrade path must work. 20:33 <@Betelgeuse> After that it's best effort. 20:33 <@wired> ferringb: understandable 20:33 <@Betelgeuse> Any way could we continue this outside agenda discussion at the end? 20:33 * ferringb nods 20:33 <@wired> ferringb: thats why freezing the tree before major changes sounds like a good idea to me. 20:33 <@ferringb> would like to see the specifics of "deprecate" nailed down also 20:33 <@wired> anyway lets move on 20:34 <@ferringb> as in "we do xyz to repoman, this is the usage scenario for verbump, revbumps, new pkgs, etc". 20:34 <@bonsaikitten> so we should discuss upgrade paths a bit more - ML maybe? 20:34 <@ferringb> yes, and keep in mind removing the support from the tree doesn't remove the PM's requirement to support it 20:35 <@ferringb> we've got the vdb to support, which can be years beyond the last appearance in the tree 20:35 <@scarabeus> ferringb: i never wanted pm to drop support 20:35 <@scarabeus> ferringb: just not allow it in portage for new shitz 20:36 <@jmbsvicetto> so, GLEP 48? 20:36 <@ferringb> scarabeus: point was, the support's there even if you decide to tell people "stop using it" ;) 20:36 <@ferringb> 48 meanwhile 20:36 <@jmbsvicetto> who wants to start? 20:36 <@scarabeus> meh diego is not around, so /me is considered as proposer 20:36 <@scarabeus> so start bashing me 20:37 <@scarabeus> lets separate it onto 2 parts one update lead role and recruitement 20:37 <@scarabeus> second change the wording for the resolving issues 20:37 <@scarabeus> so part one... 20:38 <@jmbsvicetto> I have some objections to a few points: 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 20:39 <@jmbsvicetto> in my view this "conditions" the QA team members 20:40 <@scarabeus> ok agree that that section is confusing and probably should be removed 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) 20:41 <@ferringb> where is that patch btw 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 20:41 <@scarabeus> http://dev.gentoo.org/~scarabeus/glep-0048.diff 20:41 <@ferringb> thanks 20:41 <@scarabeus> for the point 2 20:41 <@wired> Im a bit concerned with all this, I feel we're handling the whole thing the wrong way 20:42 <@scarabeus> if we drop the last two added lines 20:42 <@scarabeus> + Resolution for this kind of issue is completely in hands of the QA team 20:42 <@scarabeus> + and only the Gentoo Council can revisit the case. 20:42 <@scarabeus> it would be better for you? 20:42 <@scarabeus> jmbsvicetto: ^ 20:42 <@wired> as jmbsvicetto said, disciplinary actions of any kind belong to DevRel. 20:42 <@bonsaikitten> I don't see why QA needs some special powers 20:43 <@jmbsvicetto> scarabeus: yes 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. 20:43 <@Betelgeuse> scarabeus: For temporarily disabling access you don't need to mention infra. 20:43 <@Betelgeuse> scarabeus: There are others who can do it too 20:43 <@wired> bonsaikitten: exactly 20:43 <@wired> in effect all gentoo developers are informal QA members 20:43 <@scarabeus> Betelgeuse: ok so what should i write there (approperiate people)? 20:44 <@scarabeus> Betelgeuse: i know that in reality we will ping recruiters or infra or anyone with this priv:) 20:44 <@jmbsvicetto> scarabeus: I mentioned one idea to Diego that I see is no longer in your proposal 20:44 <@scarabeus> which one :) 20:45 <@Betelgeuse> scarabeus: I would prefer first try DevRel and if unresponsive then fallback on anyone with access 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" 20:45 <@Betelgeuse> scarabeus: I am assumign DevRel continues to handle the follow up 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 20:45 <@Betelgeuse> So no need to involve infra. 20:45 <@scarabeus> jmbsvicetto: ^ this is there 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 20:46 <@jmbsvicetto> scarabeus: bah, I missed it 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. 20:46 <@wired> why are we making this so damn political 20:46 <@bonsaikitten> yes 20:46 <@Betelgeuse> wired: possible too 20:46 <@ferringb> wired: yep 20:46 <@bonsaikitten> why is QA trying to encapsulate themselves from the rest 20:46 <@wired> we all do QA 20:46 <@ferringb> yes and no 20:46 <@scarabeus> with few exceptions 20:46 <@jmbsvicetto> scarabeus: you only mention it for the 2nd case. I'd have that the rule for both cases 20:46 <@Betelgeuse> wired: I presume the request here is to be able to force the hand of the people who can disable access. 20:47 <@scarabeus> i think that two points should be rewritten in one 20:47 <@scarabeus> with some adjusted wording from what i get from you so far 20:47 <@wired> Betelgeuse: by giving others "power" to do so? 20:47 <@wired> Betelgeuse: seems we're trying to fix this the wrong way 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. 20:48 <@ferringb> it's too strict 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" 20:48 <@wired> jmbsvicetto: you say that, but in reality anyone can request that 20:48 <@ferringb> doesn't work that way 20:48 <@ferringb> infra's not going to pop someones commit bit for a flagrant mistake 20:49 <@jmbsvicetto> wired: anyone can, but infra and devrel will only do it after an evaluation if it's just "anyone" asking 20:49 <@ferringb> when arfie broke portage in the tree, he still had his rights afterwards 20:49 <@ferringb> *arfrever, pardon 20:49 <@wired> well it was our mistake 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 20:49 * ferringb doubts infra wants to be in the position of deciding the validity of a "temp suspend this dudes rights" also 20:49 <@wired> no one went to infra and said "hey, this guy is doing something nasty, lift his privs for a while" 20:49 <@wired> "then devrel will handle it" 20:50 <@ferringb> wired: hmm? if you're talking about the portage incident, actually we did 20:50 <@Betelgeuse> In that instance access was suspended. 20:50 <@ferringb> Betelgeuse: via devrel, if memory serves 20:50 <@Betelgeuse> But really I don't think we should be handling that case here now. 20:50 <@ferringb> well 20:51 <@wired> its all part of the same problem 20:51 <@Betelgeuse> Unless we want to do it publically without asking parties. 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 20:51 <@ferringb> need scenarios if we're going to discuss this 20:51 <@jmbsvicetto> so my perspective is the following: 20:51 <@Betelgeuse> ferringb: My point was to rather keep it more abstract 20:52 <@ferringb> avoid names is your meaning 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 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 ;) 20:52 <@ferringb> either way 20:53 <@ferringb> jmbsvicetto: agreed 20:53 <@ferringb> curious 20:53 <@ferringb> what exactly is devrel's mandate? 20:53 <@scarabeus> 2 cases a) accidental commit breakage b) blatant ignoring of NO and commiting stuff 20:53 <@ferringb> a definition, if you would 20:53 <@Betelgeuse> ferringb: devrel policy is approved by council 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 20:53 <@Betelgeuse> ferringb: but it was suggested to turn that too into a GLEP which would be clearer 20:53 <@scarabeus> for a) i think suspend and then bugaboo should happen 20:53 <@scarabeus> b) suspend investigation + devrel 20:54 <@ferringb> Betelgeuse: it's a question of purposes 20:54 < Calchan> scarabeus, a) is a mistake, we all do mistakes, b) is devrel's problem 20:54 <@ferringb> Betelgeuse: mainly, I see qa/devrel intersecting, and not always in great ways 20:54 <@scarabeus> Calchan: violating qa rules is not devrel problem 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 20:54 < Calchan> scarabeus, you don't suspend somebody who's made an honest mistake or you're an ass 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 20:55 <@scarabeus> Calchan: some guys script over night, so hell i would suspend breaking commit just to freeze it 20:55 < Calchan> and if it's not an honest mistake it's devrel matter 20:55 <@Betelgeuse> ferringb: http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap2 20:55 < Calchan> you guys are completely on the wrong track 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. " 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. 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 20:57 <@wired> I still don't understand why we have to actually write a rule/definition/whatever for things like this. 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. 20:58 <@ferringb> and yes, not sure I agree w/ locking all of this down into rules... little bit of wiggle room is useful 20:58 <@Betelgeuse> ferringb: partly historical probably 20:58 <@ferringb> Betelgeuse: that devrel/qa schism I referenced there is what bugs me about the whole setup. 20:58 <@ferringb> not convinced it's best either 20:59 <@Betelgeuse> ferringb: Yeah it's not ideal. 20:59 <@ferringb> it basically defangs QA's ability to actually set standards 20:59 <@Betelgeuse> ferringb: But I don't think you can solve communication / co-operation with rule books. 20:59 <@ferringb> and leaves them asking nicely (or bribing/blackmailing if they're of my persusasion) to get things done 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 20:59 * ferringb didn't claim you could 20:59 <@wired> does this really need rules? 20:59 <@ferringb> wired: that's not how it works 20:59 <@wired> no, thats how I think it should work :) 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." 21:00 <@ferringb> Eh 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. 21:01 <@wired> ferringb: my point, thank you :) 21:01 <@ferringb> formalizing the ability to punt someones access in an emergency is needed however 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 21:01 <@Betelgeuse> ferringb: It's already in DevRel policy. 21:01 <@Betelgeuse> ferringb: We can easily turn that into a GLEP too. 21:01 <@ferringb> Betelgeuse: I meant for QA 21:02 <@jmbsvicetto> Calchan: the current proposal, taking out the last part in the 2nd diff scarabeus presented, doesn't give QA disciplinary power 21:02 <@ferringb> Calchan: yes and no, but yes, get your point. 21:02 <@wired> I recommend we talk about this a bit more in the ML 21:02 <@jmbsvicetto> wired: we have to ;) 21:02 <@Betelgeuse> ferringb: I was trying to also communicate that both should be worked in tandem. 21:02 <@jmbsvicetto> wired: this was never in a state where the council could decided about it on this meeting 21:02 <@Betelgeuse> ferringb: Probably gives the best result. 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 21:03 < c1pher> Calchan: I'm not sure if I'm the only one that's confused, but to which parts are you refering? 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 21:04 < Calchan> jmbsvicetto, isn't that supposed to be infra's responsibility? 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 21:04 <@bonsaikitten> i guess we disagree if there even is a problem 21:05 < Calchan> again, infra's job 21:05 <@bonsaikitten> also what the problem is, and if we need to fix it 21:05 <@wired> Calchan: I've been trying(and failing) to point that out 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" 21:06 < Calchan> jmbsvicetto, infra is always available, more than QA at least 21:06 < Calchan> and the interpretation is true, but they are gnetoo users too 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 21:07 < Calchan> jmbsvicetto, don't all developers have authority to talk to infra/devrel/council/etc...? 21:07 <@jmbsvicetto> Calchan: I didn't say infra wasn't avilable, I said they might not have noticed it 21:07 <@jmbsvicetto> Calchan: one thing is being able to talk to, another is having "delegated powers" to do so 21:08 < Calchan> what are you talking about? devs don't need anybody's authorization to talk! 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" 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 21:09 <@wired> i think the real problem here is "authority" 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 21:10 <@Chainsaw> I do believe the way the "distfiles go in dev.g.o/~you" edict was handed down is problematic. 21:11 <@bonsaikitten> Chainsaw: silly thing, that 21:11 <@Betelgeuse> Calchan: infra members are not required to understand ebuild development 21:11 <@Betelgeuse> But in general I don't see problems in automatically pulling the switch pending eval is multiple QA members ask. 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 21:13 < Calchan> jmbsvicetto, how about you talk to them before you make this kind of assumption? 21:14 <@jmbsvicetto> To infra or to the other developer? 21:14 < Calchan> infra 21:14 <@jmbsvicetto> I've talked with infra members about this issue before 21:14 <@jmbsvicetto> and I'm not complaining about infra, quite the contrary 21:15 <@jmbsvicetto> so, let's push GLEP-48 back to the mls? 21:15 <@wired> yes please 21:16 <@jmbsvicetto> Do we want to over the bugs? I'd prefer to leave that for next meeting 21:16 <@Betelgeuse> was always the plan any way :) 21:17 <@scarabeus> ha ha :) 21:17 <@jmbsvicetto> Seems like no one is interested on bugs, so who wants to chair next meeting and when shall we have it? 21:17 <@scarabeus> ayway i will update teh text with what we said here and sent it again to -dev 21:17 <@Betelgeuse> scarabeus: good context :) 21:18 <@scarabeus> jmbsvicetto: in 4 days around 18:00 presence will be around 5 out of 7 members O:) 21:18 <@scarabeus> or something :D 21:18 <@jmbsvicetto> Shall we have the next meeting at 20110301 2000 UTC? 21:18 <@bonsaikitten> scarabeus: and a combined alc level of ~3% ;) 21:19 <@jmbsvicetto> scarabeus: hehe - that'll be an "extra" meeting ;) 21:19 <@scarabeus> jmbsvicetto: agreed on the date 21:19 <@Chainsaw> jmbsvicetto: What day of the week is that please? 21:19 <@jmbsvicetto> Tuesday 21:19 <@scarabeus> same as this 21:19 <@Betelgeuse> wfm 21:19 <@wired> wfm2 21:19 <@Chainsaw> Yes, that works for me. 21:20 <@jmbsvicetto> any volunteers to chair the meeting? 21:20 <@Chainsaw> It's my birthday, so there must be cake. 21:20 <@Chainsaw> But other then that, all good :) 21:20 <@jmbsvicetto> ferringb: ^^ 21:20 <@ferringb> bastards 21:20 <@jmbsvicetto> Chainsaw: hehe 21:20 <@ferringb> jmbsvicetto: answer your question? ;) 21:20 <@ferringb> yeah, can swing it 21:20 <@jmbsvicetto> is that for FOSDEM or meeting date? :P 21:20 <@wired> Chainsaw: woohoo, we'll have cake ;p 21:20 <@ferringb> may need to adjust it, but won't know for a week or so 21:21 <@jmbsvicetto> ferringb: if you'd prefer a different date / time, can you make a suggestion? 21:21 <@jmbsvicetto> alright, I see no one is too interested, so I'll chair next meeting too 21:22 <@jmbsvicetto> ferringb: want to suggest a different date or can we go forward with Tuesday, 20110301 2000 UTC? 21:22 <@scarabeus> jmbsvicetto: ferringb look like he agreed to that chair, nt to the date :P 21:22 <@scarabeus> *looks 21:22 * ferringb didn't agree to chair 21:22 <@scarabeus> :D 21:22 <@ferringb> I tried that one, I sucked at it 21:22 * scarabeus chuckless 21:22 <@ferringb> *once 21:23 <@scarabeus> jmbsvicetto: anyway i can chair it so you dont do it in row 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 21:23 <@jmbsvicetto> ok 21:23 <@ferringb> jmbsvicetto: or I'll just send a proxy, since I've not yet ;) 21:23 <@jmbsvicetto> scarabeus: you want to chair it or will i? 21:23 <@scarabeus> ferringb: soome pretty girl please, if Chainsaw has the birthday so we have it cosy 21:23 <@jmbsvicetto> I* 21:23 <@wired> ferringb: we can always push it a few days if you can't make it :) 21:23 <@scarabeus> jmbsvicetto: write me 21:23 <@jmbsvicetto> ok 21:24 <@jmbsvicetto> so, let's open the floor to the community 21:24 <@jmbsvicetto> Anyone has any issues or questions to bring to the attention of the council? 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 21:25 <@bonsaikitten> scarabeus: you sound fat 21:25 <@bonsaikitten> :D 21:25 <@scarabeus> i am all slim and sexy! 21:25 <@scarabeus> well at least the first part is true 21:26 <@bonsaikitten> I'm leaner than your steak! HA HA 21:26 <@scarabeus> :)) 21:26 <@jmbsvicetto> I sense some discrimination against geometric figures like the circle :P 21:27 <@bonsaikitten> no, we need differences to enjoy what we have 21:27 <@wired> i have an issue 21:27 <@wired> FOSDEM in 4 days! 21:27 <@jmbsvicetto> hehe 21:28 <@wired> assuming my flight is not cancel;ed anyway 21:28 <@jmbsvicetto> wired: I have a thing tonight, work tomorrow and start my travel to FOSDEM on Thursday ;) 21:28 <@wired> heh 21:29 <@jmbsvicetto> oh and I still need to write some slides :> 21:29 <@scarabeus> ook i guess i can safely disappear and take look what sabayon guys pinged about :) 21:29 <@jmbsvicetto> ok, it seems like there's no issues from the community 21:29 <@jmbsvicetto> I'll wait a bit more and close the meeting in around 30 minutes 21:29 * ferringb is back to work already 21:30 <@ferringb> avail off/on with some lag for the next half hour or so 21:30 <@wired> jmbsvicetto: really? just end the meeting now :P 21:30 <@jmbsvicetto> scarabeus / wired: Did you get my wave invitation? Mind checking the summary there 21:30 <@wired> jmbsvicetto: got it, reading it 21:30 <@jmbsvicetto> I hereby close this meeting" 21:31 <@jmbsvicetto> Anyone intersted has 30 minutes to raise an issue before I commit the summary / logs 21:31 < hwoarang> re arch teams 21:32 <@wired> jmbsvicetto: looks good 21:32 < hwoarang> bare in mind that amd64 is at stake too 21:33 <@scarabeus> looks fine 21:33 < hwoarang> jmbsvicetto: maybe you want to contact *all* the arch teams 21:33 <@jmbsvicetto> hwoarang: I do 21:33 < hwoarang> thank u 21:33 <@jmbsvicetto> hwoarang: I wasn't planning to exclude any team 21:33 < hwoarang> ok didn't realize that 21:34 <@jmbsvicetto> I'll try to send an email to all teams alias 21:35 <@jmbsvicetto> +tonight