15:00 <@Koon> ok, let's start 15:01 -!- mode/#gentoo-council [+m] by Koon 15:01 -!- ribosome [n=ribosome@dhcp-160-185.rsvs.ulaval.ca] has joined #gentoo-council 15:01 <@Koon> First item on the agenda is : 15:01 -!- kallamej [n=kallamej@82.182.101.109] has joined #gentoo-council 15:01 -!- arachnist [n=arachnis@nat-Exatel.who.vectranet.pl] has joined #gentoo-council 15:01 -!- ciaranm [n=ciaranm@alpha.total-knowledge.com] has joined #gentoo-council 15:01 <@Koon> Official confirmation that the council is inline with the already-defined roles of devrel and QA and its commitment to make already-approved GLEPs (including GLEP 31) respected (Clarification of position asked by many people including Ciaran McCreesh, Patrick Lauer and Lance Albertson) 15:02 -!- AllanonJL|W [n=allanonl@gentoo/developer/allanonjl] has joined #gentoo-council 15:02 -!- ka0ttic [n=ka0ttic@gentoo/developer/Ka0TTiC] has joined #gentoo-council 15:02 <@SwifT> euhm... is "yes" sufficient? 15:02 -!- MadMethod [n=Method@gentoo/developer/Method] has joined #gentoo-council 15:02 <@vapier> which is to say that everything previous management has put forth is still valid 15:02 <@seemant> sounds like there are more GLEPs than just 31 that are not being respected? 15:02 <@Koon> My position is that the current council should be in-line with what is already defined 15:02 <@SwifT> the devrel-part is always under heavy discussion (still is on the mailinglist 15:03 -!- dertobi123 [n=tobias@gentoo/developer/dertobi123] has joined #gentoo-council 15:03 -!- Flameeyes [n=flame@gentoo/developer/Flameeyes] has joined #gentoo-council 15:03 <@Koon> SwifT: you mean the QA/devrel power setup ? 15:03 <@SwifT> yes 15:04 <@agriffis> I think the "commitment to make already-approved GLEPs respected" part is Ciaran's way of asking: What is the Council going to do if people don't respect this stuff? Is the Council going to take disciplinary action for technical violations? 15:04 <@Koon> yes, the fact that we accept the current default situation doesn't mean we cannot (or shouldn't) change it 15:05 <@Koon> my opsition is that QA should work more closely with devrel... but maybe it's just a dream ? 15:05 <@Koon> position 15:06 <@SwifT> we aren't going to get all technical violations on our plate will we? that's more for QA 15:06 <@seemant> which means QA needs to have some "teeth" in order to be effective 15:06 <@agriffis> SwifT: but the question is: what happens when people violate? Does QA have any authority? Does devrel handle discipline for technical violations? 15:06 <@seemant> sorry, I'm asking 15:06 <@SwifT> bah, can't people use "common sense"... 15:07 <@Azarah> my opinion is that we should not split something among bodies .. QA does QA .. if somebody do not listen, depending on how serious it is, they might go to Infra to temporarily put that person on ice, but the complaint should still go through devrel 15:07 <@SwifT> QA should probably have authority but only if its a large enough team... not 4 or 5 people 15:07 -!- mpagano [n=mike@70.105.167.3] has joined #gentoo-council 15:07 <@Azarah> if its not satisfactory how they do it, then that should be fixed 15:07 -!- slarti [n=tmartin@gentoo/developer/slarti] has joined #gentoo-council 15:08 <@Koon> the first case of QA direct punishment you'll hear screams of abuse of power 15:08 <@Azarah> i think somebody said they talked about it on devrel mailing list this last week or so ? 15:08 <@Koon> I agree with vapier, let just one group be the bad guys 15:08 <@vapier> and the QA team should not be dealing with that crap 15:08 -!- wolf31o2-work [n=wolf31o2@gentoo/developer/wolf31o2] has joined #gentoo-council 15:08 <@SwifT> I thought QA would just pass on the violator to devrel 15:08 <@vapier> that is what the current process is, yes 15:08 -!- Betelgeuse [n=betelgeu@gentoo/developer/Betelgeuse] has joined #gentoo-council 15:08 <@agriffis> Anyway, my point here is not to necessarily answer this question. My point is to say that this question is loaded. Depending on the Council's answer, there will be follow-up questions like: "So that implies..." 15:08 <@Koon> but people think it's too slow/complicated 15:09 <@agriffis> Koon: huh? 15:09 -!- dang [n=dang@gentoo/developer/pdpc.active.dang] has joined #gentoo-council 15:09 <@agriffis> Koon: the only people I've heard say the complaint process is slow/complicated is devrel 15:09 <@vapier> the only way to find out if the QA violation -> devrel punishment is too slow is to let it be tested 15:09 <@agriffis> Koon: but I haven't talked to a lot of people personally on that topic 15:09 <@Koon> agriffis: in the thread I read people said that going through devrel for QA violations takes too much time 15:09 <@Koon> (memry replacing lost IMAP folders) 15:10 <@Koon> (memory) 15:10 <@SwifT> www.gentoo.org/proj/en/qa is quite... empty :/ 15:10 <@agriffis> Koon: oh okay, I might not have seen that message 15:10 <@Azarah> Koon: who said it? devrel like agriffis noted 15:10 <@vapier> that's because the qa proj has been working with 2 or 3 people via irc 15:10 <@SwifT> well, if it sticks with a few people, no official and approved documentation to back it up, QA doesn't have much powers... even with Council standing behind it 15:10 <@seemant> and basically swegener's been documenting things on his personal site (d.g.o/~him) for the mmoment 15:11 * agriffis *must* pay attention to a con-call for a few minutes 15:11 <@seemant> SwifT: it's a bit of a chicken-egg thing -- people don't see QA as being effective and so aren't all eager to pay attention to it, making QA less effective, making people not .... 15:11 <@seemant> ad nauseum 15:11 <@Koon> ok, let's focus... I think the only thing we can say atm is that the current procedure is the default "QA should go punish through devrel", but discussion is welcome to think about a change 15:12 <@seemant> ok first of all can we simplify things a bit? 15:12 <@Koon> this is not the place to discuss the solution, just to say what current policy is 15:12 <@Azarah> and the 'change' might be pressed is to improve the resolving procedure if that is an issue ? 15:12 <@seemant> I don't think that every QA violation is devrel worthy 15:12 <@Azarah> seemant: i dont think QA will do that 15:12 <@seemant> surely QA can sort things out with devs themselves -- part of it is -- do we as the council stand by QA to have that minimal authority to bring things to devs' attention? 15:13 <@vapier> QA team finds violation -> QA educates violater -> violater improves 15:13 <@Azarah> like vapier pointed out, its usually if there is nothing else they can do to try to keep the person in bounds 15:13 <@vapier> violator does not improve -> devrel kicks their ass 15:13 <@seemant> with *repeat* offenders, you have a situation that devrel might be involved, fex ignoring QA 15:13 <@seemant> at that point, it's cut and dried even in our current policy 15:14 <@Koon> seemant: authority to bring things to devs attention, of course 15:14 <@vapier> QA works off of agreed policy. policy was put forth by developers and validated by council. 15:14 <@seemant> the fact is, QA can scream all they want -- but if there's no *authority* behind them, devs might be inclined to feel free to ignore QA 15:14 <@Azarah> and if they do, they get sorted by devrel in theory 15:15 <@vapier> so they have authority now. listen to the QA team because they're working of valid policy. if you dont, devrel will take action. 15:15 <@seemant> vapier: that's it, yes 15:15 <@Koon> ok, I think we agree... can we move to the next item ? 15:15 <@solar> yes 15:15 <@SwifT> but QA should also take note about QA mistakes, help GDP/devrel improve the affected documentation, keep developers up to date ... not just be the "audit" group (not saying that they aren't doing this already, I just see too much "authority"-discussions here :) 15:16 <@Koon> let there be a group and we'll see what they want to do in it 15:16 <@Koon> ok, moving on 15:16 <@Koon> ferringb asked that we move to item 3 directly and come back to item 2 afterwards 15:16 <@Koon> so now : 15:16 <@vapier> err hold, the glep stuff in item 1 15:16 <@vapier> we all agree that previous management decisions are valid 15:17 <@Koon> yes 15:17 <@vapier> aka ciaranm's glep 31 can be put into effect 15:17 <@Azarah> dont see a problem with it as long as nano is sorted ? 15:17 <@vapier> makes sense to me 15:18 <@vapier> yeah, i've been working a little with ciaranm and upstream nano dev 15:18 <@vapier> havent had a compelling reason to do it until now though ;) 15:18 <@Koon> ok. 15:18 <@Azarah> so it should work like vim ? fex not convert utf8 -> ascii ? 15:18 <@solar> glep31 should repoman or server side cvs handling scripts enforce that? 15:19 <@vapier> both 15:19 <@vapier> but that's implementation detail for ciaranm/infra/portage to sort 15:19 <@seemant> repoman should ideally, but cvs scripts would be nice for a verify/validate 15:19 <@vapier> yes, 1.3.8 should not mung existing encodings 15:19 <@agriffis> it doesn't matter to us. we just decide the policy is good, then portage team, etc is free to enforce it. 15:19 <@solar> ciaranm says "glep31check can run client or server." 15:20 <@seemant> vapier: what's an ETA for nano to handle utf8 well enough? 15:20 <@vapier> policy and implementation are sep ... we care about the first 15:20 <@seemant> and are the other common editors (emacsen I assume) up to the task already? 15:21 <@vapier> ciaranm said 1.3.8 handles input better than previous ones, but still has quirks ... i'll have to get him to brain dump on me how to test myself 15:21 <@SwifT> emacs has utf-8 support (at least the utf.xml guide sais so :) 15:21 <@vapier> ciaranm has been keeping vim up-to-speed when it breaks down 15:22 <@seemant> then would it be prudent to wait on enforcing the check until nano can handle it well enough? 15:22 <@solar> as long as the scripts are run client and or server side the editor part is not so valid it would seem. 15:22 <@solar> the commit should fail 15:22 <@seemant> (is the nano-using dev community large enough to warrant the wait?) 15:22 <@agriffis> yes, the nano-using community makes about 50% of the commits. 15:22 <@seemant> wow, nice 15:22 <@agriffis> (vapier) 15:22 <@vapier> i'll look into that, but i dont think it'll be a significant issue 15:23 <@seemant> agriffis: LOL 15:23 <@seemant> then I vote glep31 for ASAP 15:23 * agriffis is in favor of glep31 15:23 <@seemant> with my emphasis on the P for apparent technical reasons 15:24 <@Koon> glep31 is already approved, bt can't hurt to say I support it 15:24 * vapier humps glep31 15:24 <@Koon> let me know when we can move on :) 15:24 <@agriffis> so it's approved, resurrected, and the council says it's live, as soon as there are no nano issues. 15:24 * SwifT attaches a "I love XML and UTF-8" note on Glep31 15:24 <@agriffis> Koon: let's move on 15:24 <@Azarah> think we can move on ;p 15:24 <@Koon> ok. next 15:24 <@Koon> glep40: Standardizing "arch" keywording across all archs, Vote asked by Grant Goodyear 15:25 <@Azarah> this one we gonna decide to let it still cook or not ? 15:25 <@vapier> i think it's cooked now 15:25 <@vapier> i expected more stuff after i sent that e-mail 15:25 <@Koon> my position is that it's ready for prime time 15:25 <@vapier> since the amd64/x86 unification is not part of it 15:25 <@Koon> it's not very disruptive, more an officialisation of what's already under way 15:25 <@Azarah> like i said already, i dont see the alternative happening, and something needs to be done 15:26 <@vapier> we've had too many growing pains with gcc/glibc on x86 15:26 <@vapier> an arch team would help that 15:26 <@vapier> especially when i ask for testers on gentoo-dev, people say it's ok, and then when released shit blows up 15:26 <@Koon> yes, and the reasons outlined in the GLEP are very valid 15:26 <@solar> it's still going to be the exact same people. (toolchain@) 15:26 <@SwifT> did gentoo-dev@ stabilise on the thread? I thought the GLEP itself was quite accepted, just small details about what an AT would be/have 15:26 <@seemant> as far as I know it, idl, ferringb, tester and a few arch testers have already signed up on an x86 alias (with #-x86 channel in tow) 15:26 * agriffis chuckles at "robust x86 arch team" 15:26 <@Azarah> didnt say it was, i said i do not see it will happen (unification), and glep40 is logical thing to do since the dev base seem to be moving more and more from x86 15:26 <@Koon> AT status is another GLEP 15:26 <@vapier> this is unrelated to maintainership 15:27 <@vapier> maintainers dont change 15:27 <@SwifT> ah ok 15:27 <@vapier> it's just a matter of the x86 team changes the keyword from ~x86 to x86 once the maintainer of the package says it's cool 15:28 <@Azarah> yeah, and since glibc-2.3.6 or whatever wont work with gcc-3.3.x, work is cut out for whoever 15:28 <@seemant> ah, now the "maint" keyword idea from Stuart(?) makes sense on that thread 15:28 <@Koon> I would rather follow ciaran. maintainer does package.mask -> ~arch and arch teams do ~arch -> arch 15:29 <@SwifT> sounds logical 15:29 <@Koon> simple and inline with the ~arch meaning 15:29 <@seemant> and the process is then: maintainer files stabilisation bug and cc's all KEYWORDS? 15:29 <@SwifT> (and easy to document :) 15:29 <@solar> need a much larger team. 15:29 <@vapier> yes but there are often times when maintainer wants to keep packages in ~arch 15:29 <@vapier> for specific reasons 15:29 <@Koon> solar: probably, but that's still a step in the right direction, no ? 15:29 <@vapier> i have a whole suite of packages i never want to hit stable for example 15:29 <@SwifT> yes, but then it was said that an overlay should be used... 15:29 <@seemant> surely there should be some clearance from the maintainer about "Ready for stable" or "please don't ever stable" type things? 15:30 <@agriffis> I think it varies from package to package. 15:30 <@vapier> it's common sense ... if you dont have a pressing reason to stable an unstable package and the package has a metadata which indicates a maintainer, talk to the maintainer 15:30 <@Azarah> and arch to arch 15:30 <@agriffis> Some packages can be bumped, changed to ~arch, and safely changed to stable in a month. 15:30 <@agriffis> (with no need for maintainer approval in the process, esp. when there's no real maintainer for a package) 15:31 <@vapier> right, and metadata.xml should indicate how well a package is watched over 15:31 * agriffis nods 15:31 <@agriffis> perhaps there needs to be more info in metadata.xml 15:31 <@agriffis> that indicates the policy per package. 15:31 <@Koon> we could even have a "WARN_ME" flag in metadata telling people not to stable without maintainer advice 15:32 <@agriffis> but then the question comes up: what happens when an arch team violates policy because they disagree with the package maintainer..>? 15:32 <@Koon> for those exceptions 15:32 -!- roger55 [n=roger@gentoo/developer/roger55] has joined #gentoo-council 15:32 <@vapier> "it depends" ? 15:32 <@agriffis> heh 15:32 <@Koon> agriffis: the problem is already here, glep doesn't change that 15:32 <@seemant> ok, so let me understand something -- maintainers are simply not allowed to stable anything under any circumstances? 15:33 <@agriffis> Koon: true, I'm straying from the glep, sorry 15:33 <@Azarah> agriffis: in that case either the maintainer will need to sort the package (old or new), or agree to the judgment of arch team if he cannot 15:33 <@Koon> seemant: they can be part of arch teams :p 15:33 <@SwifT> seemant: unless they're in the arch team 15:33 <@seemant> (I'm asking because this is going to be going into policy and guides and quizes and the like -- and I'm even confused) 15:33 <@SwifT> but then the arch team probably needs to have some agreement when a package is stabilized and when not 15:33 <@vapier> the idea is you join the arch team you work on 15:33 <@agriffis> vapier: so every dev is on an arch team? 15:34 <@Koon> that will help solving the x86 manpower problem 15:34 <@agriffis> I don't think that's going to go over well. 15:34 <@seemant> no it's not going to go over very well at all 15:34 <@agriffis> Koon: no, it just puts us back where we were 15:34 <@Koon> agriffis: no, but if you want to mark stable you should 15:34 <+g2boojum> No, you only need to join the arch team if you need to control stabling. 15:34 <@vapier> ah, there it is 15:34 <@agriffis> g2boojum: but you need to join to stable the package you maintain, is what I'm hearing. 15:34 <@agriffis> I'm probably confused by this darned conf call. 15:35 <@Koon> please focus on the glep text rater than the general problem of marking stable and arch/maintainer wars 15:35 <+g2boojum> agriffis: If you're happy with the default (~arch means the arch team can stable when they find it acceptable) 15:35 <@seemant> agriffis: I'm not in the conf. call (or any conf. call) and I read it the same way 15:35 <@Azarah> the amd64 teams policy for example, is that if a package maintainer is not part of amd64 team, and stable the package without contacting them, he handles all bugs 15:35 <@Koon> the glep only says x86 is not an exception 15:36 <@Azarah> true that 15:36 <@seemant> ok those two sentences together make sense 15:36 <@Koon> and I agree with it... 15:36 <@Azarah> well, like i said already, its the logical thing to do with dwindeling x86 dev coverage 15:36 <@solar> so nobody outside of arch teams will be going from ~arch to arch? 15:36 <@vapier> i know i've jumped x86 ship 15:36 <@seemant> I read the following: if I maintain something (and my arch is primarily amd64) I'm willing to stable so long as I handle any and all bugs related to that package + amd64? 15:36 <@agriffis> okay, I'm fine with the glep in principle, very happy with it actually. I just want to understand: what happens when a package maintainer wants a package to roll to stable? either they have to join an arch team to stable it, or they have to file a bug against the arch teams, etc. 15:36 <@vapier> that's how it is now for all arches but x86 15:37 <@Azarah> agriffis: yup, like we do with sandbox, etc already 15:37 * agriffis shrugs 15:37 <@agriffis> ok, that's fine. it just seems like you end up with people on arch teams solely for the purpose of marking a single package stable. 15:37 <@agriffis> that's a little strange. 15:37 <@seemant> vapier: actually it seems to me you do it for your own arch but have arch teams do it for the rest? 15:38 <@seemant> in the current scheme I mean 15:38 <@Azarah> not really, they need to test and plan gcc/glibc/whatever migrations, etc 15:38 <@vapier> mips, sparc, hppa, and ia64 have their own teams 15:38 <@Azarah> some things is easy, some not 15:38 <@vapier> as does amd64 15:38 <@Koon> ciaranm says that some maintainers have pre-arrangements with arch teams and can mark things stable 15:38 <@agriffis> and alpha! 15:38 <@vapier> i do it for my own arches because i'm the only guy (arm/sh/s390) or because i'm on the team (hppa/ia64) 15:39 <@Azarah> x86 have just been relatively easy in the past, as its the no1 supported arch in the linux world (correct me if im wrong) 15:39 <@Koon> as long as it's pre-arranged in advance 15:39 <@vapier> ok 15:39 <@agriffis> Koon: the only thing I don't like about that is that it is specifically an under-the-table agreement that happens outside of the written policy. 15:39 <@SwifT> I suppose this pre-arrangement is mostly when the arch team knows the dev follows a good QA (i.e. doesn't circumvent repoman, etc.) 15:39 <@Koon> of course :) 15:40 <@agriffis> in other words, it is a vehicle for miscommunication, disagreement, etc. I'd rather if there were a way to handle that *inside* the policy. 15:40 <@agriffis> but this is beside the point. 15:40 <@Koon> yep. 15:40 <@Koon> moving on.. anyone wants to deny or delay the glep ? 15:40 <@Azarah> agriffis: i do not see the issue if its something simple with general history of little to no per-arch issues 15:40 <@vapier> it isnt quite outside of the policy ... GLEP 40 specifically says maintainers can make arangements with x86 team like any other team 15:40 <@SwifT> surely not 15:40 <@seemant> I just want clarification on it, Koon 15:40 <@agriffis> I agree with the GLEP. There might just be more details to be worked out later as an indirect result. 15:41 <@agriffis> vapier: oh, thanks 15:42 <@vapier> so, what do you want clarification on seemant ? 15:42 <@solar> can we agree with the idea, but wait till we have the resouces to handle it at a later time (like a team in plae). 15:42 <@Koon> solar: we can vote the glep, doesn't mean it will be in effect tomorrow 15:42 <@vapier> the idea is that the team is being slowly formed, but it wont gather force until the GLEP is approved 15:42 <@solar> place. What we have now is far to small to hit the "go" button 15:42 <@seemant> vapier: the "you need to be on an arch team to stabilise your own package on the arch that you happen to be on primarily" bit 15:43 <@vapier> seemant: i worded it wrong ... highly suggested you be on the arch team, but you can make arangements with specific arch teams instead 15:43 <@Azarah> seemant: or get permission from them 15:43 <@agriffis> ciaranm says that sparc actually keeps a written list of people with whom they have arrangements. 15:43 <@vapier> yeah, Weeve does 15:43 <@vapier> that way he knows who to stab first 15:44 <@Koon> that should solve the "under-the-table" problem 15:44 <@seemant> may I paste? 15:44 <@Koon> be my guest 15:44 <@seemant> it's about 8 lines worth 15:44 <@seemant> 15:41 only if I broke something 15:44 <@seemant> 15:41 most people won't say anything 15:44 <@seemant> 15:42 the idea is to do like is done on other arches... you either #1. say "Hey, I have an x86 box and am willing to field my own bugs on my packages" or #2. join the arch team 15:44 <@seemant> 15:42 currently, #1 is implied 15:44 <@seemant> 15:42 the idea is to make it explicit 15:44 <@seemant> is that correct then? 15:45 <@vapier> pretty much ... bugs are floated between arch teams and maintainer depending on where the issue lies 15:45 <@seemant> so "pretty much" implies something's missing there 15:45 <@seemant> what's that something? 15:45 <@SwifT> not entirely afaik... 15:45 <@SwifT> I'm more in favor of this arrangement-thing 15:46 <@vapier> the pretty much is that bugs which arent due to running on a specific arch are [rightfully] given to the maintainer 15:46 <@seemant> apparently #1 *is* making the arrangement 15:47 <@Koon> seemant: does that answer your question ? 15:47 <@seemant> Koon: are these arrangements private or public? 15:47 <@seemant> how are they documented? 15:48 <@seemant> if a maintainer with an arrangement goes away, does his/her successor inherit the prior arrangement? 15:48 <@seemant> etc and so on are things I'm not sure I entirely understand 15:48 <@Koon> I think it's up to the arch team to store their arrangements list 15:48 <@seemant> but the principle of "x86 is just another arch, not the grandpappy of them all" is something I fully agree with 15:49 <@Koon> that's what's in the glep 15:49 <@seemant> s/grandpappy/one-ring/ 15:49 <@SwifT> so I suppose we can move along, keeping the technical stuff on gentoo-dev@ again (which is open for all devs) 15:49 <@Koon> we might need some stabilization glep in the future 15:49 <@seemant> Koon: agreed 15:50 <@Koon> ok so everyone agrees with glep40, as in "x86 is not a special arch, let there be an x86 team" 15:50 <@agriffis> seemant: right, I would like to see that 15:50 <@SwifT> Koon: yes 15:50 <@solar> yes on #glep40 15:50 <@vapier> yes 15:50 <@seemant> yes 15:50 <@Koon> ok, moving on 15:50 <@Koon> glep33: Eclass Restructure/Redesign Vote asked by Brian Harring 15:51 -!- mode/#gentoo-council [+v ferringb|afk] by Koon 15:51 <@seemant> oh man, finally this glep is in existence and has some motion 15:51 <@seemant> my vote is "about time" 15:51 <@vapier> in case anyone cares, Azarah/agriffis voted yes earlier for glep40 15:51 <@Koon> yes, and I find the GLEP33 text very detailed and well written 15:51 <@SwifT> i'm in favor of it as well 15:51 <@Koon> vapier: who cares :) 15:52 <@vapier> ferringb knows what i want/need above and beyond GLEP33 15:52 <@vapier> but GLEP33 is the framework which i'm for 15:52 <@Koon> OK . anyone else has to say something about it ? 15:52 * vapier pokes ferringb|afk 15:52 <@seemant> vapier: can you share? 15:52 <@Koon> (we might fit the hour, finally) 15:53 <+ferringb|afk> vapier: specifics you want spilled, or... 15:53 * ferringb|afk assumes this is in reference to per pkg eclass/elib support 15:53 <@vapier> right, but that topic need not be covered here 15:53 <@SwifT> righto... on to the meeting time schedule :) 15:53 <@vapier> since it can be based off of GLEP33 15:53 <@Koon> I vote yes to glep33 15:53 <@solar> no objections 15:53 -!- g2boojum_ [n=grant@gentoo/developer/g2boojum] has joined #gentoo-council 15:54 -!- mode/#gentoo-council [+v g2boojum_] by ChanServ 15:54 <@seemant> vapier: can you share that with us offline then? 15:54 -!- g2boojum [n=grant@gentoo/developer/g2boojum] has quit ["leaving"] 15:54 <@vapier> i think i've mentioned in on gentoo-dev before 15:54 <@seemant> yes to 33 15:54 -!- g2boojum_ is now known as g2boojum 15:54 <@Azarah> no issues with glep33 15:54 <@agriffis> yes to 33 15:55 -!- hparker [n=hparker@gentoo/developer/hparker] has joined #gentoo-council 15:55 <@Koon> OK. On to "Discussion of the next meeting date(s)"... the idea being should we have a rule to determine meeting dates or just arrange them manually each time 15:55 <@SwifT> I would rather have a rule 15:55 <@agriffis> rule-based 15:55 <@SwifT> meetings that are announced in less than one week in advance might be dangerous 15:55 <@seemant> something rule based aka regular 15:55 <@agriffis> we can always make an exception if some significant number can't make it. 15:56 <@vapier> right 15:56 <@vapier> easier to push back a few days 15:56 <@Azarah> i dont have a problem either way, but most i think already said they want it more anual 15:56 <@vapier> and if anything it helps people get stuff added to agenda 15:56 <@Koon> 2nd Thursday of each month, can be pushed back to 3rd ? 15:56 <@agriffis> works for me 15:56 <@SwifT> what time? 1900 UTC ? 15:56 <@Azarah> fine by me if it works for everybody else 15:57 <@seemant> SwifT: this time honestly suits me very well 15:57 <@agriffis> are we going to try to figure out something that works for solar? 15:57 <@agriffis> otherwise he's always going to need a proxy. 15:57 <@Koon> for the time we should alternate maybe 15:57 <@seemant> SwifT: but I am flexible to within +/- 2-3 hours 15:57 <@agriffis> solar: ...but you're here now, I just realized... 15:57 <@SwifT> nono, 1900UTC is probably the best here as well 15:57 <@Koon> solar prefers some other time, would be fair to have some meetings at a time he prefers 15:57 <@Koon> tough I probably can't make it at 2200 :) 15:58 <@seemant> Koon: I don't mind pushing back to 3rd Thursday of the month -- does that start with next week? :P 15:58 -!- moreon [n=moreon@gentoo/user/moreon] has joined #gentoo-council 15:58 <@SwifT> perhaps we can discuss this on the mailinglist when everybody has his calendar right next to him/her :) 15:58 <@Azarah> i should still be awak (or usually are) 15:58 <@Azarah> awake* 15:58 <@vapier> it's on the agenda man 15:58 <@vapier> so lets start with 3rd Thursday @ 1900UTC 15:58 <@vapier> and we'll see about floating the time on the list 15:59 <@Koon> seemant: the 15th of September is already the 3rd, we are late :) 15:59 <@seemant> Koon: oooohh 15:59 <@seemant> that's true 15:59 -!- kito [i=keetz@gentoo/developer/kito] has quit [Client Quit] 15:59 <@Koon> that's why I said 2nd Thursday that can be pushed back to the 3rd 15:59 <@vapier> wfm 15:59 -!- kito [n=kito@gentoo/developer/kito] has joined #gentoo-council 15:59 <@agriffis> me too 15:59 <@SwifT> wfm2 15:59 <@vapier> i'm available * 15:59 <@Koon> that would put the next one at 13th October 15:59 <@SwifT> what about solar? 15:59 <@seemant> yeah 3rd thursds @ 1900 wfm2 16:00 <@Koon> 3rd or 2nd ? 16:00 <@Koon> 3rd = 20th October 16:00 <@SwifT> 2nd or 3rd doesn't matter here 16:00 <@Koon> then 24th November, 22nd December 16:00 <@SwifT> stick with the first idea... 2nd, can be pushed back to third 16:00 <@seemant> solar seems to be occupied afk, so it's probably more sane to fine tune the times on the ml this week 16:00 <@agriffis> not dec 22 16:00 <@Koon> that's why I prefer 2nd, that can be pushed back to 3rd in case of emergency 16:00 <@solar> my time is a bit tricky now. 16:01 <@Koon> ok. 16:01 <@vapier> erm, dec22nd is 4th thur 16:01 <@SwifT> yes... better see if we can find a concensus the upcoming days that fits all 16:01 <@SwifT> we're with 7, shouldn't be impossible... just hard :) 16:01 <@Koon> vapier: oops :) 16:01 <@vapier> `cal` is teh bomb 16:01 <@SwifT> I'd rather not have a meeting time that's too difficult for one or two... 16:01 <@agriffis> solar: what works for you? 16:01 <@agriffis> solar: I think we're all speculating without knowing what you can do. 16:02 <@Koon> guess we can finish the discussion off-meeting 16:02 * agriffis nods 16:02 <@seemant> I gotta run people, but I'm staying online 16:02 <@seemant> thanks for a great first meeting 16:02 <@agriffis> good first meeting, guys 16:02 <@Koon> we'll open for Q&A 16:02 <@vapier> well lets go with 2nd thur pushing back to 3rd @ 1900UTC 16:02 <@vapier> tentative 16:02 <@vapier> bam 16:02 <@seemant> and thanks for bearing with me with my questions 16:02 <@SwifT> :) 16:02 <@seemant> feel free to diss me while I'm gone 16:02 -!- mode/#gentoo-council [-m] by Koon 16:03 < ChrisWhite> Koon: snip it here? 16:03 <@seemant> brb in 15 16:03 <@Azarah> later seemant 16:03 <@Koon> Does anyone has questions ? 16:03 <@Koon> ChrisWhite: Q&A session is stil part of the meeting :) 16:03 <@Koon> unless no questions... 16:03 < ChrisWhite> pfft, fine! ;p 16:03 -!- vapier changed the topic of #gentoo-council to: You missed the meeting earlier at 1900UTC (1500EST) | Agenda covered: http://article.gmane.org/gmane.linux.gentoo.devel/31498 | seemant has a van full of candy for you, look out 16:03 <+ferringb|afk> Koon: noting y'all probably should track who shows in some fashion since there is the "with slacker boot" portion of council proposal... 16:03 -!- smithj [n=smithy@gentoo/developer/smithj] has joined #gentoo-council 16:04 <@solar> you sched anytime and I'll do my best to make it. 16:04 <@Koon> ferringb|afk: yes, but today everyone was there :) 16:04 -!- smithj [n=smithy@gentoo/developer/smithj] has left #gentoo-council [] 16:04 <@Koon> ferringb|afk: we'll probably make some council pages on /proj somewhere 16:04 <+ferringb|afk> Koon: yah, I'm saying record it so that it's not up in the air a year down the line come election time (yes I'm cynical) :) 16:04 <@vapier> Koon: i was going to look into getting the existing docs updated tonight with that list you posted (quiz/docs/etc...) 16:05 <@agriffis> ferringb|afk: I agree with you 16:05 <@Koon> vapier: ok. we still have to fix the projects list too... btw : 16:05 <@agriffis> ChrisWhite: put the attendees on the top of the meeting log, eh? 16:05 <@solar> I have to go now. If anybody has anything for me I can be reached via email@ 16:05 <@vapier> agriffis: you logged it right ? we can just store it in cvs 16:05 <@vapier> proj/council/meeting-logs/ 16:06 < ChrisWhite> agriffis: I'll post when you're ready and filter it later 16:06 <@agriffis> ok, I'll put it there 16:06 -!- MetalGOD [n=DevNull@gentoo/developer/MetalGOD] has left #gentoo-council ["Leaving"] 16:06 <@vapier> datestamp it like a good boy 16:06 <@agriffis> ChrisWhite: no need, I logged it too. I'll just put it in the council cvs 16:06 * vapier pats agriffis on the bum 16:06 <@Koon> vapier: we'll have to discuss how subprojects of the "base" TLP should be promoted as full-fledged projects 16:06 < ChrisWhite> agriffis: no emailed version ? 16:06 <@vapier> you still logging ? 16:06 <@vapier> e-mail the URL :P 16:06 <@Koon> like arch projects, or embedded 16:06 <@agriffis> ChrisWhite: no, let's skip filling people's mailboxes 16:06 <@agriffis> ChrisWhite: I'll do as vapier said, email a link 16:07 < ChrisWhite> ok, my logs are closed then 16:07 < ChrisWhite> I'll use it locally for a [Summary] thread :P 16:07 <@Koon> vapier: also kill the gentoo.xml contents and turn it into an open project directory 16:07 <+g2boojum> Koon: I'm assuming that it's as simple as people moving the project pages out of proj/en/foo to proj/en. *Grin* 16:07 <@vapier> Koon: we're pretty happy with the current state of things 16:07 <@Koon> g2boojum: you're assuming bad 16:08 <@vapier> (embedded project that is) 16:08 <@Koon> g2boojum: quite a few projects have been created and don't appear 16:08 <@vapier> very little management, whole lot of coding 16:08 -!- spb- is now known as spb__ 16:08 <@Koon> g2boojum: because what appears is governed by a page rather tha by /proj contents 16:08 <+g2boojum> Koon: Oh, you're referrring to the actual project-listing page. Sorry, I missed that part. 16:09 <@Koon> g2boojum: we just need to fix that page and warn people to edit it if they want their project to appear 16:09 < ChrisWhite> so 1) Confirmed council roles 2) yes on glep 40 3) yes on glep 33 4) 2nd or 3rd thursday of the month 1900 UTC 16:09 <@Koon> ChrisWhite: yes 16:09 <+g2boojum> Koon: Smack pauldv, or ask SwifT's team for help, because that page is supposed to be autogenerated. 16:10 <+ferringb|afk> offhand... how up to date is the tlp listings? 16:10 < ChrisWhite> well that was easy :P 16:10 <@Koon> ferringb|afk: it's outdated -- but there is no such things as TLPs anymore 16:10 < ChrisWhite> Koon: want me to write up a summary like that and put the sucker on -dev? 16:10 <+ferringb|afk> Koon: projects, moreso I realize. 16:11 <@agriffis> ChrisWhite: probably better for something like that to come from a council member 16:11 <@Koon> ChrisWhite: about "1)", it's more a confirmation that we confirm old GLEPs rather than council role 16:11 < ChrisWhite> agriffis: ok 16:11 <+ferringb|afk> Koon: what I'm getting at is that I don't think I've seen any proposal/discussion about conversion of existing projects over to rules of glep39, specifically the election portion of it 16:11 <@agriffis> so having said that, I'll write it. 16:11 <@agriffis> ChrisWhite: thanks for volunteering, though. 16:11 <@Koon> ferringb|afk: thing is, the list page does not reflect the /proj directory contents 16:11 < ChrisWhite> agriffis: I'm a documentation sucker 16:11 <@Koon> ferringb|afk: but we are working on it 16:11 < ChrisWhite> agriffis: it's what I do ;p 16:11 <@Koon> it's somewhere in my giant TODO list 16:12 * ferringb|afk notes posting what is needed to be done might be wise (be lazy, delegate) 16:12 < ChrisWhite> agriffis: hopefully that summary won't turn into a huge thread :P 16:13 <@Koon> ferringb|afk: about elections, I think each project should do as they want, the council shouldn't intervene unless there are complaints from project members about their leads or something 16:13 <+ferringb|afk> inactive leads come to mind. 16:13 < ciaranm> inactive and incompetent leads 16:13 <@Koon> ferringb|afk: good example 16:13 <+ferringb|afk> regardless, the doc states it as every 12 months 16:14 <+ferringb|afk> so... change it, or follow it :) 16:14 <@Koon> members can call vote, if inactive lead doesn't show up... 16:14 <@agriffis> question regarding mailing lists: follow ups to the meeting summary should go to gentoo-council, similar to nfp business on gentoo-nfp, right? 16:14 <@agriffis> should I post the summary on gentoo-dev at all? 16:14 <@Koon> agriffis: not sure gentoo-council is open/advertised yet 16:14 < ciaranm> is gentoo-council open for subscription and archive? 16:15 < ChrisWhite> post something to -dev telling them to followup at -council 16:15 < ChrisWhite> with maybe a gmane thread link if that's possible.. 16:15 <@Koon> agriffis: in doubt, use -dev 16:15 <@Koon> OK, I'll have to go, sleep tight 16:16 <+ferringb|afk> don't spose someone could clarify exactly how a group of people (or singular) get classified as a project also... 16:16 <@Koon> grant's glep is quite clear about it 16:16 <+g2boojum> ferringb|afk: That one's in the GLEP -- they create a project page. 16:16 <@Koon> a project is a group of people maintaining a project page :) 16:17 <+ferringb|afk> g2boojum: getting at the fact there is no filter on it. 16:17 <@Koon> example, the "Apache" project ! http://www.gentoo.org/proj/en/apache/ 16:18 <@agriffis> ciaranm: gentoo-council is open for subscription 16:18 <@Koon> ok, I really have to go and get completely drunk 16:18 -!- Koon [n=koon@gentoo/developer/Koon] has quit ["*plop*"] 16:18 <+g2boojum> ferringb|afk: That's by design. If it becomes a problem, then people can get the council involved. 16:19 -!- spb- [n=spb@gentoo/developer/spb] has joined #gentoo-council 16:19 <+ferringb|afk> 'spose, although seems a bit iffy; reactive, potential damage/problems can already be created. 16:20 -!- SwifT [n=swift@gentoo/developer/swift] has quit [Read error: 110 (Connection timed out)] 16:20 <+ferringb|afk> g2boojum: ignore my comments; just thinking about avoiding drama down the line if people abuse open setups. 16:20 <+g2boojum> ferringb|afk: k *Grin* 16:21 -!- g2boojum [n=grant@gentoo/developer/g2boojum] has left #gentoo-council [] 16:21 <@vapier> dont worry, we ignore you well enough ferringb|afk 16:21 -!- spb__ [n=spb@gentoo/developer/spb] has quit ["."] 16:27 -!- ferringb|afk [n=bharring@gentoo/developer/ferringb] has left #gentoo-council ["back to work foo"] 16:29 -!- Maedhros [n=jc@i-195-137-43-74.freedom2surf.net] has left #gentoo-council [] 16:30 -!- hparker [n=hparker@gentoo/developer/hparker] has left #gentoo-council ["telnet://bbs.homershut.net"]