path: root/meeting-logs/20110201.txt

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