diff options
Diffstat (limited to 'xml/htdocs/proj/en/council/meeting-logs/20110201.txt')
| -rw-r--r-- | xml/htdocs/proj/en/council/meeting-logs/20110201.txt | 467 |
1 files changed, 0 insertions, 467 deletions
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110201.txt b/xml/htdocs/proj/en/council/meeting-logs/20110201.txt deleted file mode 100644 index 52bf0507a5..0000000000 --- a/xml/htdocs/proj/en/council/meeting-logs/20110201.txt +++ /dev/null @@ -1,467 +0,0 @@ -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 |