path: root/meeting-logs/20050915.txt

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 <wolf31o2-work> only if I broke something
15:44 <@seemant> 15:41 <wolf31o2-work> most people won't say anything
15:44 <@seemant> 15:42 <wolf31o2-work> 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 <wolf31o2-work> currently, #1 is implied
15:44 <@seemant> 15:42 <wolf31o2-work> 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"]